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

18

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.

derekerdmann
la source

Réponses:

12

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.

éponge
la source
3
Surtout # 2: lisibilité. Parfois, un morceau de code spécifique peut être rendu plus lisible en s'écartant de la directive.
Bart van Heukelom
Grâce aux IDE d'aujourd'hui, vous pouvez vous rapprocher de 100% si vous reformatez le code sur la base d'un modèle à chaque opération de sauvegarde. Eclipse le fait très bien.
Markus
1
@Markus, cela fonctionne jusqu'à ce que quelqu'un veuille utiliser un autre IDE ou éditeur. Je préfère le faire dans un hook pré-commit pour donner plus de liberté aux développeurs.
Gustav Karlsson
Fair point @GustavKarlsson, de cette façon, vous centralisez la mise en forme et créez un point de changement unique au cas où le "standard" changerait. Pour contourner le problème (avec plus d'efforts), vous pouvez toujours écrire un modèle supplémentaire pour le nouvel IDE.
Markus
5

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.

TheLQ
la source
5

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.

Robert Harvey
la source
Pourquoi avez-vous écrit votre propre norme de codage alors qu'il y en a tellement là-bas, et sont en fait standard pour le langage / framework utilisé?
Florian Margaine
2
Il n'a jamais été adopté - tadaa, et il y avait la déclaration que je cherchais en parcourant les réponses. C'est tout l'intérêt: plus il y a de personnes et plus la complexité et l'arbitraire des règles sont élevées, moins elles seront susceptibles d'être adoptées par la majorité de l'équipe. À moins que cela ne soit pas appliqué d'une manière ou d'une autre, comme Visual Studio ou le langage Go, les développeurs ont tendance à suivre leur propre esprit. J'attends depuis près de 10 ans maintenant l'IDE qui sépare le contenu du code du style du code.
JensG
2

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.

Facture
la source
4
Je dois être en désaccord. Je ne trouve rien de plus irritant qu'un IDE qui modifie le formatage par lui-même. Pourquoi devrais-je le laisser modifier mon code sans mon consentement? Il supprime une portion décente de contrôle que j'aime avoir sur mon travail.
derekerdmann
Bill, parlez-vous des conventions de dénomination par glisser-déposer que l'EDI génère telles que TextBox01? Ou voulez-vous dire un plugin Visual Studio comme Resharper?
spong
derek - oui, c'est ennuyeux, mais le temps que cela m'évite de ne pas avoir à y prêter attention 90% du temps vaut 10% du temps que je dois le combattre.
Bill
soleil - je voulais dire le formatage uniquement dans ce cas. Je serais d'accord avec les noms de contrôle par défaut sur drop uniquement s'il était extrêmement évident de savoir ce qui se passait. sous de nombreuses formes qui s'effondre après le deuxième contrôle. Je ne suis pas un grand fan de resharper, mais quand je l'utilise, je n'essaie pas non plus de corriger ce qu'il génère beaucoup. Ne combattez pas votre ensemble d'outils lorsque vous n'êtes pas obligé de le faire.
Bill
Il peut y avoir plusieurs IDE dans la même équipe - par exemple Eclipse et IDEA pour Java. Il faudrait un peu d'effort pour configurer le formatage du code sous forme de fichiers de configuration - mais cela en vaut la peine.
talonx
1

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.

Chris
la source
After taking a few minutes to apply our code format with them, they were quickly able to see the bug that they had missed before.Ce n'est pas parce que votre format de code les a aidés à voir le bogue. C'est parce que la tâche de reformater le code les a forcés à regarder attentivement le code qu'ils étaient en train de parcourir auparavant.
Brandin
1

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 source
0

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]

Audrius
la source
0

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.

mouviciel
la source
0

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.

Bryan Oakley
la source