si on pend par les couilles ceux qui font des fonctions de 1000 lignes, que doit-on faire de ceux qui écrivent des fonctions de 4-5000 lignes plusieurs fois dans un fichier > 30 000 lignes le tout en utilisant un langage objet et les fonctions ayant plus de 10 paramètres ?
(vrai question, j'ai rencontré ça professionnellement et c'est pas évident... a oui, j'ai oublié, comment on fait quand c'est le chef qui code comme ça le tout sans mettre de commentaire ?)
Sinon, pour moi le mini vital c'est :
- svn (ou autre, faut pas être sectaire ;-) )
- bugtracker (j'aime particulièrement trac qui s'interface bien avec svn)
- des commentaires dans le code (objet, fonctions, ...) : utilisation de doxygen, javadoc, etc. C'est à mon avis le mieux car c'est très facile a écrire et à maintenir en même temps que le code *
- point très important, et souvent plus complexe que les problèmes techniques : se mettre d'accord dans l'équipe sur des conventions de codage : code en anglais, position des accolades (enfin c'est forcément à la fin de la ligne donc il n'y a pas a discuter ;-) ), ...
Sinon, j'irai plus loin sur le traitement des erreurs.
Tant que c'est possible (langage, lib externes, ...) toujours avoir - au moins en debug - le niveau de warning le plus élevé possible tout en rajoutant le traitement des warning comme des erreurs. Le résultat est que le programme ne compilera / se lancera jamais tant qu'il y a le moindre warning. C'est un peu contraignant mais ça oblige à lire les warnings et force a écrire du code correcte. Il n'y a rien de plus gonflant que de vouloir compiler un soft et d'être automatiquement noyé sous les warnings idiots.
(*) : Dans certains cas, on peut faire passer en tant que warning le fait qu'il manque un commentaire (sur un membre le nécessitant, membre public, ...). Associé au traitement des avertissements comme des erreurs, l'effet est immédiat : les commentaires apparaissent.
[^] # Re: vocabulaire
Posté par CrEv (site web personnel) . En réponse au journal Bonnes pratique pour le développement. Évalué à 4.
(vrai question, j'ai rencontré ça professionnellement et c'est pas évident... a oui, j'ai oublié, comment on fait quand c'est le chef qui code comme ça le tout sans mettre de commentaire ?)
Sinon, pour moi le mini vital c'est :
- svn (ou autre, faut pas être sectaire ;-) )
- bugtracker (j'aime particulièrement trac qui s'interface bien avec svn)
- des commentaires dans le code (objet, fonctions, ...) : utilisation de doxygen, javadoc, etc. C'est à mon avis le mieux car c'est très facile a écrire et à maintenir en même temps que le code *
- point très important, et souvent plus complexe que les problèmes techniques : se mettre d'accord dans l'équipe sur des conventions de codage : code en anglais, position des accolades (enfin c'est forcément à la fin de la ligne donc il n'y a pas a discuter ;-) ), ...
Sinon, j'irai plus loin sur le traitement des erreurs.
Tant que c'est possible (langage, lib externes, ...) toujours avoir - au moins en debug - le niveau de warning le plus élevé possible tout en rajoutant le traitement des warning comme des erreurs. Le résultat est que le programme ne compilera / se lancera jamais tant qu'il y a le moindre warning. C'est un peu contraignant mais ça oblige à lire les warnings et force a écrire du code correcte. Il n'y a rien de plus gonflant que de vouloir compiler un soft et d'être automatiquement noyé sous les warnings idiots.
(*) : Dans certains cas, on peut faire passer en tant que warning le fait qu'il manque un commentaire (sur un membre le nécessitant, membre public, ...). Associé au traitement des avertissements comme des erreurs, l'effet est immédiat : les commentaires apparaissent.