petites astuces pour bien coder

par **Ryle** » 11 juil. 2007, 14:23

Je suis d'avantage tabulations également... et si c'est vrai que cela peut déranger quand on change d'IDE, la plupart des éditeurs aujourd'hui (les bons du moins

) permettent de paramétrer la taille des tabulations pour éviter cela

Quant aux commentaires il n'y a pas de règle à la ligne, au bloc ou à la page : l'obejctif est de savoir ce que l'on fait sans avoir à analyser le code. On peut commenter un if() complexe parce qu'il va tester 3 ou 4 critères et on pourra passer sur une 30 de lignes d'affectation de variable en résumant le commentaire à : "// Affectation des variables"

Il y a quelques normes issues de javadoc pour les classes et les fonctions (les commentaires qui débutent par /** au lieu de /*), dont le but est de permettre la génération de la documentation associé et qui facilite leur recherche et leur emploi.

En gros, faut pas que ce soit un roman, faut juste que ce soit simple pour celui qui passera derrière, sachant que ca peut très bien être nous

par **zeus** » 11 juil. 2007, 14:05

Pour indenter au choix des espaces ou tab franchement je ne vois pas où ca peu gêné que se soit l'un ou l'autre.

Personnelement, je préfère par tabultation parce que la navigation au clavier est plus facile
Mais la présence de tabulation entraine le risque que différents IDE sous différents plateformes ne rendent pas la même indentation

Pour les commentaires je dirai par bloc, par ligne se serais trop lourd.

C'est discutable ...
Dans certains codes d'interfaces qui ne font qu'appeler des méthodes d'objets, chaque ligne à son importance ...
Dans certains méthodes de parcours de tableau pour afficher le contenu, seul le bloc est nécessaire

PS : au cas où tu ne l'aurais pas compris, je cherche juste à te montrer qu'il ne faut pas être trop précis quand tu détailles des conseils ... sinon personne n'en tiendra compte

par **Garth** » 11 juil. 2007, 13:08

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.

Personne n'est obligé d'aller dans la même direction

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 ?

Pour indenter au choix des espaces ou tab franchement je ne vois pas où ca peu gêné que se soit l'un ou l'autre.
Pour les commentaires je dirai par bloc, par ligne se serais trop lourd.

par **zeus** » 11 juil. 2007, 12:57

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 ?

par **Hywan** » 11 juil. 2007, 12:47

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.

par **Garth** » 11 juil. 2007, 12:12

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 : au lieu de .

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.

par **HanX** » 11 juil. 2007, 11:49

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 : au lieu de .

par **Hywan** » 11 juil. 2007, 10:46

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.

par **Garth** » 11 juil. 2007, 09:24

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.

par **Cyrano** » 11 juil. 2007, 07:39

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)

par **thehawk** » 10 juil. 2007, 23:10

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

c'est bien ca ?

par **Cyrano** » 10 juil. 2007, 19:38

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.

par **Garth** » 10 juil. 2007, 14:46

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 : , <hr>, etc...;
- en XHTML, XSL et autres trucbiduleML, on doit respecter la syntaxe XML et donc obligatoirement fermer ces balises : , <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.

par **Cyrano** » 10 juil. 2007, 14:05

...(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 : , <hr>, etc...;
- en XHTML, XSL et autres trucbiduleML, on doit respecter la syntaxe XML et donc obligatoirement fermer ces balises : , <hr /> etc...

par **Garth** » 10 juil. 2007, 08:59

balise même un 
c'est pas " " mais " ", pour être dans les règles du W3C

je sais que c'est mais en html tu peux mettre un simple 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)

petites astuces pour bien coder

Répondre

Étendre la vue Revue du sujet : petites astuces pour bien coder