Votre entreprise a-t-elle une norme de codage? [fermé]

J'ai récemment vu que Microsoft a publié un document sur les normes de codage (normes de codage du cadre de code tout-en-un ) et cela m'a fait réfléchir ... La société pour laquelle je travaille n'a aucune norme de codage officielle. Il n'y a que quelques développeurs et nous avons été ensemble assez longtemps pour avoir évolué vers des styles similaires et cela n'a jamais été un problème.

L'entreprise pour laquelle vous travaillez a-t-elle des normes de codage documentées? Si non, pourquoi pas? Le fait d'avoir une norme fait-il une différence? Vaut-il la peine d'écrire une norme à partir de zéro ou devez-vous adopter une autre norme comme la vôtre (c.-à-d. Faire les normes de Microsoft les vôtres)?

Il est important pour une équipe d'avoir une seule norme de codage 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 provoquer des guerres d'enregistrement entre les développeurs.
• Voir différentes normes dans la même classe peut être extrêmement irritant.

Je suis un grand fan de ce que l' oncle Bob a à dire sur les normes:

1. Laissez-les évoluer au cours des premières itérations.
2. Qu'ils soient spécifiques à l'équipe plutôt qu'à l'entreprise.
3. Ne les écrivez pas si vous pouvez l'éviter. Laissez plutôt le code être la façon dont les normes sont capturées.
4. Ne légiférez pas sur une bonne conception. (par exemple, 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, rassemblez l'équipe pour décider.

Je pense qu'il est essentiel d'avoir une norme de codage, même si tout ce qu'il dit est "nous utilisons l'indentation à 3 espaces et les crochets ouverts vont à la ligne suivante." Quelques avantages:

• Cela rend la lecture de l'ensemble de la base de code beaucoup plus facile, car le basculement entre les styles de codage entre les fichiers est ennuyeux.
• Cela facilite la lecture d'un seul fichier, car tout fichier mis à jour par deux développeurs avec des styles conflictuels aura finalement tendance à mélanger ces styles. Lire un fichier qui mélange des tabulations et des espaces (et le modifier plus tard) est une douleur dans le cul.
• Cela permet aux nouveaux développeurs d'utiliser plus facilement un bon style s'il existe une norme explicite, plutôt qu'implicite.
• Des conventions de dénomination cohérentes facilitent la recherche de fonctions / variables. Était-ce ArraySort ou array_Sort ou sortTheArray ou doSortArray ou ...?

En ce qui concerne l'adoption d'une norme existante, peu importe - la cohérence est ce qui est important. Si vos développeurs ont une douzaine de styles différents, vous pouvez aussi bien en choisir un existant, publié. Si vous avez tous évolué vers un style assez cohérent, notez-le et utilisez-le.

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

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

Je ne peux vraiment pas me tenir debout lorsque les programmeurs C écrivent du code Java avec un formatage C. Non seulement cela ne ressemble pas à Java, mais cela les fait croire qu'ils peuvent utiliser d'autres pratiques de type C en Java.

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

Mon ancien employeur a une norme de codage. J'envisage d'en documenter officiellement un pour moi aussi.

Ou, comme vous le suggérez, trouver une norme existante décente et la modifier / l'adopter. Pour une entreprise, je suggérerais certainement d'examiner les normes de codage existantes, mais d'en créer / modifier une pour leurs besoins particuliers. Il n'est pas nécessairement nécessaire d'en créer un à partir de zéro, mais il convient de veiller à ce que la norme de codage soit adaptée au type de logiciel créé par l'entreprise.

Oui, avoir une norme de codage fait une différence, mais ce n'est pas une solution miracle. Le code est plus lisible car il n'y a pas autant de conflits de styles différents et certaines erreurs / pièges courants peuvent être évités. Même avec une norme, vous aurez une certaine variation dans les styles de codage, mais cette variabilité sera réduite. Le but n'est pas d'essayer d'éviter toute variation ou de se préparer à chaque situation possible. Un standard de codage trop compliqué peut être pire que pas du tout.

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

Mais, pire encore, quelqu'un écrit des noms de variable et de classe en italien, quelqu'un d'autre en anglais ...

J'adapte toujours mon style à celui du langage, de la bibliothèque et du framework que j'utilise, afin qu'un code source soit uniforme et clair.

Gardez à l'esprit qu'il s'agit d'un document de normes de codage spécifique au cadre de code tout-en-un.

J'ai travaillé dans diverses entreprises, dont certaines avaient une norme existante et d'autres (la plupart) dont j'ai aidé à l'élaboration de la norme. Pour la plupart, si vous faites du développement basé sur .NET (et même si vous ne l'êtes pas, la plupart des règles s'appliquent toujours), vous devriez jeter un coup d'œil aux directives de conception du cadre . Bien que cela soit spécifique à l'écriture d'API accessibles au public, la plupart des directives s'appliquent également à tout code.

La plus grande préoccupation avec les normes de code est de le garder relativement simple et direct. Vous voulez que les développeurs puissent internaliser les directives présentées, donc leur donner un document de plus de 50 pages est inutile. Vous pouvez toujours créer ce document si vous souhaitez fournir un arrière-plan, des exemples, etc., mais vous voudrez également quelque chose qui se résume à un ensemble de directives à puces. Votre norme de codage doit également être un document évolutif et flexible qui doit changer à mesure que la technologie évolue.

Les discussions sur la norme de codage se résument à ceci:

• Oui, vous en avez besoin, la cohérence et le code propre sont la pierre angulaire d'un 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 le vôtre, vous vous retrouvez dans une discussion sans fin et douloureuse. Il y en a beaucoup qui sont populaires.
• L'utilisation de normes publiques (comme celles de MSDN ) vous donne une tierce partie agnostique avec laquelle vous ne pouvez pas vous disputer. Si vous souhaitez discuter avec eux, reportez-vous au point 2.

Si vous développez en C # dans Visual Studio, alors StyleCop est une solution miracle. Si vous utilisez également ReSharper, le plugin StyleCop for ReSharper est tout simplement génial.

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

Maintenant, Paul Graham et ses amis sont beaucoup plus intelligents que nous, mais nous, les programmeurs de blub, nous pouvons tous nous lire mutuellement, en fait, tout programmeur de blub peut lire notre code de blub.

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

Si nous programmons en C ou C ++ (nous sommes tous multilingues, même si nous programmons en blub), nous utilisons principalement le style blub pour le nouveau code, ou pour les choses open source, la norme du projet dans lequel nous travaillons.

Vous avez besoin d'une norme. J'ai vu différentes normes dans différents coins d'une application qui avaient des pistes différentes qui voulaient toutes le faire "à leur manière". Peut-être le concept de "standard" a-t-il été mal compris. Très fou. Et, les pires normes sont générées par une seule personne. Peu importe qui est cette personne, si une seule personne élabore la norme, il est presque certain qu'elle est mauvaise.

Cela peut aider les gens, cela peut aussi vraiment aider avec les outils:

Si vous voulez pouvoir utiliser n'importe quel type de formatage automatique de code, vous devez vraiment standardiser les règles qu'il va utiliser, sinon vous obtiendrez constamment de nombreux changements de formatage insignifiants encombrant vos différences.

Les ensembles de règles par défaut pour les outils d'analyse statique peuvent très bien vérifier un style de dénomination spécifique, et il est probablement plus facile de se conformer à cela, puis d'écrire un tas de nouvelles règles. (sauf si vous allez tout simplement désactiver la règle)

enfin, il 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 droit d'auteur standard dans vos en-têtes car vous ne voulez pas exécuter chaque nouveau fichier que vous écrivez devant l'équipe juridique de votre entreprise, et vous voulez certainement obtenir les noms de toute API publique dès la première fois