Quelles sont les directives de formatage de code généralement acceptées ?

Question

Selon Le modèle de qualité de McCall, Révision du produit est l'une des trois principales perspectives pour décrire les attributs de qualité d'un produit logiciel.Dans la perspective de révision du produit, maintenabilité, la capacité de trouver et de corriger un défaut, est identifié comme un facteur de qualité clé qui impacte la capacité à réviser le logiciel.

De toute évidence, à un moment donné du processus de révision, une implication humaine, en particulier celle des programmeurs, est nécessaire.Le formatage du code a un impact sur la capacité du programmeur à réviser le logiciel de manière efficace et efficiente.

Avec quelles directives de formatage de code généralement acceptées et indépendantes du langage avez-vous travaillé pour maximiser l'efficience et l'efficacité du programmeur dans le processus de révision du code ?

Answer 1

La meilleure ligne directrice avec laquelle j'ai jamais travaillé est la cohérence.Au fil des années, j'ai utilisé beaucoup de styles différents avec différentes équipes...le meilleur résultat que j'ai vu, c'est lorsque toute l'équipe est obligée d'utiliser le même style, quel que soit le style :-)

Answer 2

J'ai quelques réflexions sur certains concepts indépendants du langage :

1.) Supprimez le code mort.À moins que quelque chose ne soit absolument essentiel, le code mort commenté doit être supprimé.Cela encombre une routine, vous obtiendrez souvent des faux positifs lorsque vous recherchez une chaîne et cela montre une négligence générale qui n'est pas bonne pour un développeur professionnel.

2.) Pour les correctifs de maintenance, faites référence à un numéro de suivi des défauts dans un commentaire, en supposant que vous disposez d'une sorte de système de suivi des défauts.Cela permet à toute personne gérant votre travail de comprendre plus facilement pourquoi le code a été modifié entre une révision et une autre.

3.) Pour les langages qui le prennent en charge, déclarez les variables aussi proches que possible de leur première utilisation.

Je suis sûr qu'il existe quelques autres concepts indépendants du langage, mais ce sont les premiers qui me viennent à l'esprit.Autant que je sache, il est relativement difficile de discuter des normes de codage en l'absence d'un langage spécifique.Et je suis d'accord avec les autres réponses ci-dessus : le meilleur style est généralement celui qui se marie le mieux avec le style existant.

Vous voudrez peut-être jeter un oeil à Steve McConnell Code terminé.Il regorge de bonnes idées qui devraient être applicables dans presque toutes les situations de développement, quel que soit le langage de programmation.

Answer 3

La cohérence est la clé.Notez les directives quelque part et exigez leur conformité.

Le formatage du code ne vaut pas la peine de s'inquiéter ni de faire l'objet de discussions.Établissez simplement quelques règles et respectez-les.

Answer 4

Je suis d'accord avec Joël.Il existe de nombreux exemples de style ;la plupart sont bons.Certains ne sont plus aussi utiles que d’autres (notation hongroise ?).Mais le tout est de cohérence.Tant qu'un nouveau développeur peut arriver et comprendre le code immédiatement au lieu d'avoir à s'habituer au style personnel de chaque développeur, cela fonctionne.

Changer de norme chaque année environ est probablement une mauvaise idée.

Answer 5

Je suis d'accord avec Joel, la maintenabilité augmente considérablement lorsque vous avez de la cohérence au sein de votre organisation.Si je rejoins une autre équipe, le temps de montée en puissance est bien moindre si tout a une apparence et une sensation similaires à mon actuel, car je peux lire le code beaucoup plus rapidement sans tous les "changements de contexte interne" pour comprendre "donc ils utilisent mVar au lieu de _var" /etc

Answer 6

L'une des grandes normes dont nous disposons est le "préfixe" variable.Jusqu’à mon arrivée ici, j’écrivais principalement en solo donc je ne m’en souciais pas.

Nous sommes "obligés" de nommer les variables avec des préfixes qui indiquent ce qu'elles sont.Ainsi, vous savez instantanément en regardant dpVarName que c'est un pointeur vers un double et que lVarName est un long entier.

Au début, j'étais content qu'ils nous aient donné deux choix pour les blocs de bracketing, mais maintenant j'aimerais que nous soyons tous obligés de le faire d'une manière ou d'une autre.