Peut-il y avoir trop d'uniformité dans les normes de codage?

12

Existe-t-il une trop grande uniformité? Là où je travaille, nous avons bien sûr des normes, notamment des conventions de dénomination, des architectures, des cadres à exploiter, etc.

Par exemple, écrire des ifinstructions sur plusieurs lignes par rapport à une ligne, en utilisant l' ??opérateur de coalescence nulle c # au lieu de dire == null, les quantités d'espacement pour les indentations, etc.

Il me semble que cela commence à devenir un choix de style personnel et n'a pas besoin d'être uniforme dans une équipe ou une entreprise. Ce qu'une personne pense en lit plus clairement, une autre ne le peut pas. Y a-t-il une valeur à cette uniformité "supplémentaire"?

programming-practices team coding-standards

— Gratzy
source

2

Salut Gratzy, Programmers.SE n'est pas un forum de discussion ; nous sommes là pour résoudre les vrais problèmes que vous pourriez rencontrer. Avez-vous un problème réel que vous essayez de résoudre? Si oui, pouvez-vous reformuler votre question pour garder les réponses constructives et éviter les pièges de devenir une discussion?

1

@Gratzy pour le dire autrement, étant donné une situation à laquelle vous êtes personnellement confronté, quels seraient les critères pour une réponse correcte?

2

@Mark Trapp selon la FAQ ce sont les critères d'une question Toutes les questions subjectives devraient être constructives. Comment définissons-nous cela? Questions subjectives constructives… 1. inspirer des réponses qui expliquent «pourquoi» et «comment». 2. ont tendance à avoir des réponses longues et non courtes. 3. avoir un ton constructif, juste et impartial. 4. invitez à partager vos expériences plutôt que vos opinions. 5. insister pour que l'opinion soit étayée par des faits et des références. 6. sont plus qu'un simple plaisir social insensé. Je crois que ma question couvre au moins les 4 premiers

— Gratzy

2

@Gratzy également de la FAQ: "Vous ne devez poser que des questions pratiques et fiables basées sur les problèmes réels auxquels vous êtes confronté. Les questions ouvertes et bavardes diminuent l'utilité de notre site et repoussent les autres questions de la première page."

2

@Mark Trapp J'ai déjà énoncé des critères pour une réponse acceptable et oui, comme je l'ai dit, c'est un problème réel et très franchement de l'intérêt pour la question et les réponses, je dirais que les autres sont d'accord.

— Gratzy

16

L'uniformité n'est pas un problème (c'est bien) mais la rigidité ou l'inflexibilité peuvent l'être. Si, en recherchant l'uniformité, vous devenez dogmatique, le mal que vous faites à l'équipe peut être plus grand que le bien qui provient de l'uniformité (éventuellement) qui en résulte.

Il est préférable de définir un style de base pour les choses les plus importantes (normes de dénomination et de capitalisation, indentation, nouvelles lignes et placement des crochets, etc.), de définir des recommandations pour les choses moins importantes (si le format de l'instruction, d'autres espaces autour des parenthèses, etc.) , puis ne vous inquiétez pas du reste.

— Nicole
source

1

J'y suis allé

+1, a dit ce que je voulais dire, mais en mieux!

— FrustratedWithFormsDesigner

@Pierre, c'est pour ça que vous êtes freelance maintenant? :)

— Nicole

pas vraiment, mais j'ai rencontré beaucoup de gens obsédés par les directives. C'est effrayant à quel point cela peut être extrême. Je pense que vous avez assez bien défini la limite.

7

Lorsque potentiellement des dizaines de personnes travaillent sur un projet au cours des années de sa durée de vie, cela devient parfois déroutant lorsque vous devez changer de style. Imaginez-vous en train de lire un livre où différents chapitres sont écrits par différents auteurs qui ne maintiennent que quelque peu le style d'écriture. C'est possible, mais c'est ennuyeux.

La plupart des IDE peuvent appliquer des styles de nos jours, donc si nécessaire, vous pouvez distribuer (en tant que partie du code source du projet) un fichier de préférences IDE qui spécifie le style de codage choisi et que tout le monde installe et utilise pour formater le code qu'ils écrivent . Je parie qu'il y a même des façons de reformater / styliser le code à l'enregistrement (bien que je n'ai pas encore eu à enquêter).

— FrustratedWithFormsDesigner
source

Ouais, tu pourrais probablement coller un script de fourmi quelque part.

— Michael K

1

IntelliJ, au moins, a une option pour reformater le code avant l'archivage.

— Nicole

3

Un cas de sur-uniformité que j'ai vu est d'avoir une norme unique qui s'applique à tous les langages de programmation indépendamment de leur pertinence:

Décourager gotomême dans des langues comme C sans try... catch.
Utilisation de InitialCapsnoms (comme dans MFC et C # de Microsoft) dans JavaScript où se trouve la bibliothèque standard initialLowerCase.

— dan04
source

2

Je ne pense pas qu'il y ait trop d'uniformité. Cependant, je trouve souvent que trop de SPÉCIFICITÉ dans les normes de codage. Les avantages pour tout le monde de mettre l'accolade d'ouverture sur une ligne distincte sont au mieux douteux et ne l'emportent pas sur le temps passé à en discuter ou à résoudre les problèmes cosmétiques dans le code.

— JohnFx
source

2

@Tungano Je ne pourrais pas être plus d'accord. Le paradoxe des normes de codage est qu'elles en valent la peine, mais elles ne valent pas la peine d'être discutées.

— Charles E. Grant

3

Je ne vois pas comment le fait de forcer un style particulier dans la gorge d'un programmeur va vous aider à éviter ces arguments. En fait, je dirais que faire en sorte qu'un programmeur s'adapte à un style qu'il n'aime pas ENCOURAGE ces arguments, ou du moins le ressentiment.

— JohnFx

1

@JohnFx, car la plupart des programmeurs se rendront compte que la cohérence du style contribue beaucoup plus à la qualité et à la maintenabilité du code que tout choix de style particulier. D'après mon expérience, vous pouvez faire un décompte rapide de l'équipe, voir ce que les gens aiment et n'aiment pas et arriver rapidement à un consensus. Parfois, quelqu'un aura un bugaboo particulier et vous les hébergerez, puis ils céderont au bugaboo de quelqu'un d'autre. Si je me retrouve à haranguer l'équipe pendant cinq minutes sur les raisons pour lesquelles l'étui à chameaux est diabolique, je l'abandonne et je cède le pas pour tester ma flexibilité personnelle.

— Charles E. Grant

1

Je suppose que la plupart des programmeurs pensent que la cohérence du style apporte une telle contribution, mais ce n'est vraiment pas le cas. Il semble que cela devrait être le cas, il est ennuyeux de regarder du code qui ne correspond pas au style de votre animal de compagnie, et passer par un bloc de code "le nettoyer" pour des problèmes cosmétiques mineurs est un bon moyen de tergiverser. Écoutez, je faisais aussi partie de ce mouvement jusqu'à ce que je réalise que je me concentrais sur le placage à l'or et non sur le livrable.

— JohnFx

1

Je travaille avec du code de notre équipe allemande, quelques projets OSS et du code ancien que nous avons ainsi que nos trucs actuels. Certains sont C, certains C ++, certains C #. Je dois donc travailler avec plusieurs styles de code différents tout le temps. Lorsque vous faites cela, vous vous rendez compte à quel point les directives de style imposées dans les normes sont mesquines. Si je peux passer d'un projet à un autre, je peux gérer quelqu'un qui place son {} à différents endroits. C'est pourquoi je pense que la seule norme qui en vaille la peine est celle avec 1 règle: "la cohérence au sein de chaque projet".

— gbjbaanb

2

J'aurais 2 arguments pour l'uniformité:

Promouvoir la propriété collective. Que quelqu'un puisse aller éditer le code de quelqu'un d'autre sans craindre que le «bébé» de quelqu'un soit sur le point d'être blessé par le changement. Une sorte de mentalité "Nous sommes tous dans le même bateau".
Facilité d'y ajouter. Si quelque chose a déjà été fait ailleurs, cela peut être pris et réutilisé éventuellement. Certaines conventions peuvent aider à rendre les choses plus faciles à lire ou à changer parfois, c'est donc un autre avantage pour moi.

— JB King
source