Il y a quelques questions sur Stackoverflow sur s'il existe des recherches ou des études sur quelle est la meilleure convention / style de codage. Ce n'est pas la question de cette question. Cette question indique s'il existe des études qui recherchent s'il existe des avantages, des gains de productivité ou d'autres effets secondaires positifs pour avoir une convention et un style de codage à l'échelle de l'organisation.
J'ai mes propres opinions à ce sujet, ce qui est essentiellement des avantages énormes pour avoir de telles normes en place. Honnêtement, je ne me soucierai pas de moins de quel style je suis obligé d'utiliser tant qu'il est cohérent dans tout le code que je pourrais avoir à travailler avec.
Je veux juste savoir s'il y a des études qui soutiennent mes opinions ou les contredisent.
3 Réponses :
L'endroit où j'ai gagné le plus d'informations sur le problème:
C ++ Codage Normes: 101 Règles, Directives et meilleures Pratiques (Sutter, Alexandrescu)
Il vaut la peine de lire même si vous ne travailliez pas en C ++.
Nos études Soutenir l'affirmation selon laquelle la connaissance des plans de programmation et des règles de programmation peut avoir un impact significatif sur la compréhension du programme. Dans leur livre, les éléments de [la programmation] Style, Kernighan et Plaudeur identifient également ce que nous appelons les règles du discours. Nos résultats empiriques ont mis les dents dans ces règles: ce n'est pas simplement une question d'esthétique que les programmes devraient être écrits dans un style particulier. Il existe plutôt une base psychologique pour la rédaction de programmes de manière conventionnelle: les programmeurs ont de fortes attentes que d'autres programmeurs suivront ces règles de discours. Si les règles sont violées, alors l'utilité offerte par les attentes que les programmeurs se sont développés au fil du temps sont effectivement annulés. Les résultats des expériences avec les programmeurs d'étudiants débutants et avancés et avec des programmeurs professionnels décrits dans ce document fournissent un soutien clair pour ces revendications.
Études empiriques des connaissances de programmation. Soloway et Ehrlich.
Il y a eu plusieurs études montrant qu'une adhésion stricte à un style visuel cohérent aide les programmeurs expérimentés à conserver plus sur le problème local en mémoire sans avoir à mémoriser les éléments individuels du problème.
Cela a trait à la façon dont la mémoire humaine fonctionne. Il s'appelle chunking . Par exemple, il s'agit d'un phénomène bien étudié que Les Masters d'échecs sont beaucoup mieux pour mémoriser des postes d'échecs que ceux qui ne connaissent pas le jeu. Mais ce n'est que si les pièces se produisent dans des "positions naturelles" pouvant survenir dans un jeu normal. Si vous placez les morceaux d'échecs dans des positions aléatoires, les masters d'échecs sont Le même concept s'applique aux programmeurs. Lorsque les styles de codage sont cohérents, les constructions de codage apparaissent «naturelles» au programmeur et des portions plus grandes du code sont plus faciles à assimiler. Notre mémoire à court terme a une capacité de "sept plus de deux" morceaux de deux ", plus ces morceaux familiers sont les plus gros, plus notre esprit peut contenir activement dans la mémoire ( George Miller ).
En face du code formaté au hasard, les programmeurs doivent dépenser une énergie mentale d'addition à Avez-vous déjà trouvé qu'un problème semble si clair pendant que vous continuez à y travailler, mais vous semblez simplement "perdre les informations" lorsque vous revenez au problème plus tard; c'est-à-dire casser votre temps de flux? Le temps de flux est bien documenté dans Personnes de personnes (un must lire pour tous les programmeurs). Le temps de flux est lorsque les programmeurs obtiennent une grande majorité des travaux effectués et ne sont atteints que lorsque vous travaillez sur un problème pour une période de temps étendue et sans distinction. En effet, il faut une certaine période pour un programmeur pour assimiler suffisamment le problème dans la mémoire cognitive afin de travailler efficacement sur le problème. Le code bien formaté aide notre traitement d'image visuel, ce qui signifie que les programmeurs atteignent le temps de flux beaucoup plus rapidement.
J'ai des normes de codage auprès de plusieurs sociétés de logiciels. Il est regrettable combien de programmeurs estiment que les normes de codage ne sont qu'un moyen d'affirmer un contrôle inutile sur la manière dont ils font les choses; une forme de censure créative. La vérité se dit, cela compte rarement quelles sont les normes réelles. La valeur consiste à obtenir tout le monde sur une équipe à être cohérente, même si cela signifie faire une décision souvent arbitraire entre le faire mon ou le faire votre votre .
Voici quelques références que j'ai mentionnées ci-dessus:
temps de flux
C'est une bonne réponse, Robert. Merci. Je suis sûr que nous avons tous éprouvé des morceaux. Je sais que lorsque je cherche un code correctement formaté, par rapport à ce que je considère bien bien sûr, que je peux comprendre le code dans son ensemble. Mais dès que le code est légèrement formaté différemment (c'est-à-dire un support frisé qui ne s'ouvre pas là où je m'attends à ce qu'il soit) la capacité de la saisir dans son ensemble est parti, ce qui me permettra de passer à travers chaque ligne. Briser le flux illusoire est un autre grand point.
Le chunking a tendance à être plus négatif que positif de mon expérience car il fait que les programmeurs font des hypothèses sur la base de certaines consistantes qui sont fausses. Insister sur cette cohérence conduit à un code «meilleur» n'est pas concluant et n'a aucune réelle études à double double aveugle. Biais de confirmation.
"énormes avantages"? Ou "avantages"? Que voulez-vous dire par énorme? Le style standard est-il plus précieux que les tests d'unités automatisés? Plus précieux qu'une bonne langue? Plus précieux que le design simple et efficace?
@ S.Lott - Juste un peu d'hyperbole. Je préfère moi-même que les gens incompréhennent parfois cela aussi.
Je soupçonne que vous pourriez vous en soucier. Que se passe-t-il si le style de codage pour C a inclus de telles choses telles que "Pas de blancheur inutile (y compris de nouvelles lignes) autorisées"? Ou "Commentaires multi-mots décrivant que l'utilisation d'une variable doit apparaître mélangée à chaque lettre de la déclaration: par exemple, int t / * hauteur * / A / * de * / L / * caractère * / L; Ce sont des exemples extrêmes, mais je soupçonne que "ne pouvait pas s'en ficher moins" est une exagération. :)
@ S.Lott Ce n'est pas une comparaison de différentes pièces ou technologies du processus de développement de logiciels. Je tiens au fait que je pense que cela a d'énormes avantages d'une perspective de maintenance, de flexibilité inter-équipes et de pouvoir comprendre autrui au code sans devoir prendre le temps d'adapter votre reconnaissance de modèle intégrée à un style de codage inconnu.
@William Pursell peut-être que "ne pouvait pas s'en ficher moins" est un peu fort. Permet de dire dans la raison. Vous parlez de cas de bord qui ne voleraient jamais quand une entreprise dans son ensemble prévoit de concevoir une convention standard. Cela dit, je pense que je pourrais plus facilement m'adapter à une mauvaise convention qui est strictement appliquée par rapport à des centaines de conventions individuelles.