it-swarm-fr.com

Votre entreprise a-t-elle une norme de codage?

J'ai récemment vu que Microsoft a publié un document de normes de codage ( normes de codage de codes tout-en-un ) et cela m'a fait penser ... La Société que je travaille n'a pas de normes de codage formelles du tout. Il n'y a que quelques développeurs et nous avons été ensemble assez longtemps pour avoir évolué dans des styles similaires et ce n'est jamais un problème.

L'entreprise que vous travaillez pour avoir des normes de codage documentées? Si non, pourquoi pas? Avoir une norme fait une différence? Est-ce que cela vaut la peine d'écrire une norme à partir de zéro ou devez-vous adopter une autre norme comme la vôtre (c.-à-d. Faites de la conformité de Microsoft)?

31
Walter

Il est important que une équipe ait une norme de codage unique pour chaque langue afin d'éviter plusieurs problèmes:

  • Un manque de normes peut rendre votre code illisible.
  • Le désaccord sur les normes peut causer des guerres d'enregistrement entre les développeurs.
  • Voir différentes normes dans la même classe peut être extrêmement irritante.

Je suis un grand fan de ce que oncle Bob doit dire sur les normes:

  1. Laissez-les évoluer pendant les premières itérations.
  2. Laissez-les être spécifiques à l'équipe au lieu de la société spécifique.
  3. Ne les écrivez pas si vous pouvez l'éviter. Laissez plutôt le code de la manière dont les normes sont capturées.
  4. Ne légiférez pas de bonne conception. (E.G. Ne dites pas aux gens de ne pas utiliser goto)
  5. Assurez-vous que tout le monde sait que la norme concerne la communication, et rien d'autre.
  6. Après les premières itérations, demandez à l'équipe pour décider.
39
Paddyslacker

Je pense qu'il est essentiel d'avoir une norme de codage, même si tout ce qu'il est indiqué, c'est "Nous utilisons une indentation à 3 espaces et des supports ouverts allant sur la ligne suivante." Quelques avantages:

  • Il rend la lecture à travers l'ensemble de la base de code beaucoup plus facile, car la commutation entre les styles de codage entre les fichiers est ennuyeux.
  • Il facilite la lecture d'un seul fichier, car tout fichier mis à jour par deux développeurs ayant des styles en conflit tendra éventuellement avoir mélangé ces styles mélangés. Lecture via un fichier qui mélange des onglets et des espaces (et la modifiant plus tard) est une douleur dans le cul.
  • Il est plus facile que de nouveaux développeurs utilisent un bon style s'il existe une norme explicite plutôt qu'en implicite.
  • Les conventions de dénomination cohérentes facilitent la recherche de fonctions/variables. Était-ce arrayé ou array_sort ou SortHearRay ou Dosortarray ou ...?

En ce qui concerne l'adoption d'une norme existante, cela n'a pas vraiment d'importance - la cohérence est ce qui est important. Si vos développeurs ont une douzaine de styles différents, vous pourriez aussi bien choisir un existant, publié un. Si vous avez tous évolué dans un style assez cohérent, écrivez-le et utilisez-le.

8
Fishtoaster

Je ne suis pas d'accord avec le "Nous sommes une boutique X", donc nous formatons notre code dans toutes les langues de la même manière.

Personnellement, j'ai trouvé que la plupart des langues ont des styles acceptés différents.

Je ne peux vraiment pas supporter quand c programmeurs écrit Java code avec le formatage C. Non seulement cela ne ressemble pas à Java, mais il les imite à penser qu'ils peuvent utiliser d'autres pratiques de type C dans Java.

Je pense que si vous avez une norme, cela devrait être par langue

5
sylvanaar

Mon ancien employeur a une norme de codage. Je considère comme formellement en documentant un pour moi-même.

Ou, comme vous le suggérez, trouvez une norme existante décente et de modifier/adopter cela. Pour une entreprise, je suggérerais certainement qu'ils examinent les normes de codage existantes, mais créeront/modifier un pour leurs besoins particuliers. Il n'est pas nécessairement nécessaire de créer un à zéro, mais il convient de veiller à ce que la norme de codage soit logique pour le type de logiciel que la société crée.

Oui, avoir une norme de codage fait une différence, mais ce n'est pas une balle d'argent. Le code est plus lisible car il n'y a pas autant de caractères de style différents et que certaines erreurs/pièges courantes peuvent être évitées. Même avec une norme, vous aurez une variation des styles de codage, mais cette variabilité sera réduite. L'objectif n'est pas d'essayer d'éviter toute variation ou de préparer toutes les situations possibles. Trop compliqué Une norme de codage peut être pire que rien du tout.

2
George Marian

Malheureusement non. Donc, tout le monde a sa propre façon d'utiliser l'espacement, l'indentation, etc., tout mélange (de cette façon, nous n'avons même pas à utiliser la fonction "blâme" pour savoir qui est l'auteur d'une ligne de code!)

Mais, même le pire, quelqu'un écrit des noms de variables et de classe en italien, quelqu'un d'autre en anglais ...

J'adapte toujours mon style à celui de la langue, la bibliothèque et le cadre que j'utilise, de sorte qu'un code source a l'air uniforme et simple.

1
Wizard79

N'oubliez pas que ceci est un document de normes de codage qui est spécifique dans le cadre de code tout-en-un.

J'ai travaillé dans diverses entreprises, dont certaines possédaient une norme existante et certaines (la plupart) que j'ai aidées à développer la norme. Pour la plupart, si vous faites du développement basé sur .NET (et même si vous n'êtes pas non plus, la plupart des règles s'appliquent toujours), vous devez consulter les lignes directrices Cadre de conception . Bien que cela soit spécifique à l'écriture des API face au public, la plupart des directives s'appliquent également à n'importe quel code.

La plus grande préoccupation des normes de code est de le garder relativement simple et simple. Vous voulez que les développeurs puissent internaliser les lignes directrices présentées, ce qui leur donne un document de plus de 50 pages est inutile. Vous pouvez toujours créer ce document si vous souhaitez fournir des antécédents, des exemples, etc. mais vous voudrez également quelque chose qui se résume à un ensemble de lignes directrices à bottine. Votre norme de codage doit également être un document de vie flexiBile et vivant qui doit changer en tant que changements de technologie.

1
Scott Dorman

Vous avez besoin d'une norme. J'ai vu des normes différentes dans différents coins d'une demande qui avait des pistes différents qui voulaient tous le faire "leur chemin". Peut-être que le concept de "standard" a été mal compris. Très fou. Et les pires normes sont générées par une personne. Peu importe qui cette personne est, si une personne seule développe la norme, il est presque assuré d'être mauvais.

1
anon

Cela peut aider les gens, cela peut également aider avec les outils:

Si vous souhaitez pouvoir utiliser une sorte de formatage automatique du code, vous devez vraiment normaliser les règles que vous allez utiliser, sinon vous obtiendrez constamment beaucoup de changements de formatage sans signification encombrant vos diffs.

Les ensembles de règles par défaut pour les outils d'analyse statiques peuvent bien vérifier un style de nommage spécifique, et c'est probablement plus facile tout autour de se conformer à cela puis écrivez un groupe de nouvelles règles. (sauf si vous allez simplement éteindre la règle)

enfin, c'est bon de normaliser tout ce qui doit être consulté avec quelqu'un en dehors de votre équipe. C'est-à-dire que vous voulez probablement un avis de copyright standard dans vos en-têtes car vous ne voulez pas exécuter tous les nouveaux fichiers que vous écrivez après votre équipe juridique de vos entreprises et que vous souhaitiez certainement obtenir les noms de toute API publique à droite pour la première fois

1
jk.

Codage Les discussions standard se présentent à ceci:

  • Oui, vous avez besoin d'eux, la cohérence et le code de nettoyage est une pierre angulaire du bon développement.
  • Ce qu'ils sont presque n'a pas d'importance, tant que tout le monde suit les mêmes normes.
  • N'écrivez pas la vôtre, vous vous retrouvez dans une discussion sans fin et douloureuse. Il y a beaucoup de choses qui sont populaires.
  • Utiliser des normes publiques (comme celles sur MSDN ) vous donne une tierce partie agnostique qui ne peut pas être disputée. Si vous voulez discuter avec eux, reportez-vous au point 2.

Si vous développez en C # dans Visual Studio, alors stylécop est une balle d'argent. Si vous utilisez également RESHARPER, alors le plugin stylécop pour resharper est juste génial.

1
dwynne

Nous sommes un magasin de blub, nous utilisons donc les conventions de programmation Blub.

Maintenant, Paul Graham et les amis sont beaucoup plus intelligents que nous, mais des programmeurs américains Blub, nous pouvons tous lire les autres Blub, en fait, tout programmeur Blub peut lire notre code de flaquage.

En fait, en raison de la conception de BLUB, tout programmeur Blub peut lire n'importe quel fichier Blub et la comprendre, car Blow n'a pas eu de système macro.

Si nous programmons en disant, C ou C++ (nous sommes tous multilingues, même si nous programmons dans Blub), nous utilisons principalement un style blub pour le nouveau code ou pour des éléments open source, la norme du projet dans lequel nous travaillons.

1
Tim Williscroft