Je sais qu'il a été prouvé qu'une norme de codage aide énormément. Cependant, il existe de nombreux outils et IDE différents qui formateront selon la norme que le programmeur préfère. Tant que le code est soigné / commenté (et pas un désordre de spaghetti), je ne vois pas la nécessité d'une norme de codage.

Y a-t-il des arguments pour le développement d'une norme de codage (nous n'en avons pas, mais j'en cherchais à en créer une)?

Cependant, il existe de nombreux outils et IDE différents qui formateront selon la norme que le programmeur préfère.

Bonne chance avec ça. D'après mon expérience, il existe un petit nombre d'outils (zéro!) Qui peuvent correctement reformater le code du format X au format Y. Il y a tout simplement trop de choses qui entravent. Onglets vs espaces, instructions sur plusieurs lignes, etc. Regardez simplement l'implémentation par GNU des fichiers de bibliothèque standard C ++. Ce que vous pouvez faire est de faire en sorte que votre IDE utilise toujours des espaces au lieu des tabulations et ne vous embêtez pas à reformater le code étranger. Maintenant, votre code ressemble à ce que vous aimez, et le code étranger ressemble à l'auteur d'origine.

Un style d'indentation spécifique est la dernière chose qu'une norme de codage doit spécifier. Cela frôle le début d'une guerre religieuse programmée. OMI, une norme de codage devrait spécifier une suite raisonnable de styles d'indentation acceptables, mais laisser les détails aux auteurs d'un paquet. Le style d'indentation est, ou devrait être, une infime partie d'une norme de codage. Règle numéro zéro des normes de codage: ne transpirez pas les petites choses. Le style d'indentation est une petite chose.

De plus grandes choses:

• Comment nommer les choses?
• Certaines parties de la langue sont-elles interdites?
• Le code doit-il être compilé proprement, et avec quels paramètres du compilateur?
• Le code doit-il passer certaines métriques?
• Quel type de test est nécessaire?
• Quel type de documentation est nécessaire, à la fois dans le code (commentaires) et ailleurs?
• Plus important encore, comment obtenir une dérogation à la norme?

Addendum
Peut-être encore plus important est ce qu'il ne faut pas mettre dans des normes de codage. Des sujets tels que la façon d'écrire les exigences n'appartiennent pas aux normes de codage. Les détails sur les tests n'appartiennent pas non plus. Un projet ne doit pas utiliser les normes de codage pour remplacer le plan de gestion de projet, le plan de gestion des tests, le plan de vérification et de validation, etc. Le but des normes de codage est d'améliorer la sécurité, la qualité, la compréhensibilité, la maintenabilité du code, et autres "ilités". Il existe de nombreuses façons de garantir que cela ne se produira pas. Quelques exemples: faire des normes un livre aussi complexe que les lois fiscales de certains pays, inciter à programmer des guerres de religion, avoir de mauvaises conventions de dénomination.

Les normes de codage peuvent avoir des conséquences imprévues. Exemple: un imbécile d'un ingénieur de projet va interpréter la «règle des nombres magiques» pour signifier cela if (index == 0) {...}et for (ii = 0; ii < 3; ++ii) {...}doit être changé en if (ZERO == index) {}et for (ii = ZERO; ii < NUMBER_OF_DIMENSIONS_IN_THE_UNIVERSE; ++ii) {...}ne riez pas. Je l'ai vu arriver. De nos jours, lorsque j'écris une norme de codage, c'est une "directive sans nombres magiques" plutôt qu'une règle pour contrer ce genre de folie.

La norme de codage n'est pas la défense numéro un contre un mauvais style de programmation / des pratiques de codage dangereuses. La révision du code est. Malgré de nombreuses années d'automatisation, il n'y a rien de mieux qu'un ensemble d'êtres humains quelque peu subjectifs qui regardent et jugent un morceau de code.

Les normes de codage ne concernent pas uniquement les paramètres privilégiés indent- elles incluent également les conventions de dénomination, les conventions de commentaire et un grand nombre de recommandations possibles pour les idiomes, l'utilisation des fonctionnalités de langage, etc.

Plus précisément, vous devez toujours documenter tout cela quelque part. Et enfin, tout le monde ne voudra pas utiliser un IDE qui reformate le code de cette façon ...

Si vous utilisez un style cohérent au sein d'une équipe, votre code devient plus facile à lire. Lorsque votre code sera plus facile à lire, votre équipe sera plus productive. Ils seront plus productifs car ils n'ont pas à analyser mentalement le code et peuvent se concentrer sur la logique plutôt que sur la syntaxe lors de la révision et de la maintenance du code.

Si chaque personne laisse l'EDI reformater le code à son choix, vous avez l'un des deux problèmes: soit vous devez vous assurer de toujours le reconvertir au format d'origine lors de la sauvegarde, soit souffrir du fait que votre diff affichera beaucoup de bruit, ce qui rend plus difficile de voir ce qui a changé dans la logique du code.

Réponse courte: Oui, cela reflète la qualité .

Qu'est-ce que c'est et pourquoi en avons-nous besoin?

Les normes de codage sont un élément très important d'un logiciel de haute qualité. Ils augmentent la productivité dans le processus de développement, facilitent la maintenance du code et empêchent le code d'être lié à une personne ou à une équipe. La cohérence dans la norme de codage différencie également le code créé prématurément de l'art bien conçu.

OK, chaque développeur sait que les conventions de codage sont bonnes. Mais d'où devraient provenir les normes?

Elle est principalement dictée par le vendeur propriétaire du produit. Chaque développeur peut choisir parmi de nombreuses normes de codage de l'industrie. Certaines sociétés Microsoft, Oracle et Sun Microsystems proposent des directives.

Y a-t-il des arguments pour le développement d'une norme de codage (nous n'en avons pas, mais j'en cherchais à en créer une)?

Oui, il est recommandé d'utiliser des normes de l'industrie. Cependant, chaque norme de codage est spécifique à la plate-forme de développement. Ainsi, les normes de codage sont pour la plupart spécifiques au langage. Par exemple, Java a un standard différent de .NET. Par exemple, C # .NET utilise ces normes dans cette référence .

Normes communes

Les normes communes ne dépendent d'aucun langage de programmation. En plus des normes proposées par le vendeur, alias les normes de codage de l'industrie mentionnées, il existe différentes notations de programmation comme la notation hongroise ou CamelCase . Je pense que les normes de codage Microsoft .NET étaient initialement basées sur les notations CamelCase.

Normes et directives de codage d'équipe

En théorie, chaque équipe de développement devrait convenir de normes de codage dès le démarrage du projet. Les directives de codage sont généralement créées par le chef d'équipe ou l'architecte en chef de l'entreprise. Il s'agit généralement d'un document ouvert à suivre et à améliorer en cas de besoin. Par exemple, dans notre entreprise, nous avons des pages Wiki où ce document est téléchargé et disponible pour les développeurs de l'entreprise.

Je vais prendre l'avis controversé et dire non, vous n'avez pas besoin d'une norme de codage . Soit les règles sont, comme vous le dites, des directives applicables à l'IDE, les meilleures pratiques générales que tout le monde dans chaque entreprise doit suivre, soit ce sont des appels de jugement au cas par cas par équipe qui doivent être effectués par plus d'une personne dans une équipe compétente. via la programmation en paire ou les revues de code.

Des choses comme Comment devrions-nous nommer cette variable? Quelles fonctionnalités linguistiques devrions-nous utiliser? Faut-il éviter? Quels tests sont les meilleurs? Il vaut mieux ne pas répondre à ces questions jusqu'à ce que nous rencontrions le problème étroitement défini sur lequel nous travaillons actuellement .

Cristallisé à partir de ces décisions minutieuses, des normes / modèles informels peuvent apparaître au sein des équipes, en fonction de l'intersection avec le domaine problématique actuel et les technologies utilisées. La codification de ces moyens signifie que nous pensons que des choses comme la norme de dénomination, le sous-ensemble de langues approprié, etc. utilisées sur ces projets, sur la base de centaines de micro décisions, et adoptées de manière informelle par ces équipes devraient guider chaque projet à l'avenir.

En principe, cela ressemble à une grande chose, mais en réalité, cela devient juste un aimant pour la politique. Quels outils pouvons-nous forcer tout le monde à utiliser? Qu'est-ce que je veux forcer les autres à éviter? Si tout le monde était d'accord sur ces questions, nous n'aurions pas besoin d'une norme. Nous le ferions juste. D'après mon expérience, les normes découlent du désir d'un sous-ensemble de développeurs d'exercer un contrôle sur un autre sous-ensemble. Généralement, ce type de politique et la police technologique qui en découle ne font qu'étouffer l'innovation plutôt que de fournir des orientations.

Si vous voulez de vrais conseils , au lieu de lire une norme avec un tas de règles inutiles, allez trouver des membres compétents de votre équipe et demandez-leur ce qu'ils en pensent. Par quoi ont-ils été brûlés? Comment vous suggèrent-ils d'écrire du code? Vous obtiendrez une variété de réponses utiles avec beaucoup d'expérience précieuse pour le sauvegarder. Vous verrez beaucoup d'intersections basées sur une expérience commune. Au lieu de la monoculture imposée par la norme, vous verrez également beaucoup de diversité qui ne peut que vous aider à voir de nombreuses façons valables de résoudre les problèmes.

Et lorsque quelqu'un vous dit de ne pas faire quelque chose à cause d'une règle dans la "norme" mais n'a aucune expérience ou sauvegarde raisonnable de sa réclamation, ignorez-le. Ici, la norme n'a servi personne ni fait de personne un meilleur développeur.

Maintenant que les avions commerciaux volent par fil, vous pouvez espérer que les programmes pilotant l'avion basés sur les entrées des pilotes fonctionnent. Lorsque les programmeurs écrivent un tel code, vous espérez qu'ils suivent un ensemble strict de règles pour éviter les erreurs de programmation souvent évitables. Une façon de le faire est d'utiliser une norme de codage.

Voir: Proposition de normes de codage C et C ++ de la Federal Aviation Administration

Dois-je en dire plus.

Remarque: je n'ai pas pu trouver la norme réelle de la FAA en ligne, mais je l'ai vue.

Pour moi, c'est une question de discipline et être discipliné aide toujours, c'est un reflet de la qualité du travail que vous produisez.

Cela dit, je ferais la norme de codage en gardant à l'esprit l'IDE et / ou les outils utilisés. En outre, l'IDE doit être configuré de manière identique (par exemple, l'IDE de chaque développeur doit utiliser tous les onglets ou tous les espaces blancs pour l'indentation et l'IDE de chacun doit avoir la même longueur d'onglet) pour chaque développeur afin que tout le monde puisse suivre la norme facilement ...

En outre, des scripts d'archivage pourraient être développés et utilisés, ce qui pourrait aider à respecter les normes de codage dans une certaine mesure, par exemple, ils peuvent corriger l'indentation avant de valider le fichier archivé dans le système de contrôle de version.

Les normes de codage ne pourraient PAS être plus importantes! Je suis un grand utilisateur de CakePHP et j'aime revoir les changements de version à version et les développeurs ne suivent pas les normes là-bas.

En fait, j'étais tellement bouleversé par les différences de style que j'ai dû écrire A Short Rant About Coding Conventions . Cela coûte beaucoup de temps et d'argent d'amener de nouveaux développeurs dans une équipe existante déjà - imaginez simplement faire venir un nouveau développeur sans normes ... apprendre le code serait ensuite trop impossible.