Les petits trucs que je vais vous donnes sont valable pour n'importe quel langage de programmation.
Indenter correctement votre code cela en facilite la lisibilité espacer le mais pas trop parce que si un jour vous utilisez d'autres langage plus strict vous aurez des problèmes, attention aussi aux ouvertures et fermeture de balise dans certain langage vous devez fermer toutes les balise même un <br>.
Très important même si vous programmez uniquement pour vous commenté votre code si jamais quelqu'un doit le relire surtout si les variables ne sont pas pertinentes le code en sera plus dur à analyser.
Voilà si vous avez d’autres petites astuces n’hésiter pas.

balise même un <br>

c'est pas "<br>" mais "<br />", pour être dans les règles du W3C

<br> pour du html4.0 strict et <br /> pour du xhtml 1.0 transitionnal. Merci Garth pour ces petits trucs.

balise même un <br>

c'est pas "<br>" mais "<br />", pour être dans les règles du W3C

je sais que c'est <br /> mais en html tu peux mettre un simple <br> il n'y a pas d'obligation de /
par contre en xsl c'est obligatoire si une ou plusieurs des balises ne est pas fermer correctement le code ne fonctionnera pas
Je dis ça surtouts pour ceux qui apprennent en autodidacte (enfin même si certains qui ont appris la programmation en cours ne commente pas forcement et c’est une erreur qu’ils regretteront plus tard)

...(enfin même si certains qui ont appris la programmation en cours ne commente pas forcement et c’est une erreur qu’ils regretteront plus tard)

Je connais des professionnels de formation qui ne commentent leur code que contraints et forcés

Quant aux histoires de fermetures obligatoires, il faut simplifier : soit on est dans un langage XML et toutes les balises doivent impérativement être fermées pour que le code soit conforme, soit on est dans un langage autre et dans ce cas on doit utiliser les règles qui lui sont propres.

Donc, pour faire un point sur les balises dites "vides" (br, hr, img et d'autres) :
- en HTML 4.0, on utilise une syntaxe SGML et leur fermeture est interdite ou facultative : <br>, <hr>, etc...;
- en XHTML, XSL et autres trucbiduleML, on doit respecter la syntaxe XML et donc obligatoirement fermer ces balises : <br />, <hr /> etc...

Je connais des professionnels de formation qui ne commentent leur code que contraints et forcés

Quant aux histoires de fermetures obligatoires, il faut simplifier : soit on est dans un langage XML et toutes les balises doivent impérativement être fermées pour que le code soit conforme, soit on est dans un langage autre et dans ce cas on doit utiliser les règles qui lui sont propres.

Donc, pour faire un point sur les balises dites "vides" (br, hr, img et d'autres) :
- en HTML 4.0, on utilise une syntaxe SGML et leur fermeture est interdite ou facultative : <br>, <hr>, etc...;
- en XHTML, XSL et autres trucbiduleML, on doit respecter la syntaxe XML et donc obligatoirement fermer ces balises : <br />, <hr /> etc...

Pour ce qui est de commenter le code j’émets la possibilité qu'une personne autre que celle qui l’écrit le lise, cela facilite la compréhension mais ce n'est pas une obligation.
Pour les fermetures de balises effectivement cela dépend du langage utiliser comme tu l’as expliqué "autres trucbiduleML" sont plus strict que le html.

Pour ce qui est de commenter le code, c'est important pour deux raisons.

La première, c'est que, même pour celui qui développe le code, il doit pouvoir le reprendre dans six mois ou dans deux ans sans passer une semaine dessus pour comprendre ce qu'il doit effectuer.

La seconde, c'est lorsqu'on travaille en équipe : les coéquipiers doivent pouvoir rentrer dans le code des autres pour les mêmes motifs que précédemment. Et ce point là, je le vis au quotidien, il faut parfois se bagarrer pour obtenir que certains collègues se disciplinent un peu.

Enfin, je dirais que, partant du principe que les cimetières sont remplis de gens irremplaçables, il n'est pas exclus que chacun d'entre nous soit appelé vers d'autres cieux (ou une autre activité) à un moment ou un autre : il est donc souhaitable de laisser un terrain propre pour ceux qui prendront le relai. On le réalise d'autant plus lorsqu'on prends soi-même le relai derrière un autre.

Mais c'est une habitude. Parfois difficile à adopter au départ, mais on finit par le faire naturellement sans soucis. Et ce sera d'autant plus facile si on le fait au fur et à mesure, pas après avoir écrit 5000 lignes de code.

Donc en faite il faut choisir entre le HTML 4.0 et le Xhtml

c'est bien ca ?

absolument. Le HTML 4 n'est pas encore mort même s'il commence à devenir un peu obsolète et offre moins de possibilités que le XHTML. Il demande en revanche un peu moins de rigueur puisque ce n'est pas un langage XML. Ceci dit, la rigueur n'est pas prohibée et faire un code en HTML 4 strict peut se révéler tout aussi valable que faire du XHTML 1.0.

Je dirais pourtant que préférer le XHTML 1.0 permet de se préparer au XHTML 1.1 et surtout au futur XHTML 2.0 qui ouvrira des perspectives très intéressantes puisque ce sera un véritable "eXtended" en ce sens qu'on disposera d'abord de davantage de balises et qu'on pourra créer les siennes propres. (Enfin pour autant que j'aie pu comprendre, les gourous me corrigeront)

Pour ce qui est de commenter le code, c'est important pour deux raisons.

La première, c'est que, même pour celui qui développe le code, il doit pouvoir le reprendre dans six mois ou dans deux ans sans passer une semaine dessus pour comprendre ce qu'il doit effectuer.

La seconde, c'est lorsqu'on travaille en équipe : les coéquipiers doivent pouvoir rentrer dans le code des autres pour les mêmes motifs que précédemment. Et ce point là, je le vis au quotidien, il faut parfois se bagarrer pour obtenir que certains collègues se disciplinent un peu.

Enfin, je dirais que, partant du principe que les cimetières sont remplis de gens irremplaçables, il n'est pas exclus que chacun d'entre nous soit appelé vers d'autres cieux (ou une autre activité) à un moment ou un autre : il est donc souhaitable de laisser un terrain propre pour ceux qui prendront le relai. On le réalise d'autant plus lorsqu'on prends soi-même le relai derrière un autre.

Mais c'est une habitude. Parfois difficile à adopter au départ, mais on finit par le faire naturellement sans soucis. Et ce sera d'autant plus facile si on le fait au fur et à mesure, pas après avoir écrit 5000 lignes de code.

Comme certaine personne du forum code pour eux même commenter n'est pas une obligation mais comme je l'ai dis c'est un plus, par contre professionnellement parlant il devient important de commenter sont code, je parle en connaissance de causes reprendre des long code et non commenter et bien plus difficile à comprendre donc après c'est a vous de voir si vous voulez faciliter la compréhension de votre travail ou pas.

J'aimerais juste apporter une petite correction à Cyrano (si si, j'ose ).

Le HTML 4 n'est pas mort du tout. Il reste amha bien vivant. Le XHTML 1.x l'a un peu poussé en dehors du Web, c'est un fait.

Depuis peu, je fais partis du groupe de travail HTML du W3C -- HTML Working Group -- (sous le titre honorifique d'Invité Expert, ça ne rigole plus !). Et je peux vous dire qu'HTML 5 va nous réserver de belles surprises. Mozilla et Opera ont même du mal à suivre, tellement les innovations sont nombreuses. L'HTML 5 sera de sûr plus orienté accessibilité, et supportera nettement mieux les nouvelles technologies. Beaucoup de balises font leur apparition pour donner un style plus Web 2.0 à nos belles petites pages. Comme par exemple : le support de la vidéo nativement par les navigateurs. Plus besoin donc de choisir entre différent lecteur vidéo ; la possibilité de mettre des captions sur des images ; sujet sensible du moment : les @longdesc vs @role, très amusant, ou suppression de l'attribut @style etc. Beaucoup de nouveaux donc.

Par extension, on peut encore plus se réjouir pour XHTML 2.0 ! Il va nous offrir de sacrées belles choses. Mais je suis (suivre) moins les sujets sur XHTML 2. Je zyeute de temps en temps pour ne pas finir ignorant, je ne suis pas callé sur le sujet.

Je ne pense pas que l'on puisse être aussi catégorique sur « Choisir HTML » ou « Choisir XHTML ». Même avec les versions 4 et 1.x actuelles. Si on a deux languages, c'est qu'on a deux buts différents. On doit choisir un language en fonction de ses besoins et exigences. Ca nécessite en revanche de connaître les deux.

Quelques liens si vous êtes curieux : Quality & Assurance tenu par Karl Dubost, vous y trouverez les points forts du groupe de travail ; mais également ici. Et la liste des nouvelles balises par Jens Meiert.

Le HTML 4 n'est pas mort du tout.

Je suis tout à fait d'accord... pour ma part je code toujours en HTML. Je n'ai rien trouvé de révolutionaire dans le XHTML, que des contraintes exemple : <br /> au lieu de <br>.

Le HTML 4 n'est pas mort du tout.

Je suis tout à fait d'accord... pour ma part je code toujours en HTML. Je n'ai rien trouvé de révolutionaire dans le XHTML, que des contraintes exemple : <br /> au lieu de <br>.

Entre une ligne de code en dur et dynamique il y a quand même une différence je suis désoler. Excuse moi mais, si le fais de devoir fermer un br te dérange et que tu ne vois pas l’utilité de coder en XHTML alors tu n’évolueras pas beaucoup.

Il me semblait avoir souligner l'importance de ne pas prendre parti pour un language ou l'autre. Si le W3C a prit la peine de conserver les deux languages c'est pour une raison bien précise.

L'HTML 5 arrive, donc si on reste en HTML, on évoluera.
L'XHTML est une extension d'HTML, il évolue donc avec HTML.

Et regardes les liens que j'ai donné, tu verras que HTML 5 dépasse de loin XHTML 1.x.

Je n'avais pas pris part au débat car je pense qu'il est utopique et dangereux de vouloir que tout le monde aille dans une même direction.

Et là, j'interviens pour mettre le doigt sur ce fait : tant que l'HTML est utilisé, les gens peuvent l'utiliser.
Ce n'est pas une régression de ne pas passer à la dernière norme ...
Ne pas suivre les standards à la lettre, n'est pas une hérésie ... il m'arrive souvent de choisir la fonctionnalité contre la validité, à condition que tous les navigateurs l'accepte.
Honnêtement, le W3C ne fait band*** que les développeurs ...
Je suis partisans du fait que les codes soient multi-navigateurs, mais je ne passe jamais un source au validateur W3C. Je me contente de lire les recommandations et des les appliquer au maximum

En ce qui concerne l'indentation et les commentaires, je suis d'accord, mais il se pose ensuite la question du "comment"
Pour les tabulations : 4 espaces ou un tab ?
Pour les commentaires : chaque ligne, par bloc, par section compliquée ?