Quelle est l'importance des directives de formatage du code? [fermé]

Les normes de codage sont courantes dans toute organisation de développement de logiciels, mais dans quelle mesure sont-elles importantes à suivre? Je peux comprendre la nécessité d'une certaine cohérence, mais lorsque je traite de choses simples comme la position des accolades, la longueur de la ligne, etc., je ne suis pas sûr que des normes excessivement strictes contribuent beaucoup au développement de logiciels.

N'est-il pas plus important que votre code soit lisible, pas qu'il soit conforme à une norme prédéfinie? Il semble qu'ils ressemblent plus à ... des directives de toute façon.

Demander à tout le monde de respecter à 100% les mêmes directives de formatage de code standard, c'est comme demander à tout le monde de collaborer séparément pour écrire un papier de 100 pages avec le même style d'écriture.

J'espère que tout le monde rédigera l'article en anglais (ou dans la même langue), mais différents styles apparaîtront. Certains l'écriront bien, d'autres non. Certains utiliseront des contractions, certains épeleront les mots complètement (exemple: c'est vrai que c'est). Etc.

Je pense que vous avez abordé les points les plus importants:

1. C'est une ligne directrice
2. Lisibilité

Si vous voulez que le code respecte le même formatage, comme un papier dans le même style d'écriture, il devra être édité et révisé. Le code devra être nettoyé, révisé, remanié, etc.

Je n'ai jamais été dans une boutique où j'étais complètement satisfait du style de codage ou du formatage d'un autre développeur (au minimum car ce n'est pas exactement le mien). Mais je serai content si je peux le lire / le comprendre et s'il est cohérent. Tout le reste est le sucre sur le sucre syntaxique.

Donc, pour répondre à votre question: un peu important, mais ce n'est certainement pas la fin du monde si ce n'est pas le cas.

Pour les normes de formatage, je suis ce que tout le monde fait. S'ils utilisent PascalCase pour tout, alors j'utilise PascalCase. S'ils utilisent _camelCase, j'utilise _camelCase. Pourquoi? Parce que cela limite la quantité de reformatage que je fais et limite ce que les autres doivent faire pour le rendre "beau". Les normes de formatage sont généralement là pour faciliter les choses pour tout le monde.

Dans mon travail actuel, l'une de mes premières tâches a été de trouver une norme de codage pour notre groupe de développement.

Mon premier effort a duré une soixantaine de pages (il a incorporé une grande partie des directives de Framework de Microsoft). On m'a demandé de le réduire, et mon effort suivant a duré dix pages, en utilisant des idées provenant de diverses bonnes sources. On m'a demandé de le réduire à nouveau, et finalement je l'ai réduit à trois ou quatre pages, je pense.

Il n'a jamais été adopté.

Pourquoi? Parce que je travaille avec beaucoup de gens vraiment intelligents, qui suivent déjà instinctivement une norme de codage sensée.

Pour ma part, je suis les directives généralement acceptées de Microsoft et émule les styles couramment utilisés par d'autres (Javascript et jQuery sont formatés différemment de C #, même s'ils sont tous deux des langages à accolades). Je brise également les règles de temps en temps, ce qui rendra le code plus lisible.

Si vous utilisez et l'IDE qui fait les bases de cela pour vous (Visual Studio par exemple), laissez l'IDE faire sa chose et tout ce qui semble toujours difficile à regarder vous modifie tant que vous laissez encore l'IDE faire sa chose ou la prochaine personne qui le formatera automatiquement le tuera de toute façon.

Ce qui est le plus lisible pour une personne ne sera pas pour tout le monde.

Si vous n'utilisez pas ce type d'IDE, obtenez-en un. Même y penser pendant plus de 10 minutes est un gaspillage de ressources à mon humble avis.

Je pense qu'il y a un avantage non mentionné à aider à comprendre rapidement le code. Plus la mise en forme du code est similaire dans un projet et tous les développeurs, plus vous serez en mesure de travailler avec le code (et plus inconsciemment).

J'ai eu des développeurs juniors qui sont venus me voir après avoir essayé de gérer même des bugs simples pendant une longue période. Après avoir pris quelques minutes pour appliquer notre format de code avec eux, ils ont rapidement pu voir le bug qu'ils avaient manqué auparavant.

La lisibilité est certes importante. Si vos normes de format de code sont bien pensées et correctement utilisées, vous constaterez peut-être que vous pouvez aller au-delà de la simple lecture du code et de la compréhension du code encore plus rapidement.

Un ensemble de directives que j'utilise lors du développement ou de la mise à jour de nos formats de codage est les principes de groupement Gestalt - http://en.wikipedia.org/wiki/Gestalt_psychology#Gestalt_laws_of_grouping

Comme résultat direct / exemple, notre formatage de code requiert que tout code de bloc (if, switch, etc.) ait l'accolade ouverte sur la ligne suivante, de sorte qu'il s'aligne avec l'accolade de fermeture:

if(true)
{
}

Avec le raisonnement selon lequel selon le principe de symétrie, votre esprit verra les accolades ouvertes et fermantes et pourra plus rapidement percevoir le bloc de code naturellement.

Peu importe la langue ou l'outil que vous utilisez, trouvez quelque chose. Configurez votre IDE et archivez le fichier de configuration.

Lorsque quelqu'un extrait le projet, il utilise les mêmes styles de mise en forme. Peu importe le style, seulement qu'il soit cohérent. J'ai mes propres préférences en ce qui concerne les espaces contre les tabulations et la ligne sur laquelle les accolades continuent. Mais plus que mes propres préférences, je me soucie juste qu'un fichier de code source donné soit d'accord avec lui-même. Il le rend tellement plus lisible qu'il ne s'agit d'un méli-mélo résultant d'une guerre des formats.

La pire chose que j'ai rencontrée jusqu'à présent n'utilise aucune norme de codage. Et il vous est interdit de rendre certains blocs de code plus lisibles car ils cassent les outils de diff ... Parce que nous utilisons des correctifs pour appliquer les changements (demande de changement / correction de bogue -> correction / changement -> correctif -> correctif appliqué par une personne de "confiance") -> commit) vous pouvez obtenir un code source assez amusant (du point de vue de la lisibilité). Au moins, nous n'avons personne utilisant des variables à deux lettres (-.

[diatribe] Le plus drôle, c'est que tout le monde convient que nous devons changer cela. Il y a même eu quelques tentatives de reformatage (automatisées lors de la validation), mais parce qu'une seule petite option de formatage itsy bitsy est manquante - le tout vient de passer. Vue ... [/ diatribe]

Les directives aident à améliorer la qualité du code:

• du point de vue de l'auteur: de nombreuses règles visent à réduire l'introduction de bogues. Par exemple, une règle indiquant que if()ou les for(;;)constructions doivent être suivies par un bloc et non par une seule instruction, rend explicite l'intention du codeur initial et aide les codeurs suivants à le maintenir.

• du point de vue du lecteur: le code qui suit les directives convenues est examiné plus efficacement que le code avec différents styles. L'évaluateur sait mieux avec moins d'efforts où chercher d'éventuels bogues.

Il n'y a pas de norme universelle pour ce qu'une équipe devrait ou ne devrait pas faire. Certaines équipes doivent suivre des directives strictes, d'autres non.

Le fait est que vous devez travailler ensemble en équipe et décider de ce qui est le mieux pour votre équipe . Le code doit être facile à lire, car il est lu des ordres de grandeur plus de fois qu'il n'est écrit. Si votre équipe a besoin de conseils pour créer du code lisible, respectez une norme de codage. Sinon, non.

Cela étant dit, je pense que la plupart des équipes gagneraient à s'entendre sur une façon standard de nommer les variables, les fonctions et les classes, les accolades de position, etc. Si l'équipe ne parvient pas à s'entendre sur quelque chose d'aussi simple que cela, comment peut-elle s'attendre à se rassembler et à prendre les décisions vraiment importantes? De plus, votre équipe ne sera pas toujours composée des mêmes personnes - des personnes partent, de nouvelles personnes sont embauchées. Plus il est facile pour les nouvelles personnes de maîtriser la base de code, plus vite elles peuvent contribuer à l'équipe sans abaisser la qualité du code.