Pourquoi oncle Bob suggère-t-il que les normes de codage ne soient pas écrites si vous pouvez les éviter?


145

Pendant que je lisais cette question , la réponse la plus votée citait Oncle Bob sur les normes de codage , mais cette astuce me laissait perplexe:

  1. Ne les écrivez pas si vous pouvez l'éviter. Laissez plutôt le code être la manière dont les normes sont capturées.

Cela a rebondi dans mon cerveau, mais je n’ai pas pu trouver un endroit où coller. Si une nouvelle personne se joint à l'équipe ou si les normes de codage changent, ne pourrait-il pas y avoir confusion des informations?

Pourquoi ne devrais-je pas écrire une norme de codage?


47
Hmm. J'essaie d'imaginer comment cela fonctionnerait dans une grande multinationale avec des centaines de développeurs et une base de code couvrant plusieurs décennies.
Matthew James Briggs

31
@ MatthewJamesBriggs: cela fonctionne aussi bien qu'un standard écrit que la plupart des développeurs ignorent, ou dont le contenu était différent au moment de l'écriture initiale du code.
Doc Brown

7
@ MatthewJamesBriggs: d'accord. Le guide de style doit contenir suffisamment d'informations pour reconnaître les conventions précédentes qui sont désormais obsolètes. Sinon, la culture de "copie du style existant" trouvera une horreur vieille de 10 ans à ressusciter. De plus, lorsque des cliques se forment accidentellement et utilisent des spécimens différents et incompatibles pour déduire le style officiel, le guide de rédaction écrit indique lequel d'entre eux est correct (ou, idéalement, empêche la formation de la clique en premier lieu). Et si certains de vos centaines de développeurs ne lisent pas la documentation, dans une grande entreprise, vous pouvez simplement les renvoyer pour un manque total de ressources.
Steve Jessop

14
Pour être juste, Bob a également déclaré que vous ne devriez pas avoir de norme de codage à l’échelle de l’entreprise, écrite ou non. Au contraire, chaque équipe / clique devrait développer la sienne.
Steve Jessop

37
Au lieu d'écrire un document que personne ne lira, utilisez un linter qui impose le code d'une certaine manière. Si cela fait partie de votre processus de développement, c'est inévitable.
Seiyria

Réponses:


256

Il y a quelques raisons.

  1. Personne ne lit la documentation.
  2. Personne ne suit la documentation même s’ils la lisent.
  3. Personne ne met à jour la documentation, même s’ils la lisent et la suivent.
  4. Écrire une liste de pratiques est beaucoup moins efficace que de créer une culture.

Les normes de codage ne traitent pas de ce que les gens devraient faire, mais de ce qu'ils font réellement . Lorsque les utilisateurs s’écartent des normes, cela devrait être pris en compte et modifié grâce à un processus de révision du code et / ou à des outils automatisés.

N'oubliez pas que le but des normes de codage est de nous faciliter la vie. Ils constituent un raccourci pour notre cerveau afin que nous puissions filtrer les éléments nécessaires des éléments importants. Il est bien préférable de créer une culture de contrôle pour le faire respecter que de le formaliser dans un document.


11
Et si vous souhaitez appliquer des règles, vous devez avoir une étape de processus de construction qui les applique, et non un guide de style.
Wayne Werner

31
N'avez-vous pas vraiment de document standard, mais juste crier après les premières semaines à chaque révision de code? Il semble que vous vous attendiez essentiellement à ce que les débutants modifient vos guides de style de codage. Ou est-ce plus un hypothétique "Je pense que c'est ce qu'il voulait dire"? Maintenant, s’il s’agit d’outils automatiques appliquant ces règles - convenu, c’est essentiel. Mais je ne veux pas avoir à comprendre péniblement les règles.
Voo

13
@Voo, pourquoi pensez-vous que vous devez crier lors de la révision du code si un problème survient?
Jaap

20
@ Jaap Je pensais que l'hyperbole était évidente .. apparemment pas. Non, ne pas crier après les gens, mais leur dire qu'ils doivent retourner en arrière et réparer tout ce qu'ils ont violé parce qu'ils ne pouvaient pas savoir mieux.
Voo

5
@Voo: vous n'avez pas besoin de «faire de l'ingénierie inverse des guides de style de codage». Les conventions devraient être apparentes quand on regarde le code existant. Tout ce qui ne saute pas immédiatement dans les yeux est soit rare, soit même pas figé. Au cas où il y aurait des règles vraiment importantes sur quelque chose qui se produirait rarement, il pourrait être intéressant d'en discuter avec les nouveaux développeurs, quand ce sont eux qui doivent écrire ce code. La communication ne peut être surestimée.
Holger

112

Il y a une autre interprétation. Je ne crois pas que ce soit ce que voulait dire Oncle Bob, mais cela vaut la peine d'être examiné.

Ne capturez pas les normes de codage dans un document. Capturez-le en code, en ayant un processus automatisé qui vérifie que les normes sont respectées .

Ne vous fiez pas aux gens qui référencent un document, mais en même temps, ne comptez pas sur ceux qui interprètent le code existant et identifient ce qui est conventionnel et ce qui est une coïncidence.

Incorporez quelque chose comme Checkstyle dans votre build de commit. Cela peut appliquer les règles de base telles que les normes de formatage et de nommage, et au lieu de déployer des efforts considérables en matière de style, tout cela peut être transféré à un processus stupide, dont au moins la garantie d'être minutieuse.

Si cela compte, définissez strictement ce que vous voulez et échouez si cela ne va pas.


6
En fait, je soupçonne que quelque chose comme cela faisait au moins partie du raisonnement de la suggestion de l'oncle Bob. L'automatisation des normes de codage va de pair avec les tests automatisés en tant que moyen utile d'améliorer la qualité, et je suis sûr que Bob le sait ...
Jules

10
Il est peut-être intéressant de mentionner la règle n ° 6: After the first few iterations, get the team together to decide.avec la règle n ° 3, il semble qu’il ne préconise aucune norme de codage, mais lorsque vous examinez toutes les règles ensemble, et surtout la règle n ° 6, il semble qu’il dis vraiment: forcez d'abord une norme de codage. Laissez-la se développer de manière organique, et après un moment, asseyez-vous avec votre équipe pour préciser les détails. " Ce qui est très différent de "Ne formalisez pas votre norme de codage" (ce qui semble être l’essence de nombreuses réponses).
Shaz

Si vous lisez les articles, vous constaterez que ce n'est certainement pas ce qu'il a voulu dire, par exemple, celui-ci seul devrait vous dire quelque chose: 2. Laissez-les être spécifiques à une équipe plutôt qu'à une société.
Bill K

Notez que je réponds à la question "Pourquoi ne devrais-je pas écrire une norme de codage" - pas "Qu'est-ce que voulait dire Oncle Bob"? Cela peut aller à l’encontre du titre de la question, mais pas de son esprit.
Tom Johnson

Notez qu'un système de format de codage automatisé qui ne fournit pas de clause d'échappement (où je peux l'éteindre pour une section de code) deviendra presque certainement un malware à un moment donné.
Yakk

66

Les gens négligent le véritable objectif d'un document de normes de codage, à savoir le règlement des différends .

La plupart des décisions de la norme de codage n'auront qu'un effet très mineur sur la lisibilité et la productivité. Surtout si vous adoptez le style «normal» pour le langage et que les concepteurs de langage commencent à se rendre compte que cela devrait faire partie de la spécification (par exemple, Go).

Parce qu'ils sont si triviaux, les arguments peuvent être très difficiles à comprendre et à courir sans fin, ce qui nuit considérablement à la productivité et à la cohésion de l'équipe. Ou encore, obscurcissez votre historique des changements avec un reformatage sans fin entre les styles préférés de deux personnes ou plus.

Avoir une norme écrite met fin à la discussion. Les gestionnaires peuvent le pointer et dévier l’insatisfaction vers le document. Vous pouvez discuter avec un bout de papier, mais il ne vous écoutera pas.

(Voir aussi La tyrannie de l'absence de structure )


19
Ceci est extrêmement important pour les équipes traitant du code hérité. Particulièrement lorsque l'on passe d'un code à un autre (ou ne suit aucun standard) à un autre. Sans guide à utiliser, il est impossible de déterminer le style de code à suivre lorsque plusieurs styles sont déjà présents dans la base de code. Je pense que le conseil de ne pas écrire de normes est destiné à de très petites équipes travaillant sur des projets "greenfield" sans rotation du risque - un cas très rare, selon mon expérience.
thomij

4
Il est beaucoup plus important d'accepter une norme que son contenu réel. Vous pouvez vous habituer à n’importe quel style si vous le travaillez assez longtemps.
Mark Ransom

3
Se disputer pour des banalités est un signe d’incompétence, à mon humble avis. Le règlement du différend concret ne résoudra pas le problème sous-jacent.
Jørgen Fogh

1
Oui, la résolution des litiges et le maintien de l'historique des modifications non polluées sont énormes, en particulier lorsque vous avez un mélange de développeurs OCD et non-OCD dans votre équipe. Cependant, j’ai trouvé que les normes écrites étaient bien moins efficaces que les outils automatisés tels que StyleCop, qui établissent la loi sans la rendre personnelle ni faire perdre du temps aux gestionnaires.
Eric Hirst

12
"Discuter de trivialités est un signe d'incompétence" - J'aimerais que ce soit le cas en ingénierie logicielle ... Je crains que certains développeurs très, très compétents (du moins techniquement) soient exactement ceux qui aiment le plus à discuter de trivialités. Enfer, c'est leur sport national. "Infini sont les arguments des mages" -Ursula Le Guin
Spike0xff

21

Parce que les commentaires sont des mensonges .

La norme de codage est un très bon commentaire sur ce que le code devrait être. Le code lui-même est la source ultime de vérité. La vérité, dans ce cas, n’est pas un comportement de code, mais le style dans lequel elle est exprimée. Si vos normes ne sont pas déjà reflétées dans votre code, vous avez beaucoup de travail à faire.

Oncle Bob considère un commentaire comme un échec personnel du programmeur, car cela prouve qu'il n'a pas réussi à exprimer l'objectif du fragment de code avec le langage de programmation lui-même. De même, un document de normes est un échec pour exprimer un style cohérent dans la base de code.

Les nouveaux programmeurs devraient passer du temps à consulter le code et non pas à lire un document de normes comportant plusieurs chapitres (j'ai dû le faire, soupir).

Un document de normes n’est pas une si mauvaise idée, mais j’ai travaillé dans des ateliers de programmation où le maintien des documents de normes était un travail à plein temps. S'il vous plaît, si vous devez conserver un document de normes, conservez-le sur une page. Mais si vous avez déjà du code, personne ne devrait-il être capable de rassembler le même document en moins d'une journée?

Avoir des normes de code est important. Avoir un document qui dicte ce qu’ils sont ne l’est pas.


22
J'ai expérimenté la base de code vieille de plusieurs décennies avec la politique "sans commentaires"; Bien que cela encourage les noms de méthode descriptive très longs, il est absolument terrible de saisir l'intention, les raisons de ne pas faire les choses, et nous nous en tirons seulement avec l'un des auteurs originaux encore avec nous.
pjc50

7
+1 "Avoir des normes de code est important. Avoir un document qui dicte ce qu’elles sont ne l’est pas." Bien et succinctement mis.
David

4
@ pjc50 Je n'ai jamais entendu Oncle Bob encourager une politique de non-commentaire. Il n'enseigne pas qu'il ne faut jamais commenter. Il enseigne que vous devriez vous sentir mal quand vous vous rendez compte que vous devez le faire pour être compris. Uncommented unreadable <commented unceadable <code lisible qui n'a pas besoin de commentaires. Notez que les commentaires que vous mentionnez sont ceux qui sont complètement découplés à COMMENT le code fonctionne. Les documents de normes peuvent se transformer en une liste de contrôle de la mort cérébrale qui est cochée lors d'une révision du code. L'important n'est pas d'avoir toutes les tiques. C'est que les gens autour de la table comprennent votre code.
candied_orange

3
"Les nouveaux programmeurs devraient passer du temps à examiner le code et non pas à lire un document de normes comportant plusieurs chapitres". Aucune idée des guides de codage que vous suivez, mais le guide de style C ++ de Google peut facilement être lu en moins d'une heure et est beaucoup plus facile à comprendre que de devoir inverser le style préféré en fonction du code existant (ce qui me paraît horrible). La même chose est vraie pour tous les autres guides de style que j'ai jamais lus.
Voo

5
@CandiedOrange: Souvent, les commentaires les plus utiles sont ceux qui décrivent la raison pour laquelle certaines choses n'ont pas été faites [car en l'absence de tels commentaires, les futurs programmeurs risquent de perdre du temps à essayer de mettre en œuvre et de retirer ultérieurement des "améliorations" apparemment évidentes qui tournent être impraticable]. À moins de devenir vraiment fou avec des noms de variables, il est impossible que même le code le plus brillamment lisible puisse capturer ces informations.
Supercat

16

Pourquoi oncle Bob suggère-t-il que les normes de codage ne soient pas écrites si vous pouvez les éviter?

Si vous demandez des raisons derrière son opinion, vous n'aurez peut-être une réponse que s'il publiera une réponse ici ( notre opinion est tout simplement sans importance), cependant ...

Pourquoi ne devrais-je pas écrire une norme de codage?

Si vous lui demandez s'il a raison, laissez-moi être le seul impopulaire (jusqu'à présent) à dire que vous n'avez aucune raison de l'éviter.

ECRIVEZ-LE . Cependant, je vais essayer d'expliquer mes raisons ...

Dans un commentaire, David a suggéré que l'objectif principal de la réponse de Stephen n'était pas de savoir pourquoi vous ne devriez pas écrire de documents, mais sous quelle forme. Si les directives sont formalisées dans des outils (pas simplement une révision manuelle du code), je peux accepter (lorsque la loi n'exige rien d'autre). Veuillez noter que, malheureusement, les outils ne peuvent pas tout vérifier (la théorie du calcul n’est pas notre ami) souvent parce qu’ils sont limités à une unité de traduction ou à un package spécifique , ou quelle que soit votre langue préférée, appelez une limite .

Cependant, le libellé de mon oncle Bob ne me laisse pas penser qu'il en parle.

Puis-je être en désaccord avec un tel expert chevronné? Je le fais, pour presque chaque point dans le post cité (voir aussi la deuxième partie de cette réponse pour plus de détails). Essayons de comprendre pourquoi ( en supposant que vous savez déjà que les lignes directrices de codage ne sont pas seulement mineures de mise en forme des questions ).

  • Dans certaines circonstances, des normes de codage écrites sont requises par la loi.
  • Je lis la documentation et je suis sûr que je ne suis pas seul. Les membres de l'équipe peuvent changer avec le temps, les connaissances ne peuvent pas être dans une base de code vieille de 5 à 10 ans ni dans l'esprit des membres de l'équipe. Les organisations devraient licencier les personnes qui ne suivent pas les directives internes.
  • Les normes de codage, une fois qu'elles ont été approuvées , ne changeront pas souvent et si vous voulez en savoir plus à ce sujet. Si les normes ont changé, votre documentation (en code) est obsolète car tout votre code ne suit pas la nouvelle norme. Le reformatage / refactoring peut être lent, mais vous devez toujours suivre des directives écrites faisant autorité .
  • Il est préférable de lire un document de 5 pages plutôt que d'inspecter une LOC de 10 / 20K pour extrapoler une règle (que vous comprenez peut-être mal, BTW), cela ne fait aucun doute.
  • Il est ironique de constater que quelqu'un qui a écrit de nombreux livres sur les principes de conception et le style de codage suggère de ne pas écrire vos propres directives. Ne faites-vous pas mieux s'il nous envoyait des exemples de code? Non, car les directives écrites vous indiquent non seulement quoi faire, mais aussi deux autres choses qui manquent dans le code: ce qu'il ne faut pas faire et les raisons de le faire ou non.

"La programmation libre et auto-organisée" est bonne pour un ninja de 16 ans, mais les organisations ont d'autres exigences :

  • La qualité du code doit être garantie (et définie) au niveau de l'entreprise - ce n'est pas une tâche à décider par une seule équipe. Ils n’ont peut-être même pas les compétences nécessaires pour décider de ce qui est préférable (combien de développeurs, par exemple, ont-ils tous les compétences requises pour examiner MISRA ou même simplement comprendre chaque règle?)
  • Les membres peuvent être déplacés dans différentes équipes: si tout le monde respecte les mêmes normes de codage, l'intégration est lisse et moins sujette aux erreurs.
  • Si une équipe s'organise elle-même, les normes évolueront avec le temps lorsque ses membres changeront. Vous disposerez alors d'une base de code énorme qui ne respecte pas les normes actuellement acceptées .

Si vous pensez aux personnes avant le processus, je ne peux que suggérer une lecture à propos de TPS: les êtres humains sont un élément central de Lean, mais les procédures sont hautement formalisées.

Bien sûr, une petite organisation avec une seule équipe peut laisser l’équipe décider des normes à adopter, mais cela doit être écrit par la suite. Ici sur Programmers.SE, vous pouvez lire les articles d’Eric Lippert: Je suppose que nous sommes tous d’accord sur le fait qu’il est un développeur expérimenté. Lorsqu'il travaillait pour Microsoft, il devait respecter leurs consignes écrites (même si certaines règles pouvaient être erronées , non applicables ou inutiles. à lui.) Et Jon Skeet? Les directives de Google sont assez strictes (et beaucoup de personnes ne sont pas d'accord avec celles-ci), mais il doit s'y conformer. Est-ce irrespectueux pour eux? Non, ils ont probablement travaillé pour définir et améliorer de telles directives, une entreprise n’est pas composée d’un membre (ou d’une équipe) et chaque équipe n’est pas une île .

Exemples

  • Vous avez décidé de ne pas utiliser plusieurs classes d'héritage et imbriquées en C ++, car les membres de votre équipe ne le comprennent pas bien . Par la suite, toute personne souhaitant utiliser plusieurs héritages doit parcourir l'intégralité du LOC 1M pour voir s'il a déjà été utilisé. C'est mauvais parce que si les décisions de conception ne sont pas documentées, vous devez étudier toute la base de code pour les comprendre. Et même dans ce cas, si cela n’a pas été utilisé, c’est parce que cela va à l’encontre de la norme de codage, ou est-ce autorisé, mais il n’y avait tout simplement pas de situations antérieures où l’héritage multiple convenait bien?
  • En C #, vous aviez des méthodes surchargées pour fournir des paramètres par défaut car votre base de code a démarré lorsque des paramètres facultatifs n'étaient pas disponibles en C #. Ensuite, vous avez changé et vous avez commencé à les utiliser (refactoriser l'ancien code pour les utiliser chaque fois que vous deviez modifier de telles fonctions). Même plus tard, vous avez décidé que les paramètres facultatifs sont mauvais et vous commencez à éviter de les utiliser. Quelle est la règle que votre code vous dit? C'est mauvais parce que la norme évolue mais que codebase est plus lent à évoluer et si c'est votre documentation, vous avez des problèmes.
  • Jon est passé de l'équipe A à l'équipe B. Jon doit apprendre un nouveau standard. tout en apprenant, il introduira probablement des bogues plus subtils (ou, si vous êtes chanceux, prenez tout votre temps pour comprendre le code existant et prolonger sa révision).
  • L'équipe A se déplace vers une base de code précédemment détenue par l'équipe B. Elle a des normes de codage complètement différentes. Récrire? Adapter? Mélanger? Tous sont également mauvais.

Oncle Bob

Laissez-les évoluer au cours des premières itérations.

Il est vrai que tant que vous n’avez pas de norme et que votre organisation vous a confié la tâche de la construire .

Laissez-les être spécifiques à l’équipe plutôt qu’à la société.

Non, pour toutes les raisons expliquées ci-dessus. Même si vous pensez formaliser uniquement le formatage du code (la chose la moins utile que vous souhaitiez formaliser), j'ai encore en mémoire des guerres sans fin (et inutiles) sur le formatage. Je ne veux pas les vivre encore et encore, réglez-le une fois pour toutes.

Ne les écrivez pas si vous pouvez l'éviter. Laissez plutôt le code être la manière dont les normes sont capturées.

Non, pour toutes les raisons expliquées ci-dessus (bien sûr, à moins de refactoriser tout votre code en une fois lorsque les directives changent). Voulez-vous laisser votre code tel quel? Comment inspectez-vous codebase pour comprendre les directives actuelles ? Recherche par âge de fichier et adaptation de votre style de codage à l’âge du fichier source?

Ne légiférez pas un bon design. (par exemple, ne dites pas aux gens de ne pas utiliser de goto)

Certes, les directives doivent être courtes ou personne ne les lira. Ne répétez pas l'évident.

Assurez-vous que tout le monde sait que la norme concerne la communication et rien d'autre.

Non seulement, un bon niveau concerne la qualité, à moins que vous ne souhaitiez définir un standard uniquement sur des détails mineurs .

Après les premières itérations, demandez à l’équipe de décider.

Voir le premier point et ne pas oublier qu’une norme de codage est généralement un processus qui a pris plusieurs années à être développé et affiné: peu d’itérations, peut-être avec des développeurs débutants? Vraiment? Voulez-vous vous fier à la mémoire d'un membre senior (le cas échéant)?

Trois notes:

  • À mon avis, les inconvénients sont plus graves avec certains langages que d’autres, par exemple en C ++, une norme au niveau de l’entreprise est encore plus nécessaire qu’en Java.
  • Ce raisonnement peut ne pas s'appliquer entièrement (et les raisons données par Oncle Bob peuvent être moins extrêmes ) si vous travaillez dans une très petite entreprise où vous n'avez qu'une seule petite équipe.
  • Vous êtes embauché (en équipe) et vous travaillerez seul avec un nouveau projet, vous l'oublierez et vous passerez à autre chose. Dans ce cas, vous ne vous en souciez peut-être pas (mais votre employeur devrait ...)

5
J'ai voté contre cela parce que je pense que la réponse est hors sujet à la question, c'est pourquoi vous (et plus particulièrement Oncle Bob) n'écririez pas une norme de codage , pas pourquoi vous devriez le faire. Je pense que tout le monde comprend les avantages d'avoir une norme écrite, mais les inconvénients sont plus difficiles à déterminer. Lorsqu'un haut responsable de l'industrie prend position contre la pratique habituelle du secteur, il est certainement utile de se demander pourquoi.
Jules

5
@gnat merci, je n'ai pas besoin de upvotes pour les articles hors sujet, n'est-ce pas "Pourquoi M. X a-t-il Y?" hors sujet dans ce cas? Nous ne connaissons pas ses raisons et il ne les a pas expliquées, la question ne devrait-elle pas être fermée comme hors sujet alors? Comment répondriez- vous à cette question? Inventer des raisons aléatoires ou dire que la prémisse est fausse?
Adriano Repetti

1
@AdrianoRepetti - Oncle Bob a beaucoup expliqué au fil des ans. Il est donc raisonnable de penser que quelqu'un peut avoir une idée de sa façon de penser, mais vous avez raison si son interprétation directe est requise.
JeffO

3
@ jeff oui, si la question porte sur "pourquoi il le pense", alors la réponse n’est qu’une hypothèse. Si la question est "est-ce juste?" alors ma réponse personnelle est d *** absolument non.
Adriano Repetti

1
"Quand il travaillait pour Microsoft, il devait se conformer à leurs directives écrites" - vous pariez que je l'ai fait. Et bien sûr, nous avons utilisé FXCop et StyleCop pour empêcher l'enregistrement de mauvais motifs.
Eric Lippert

12
  1. Pour être utile, une norme de codage ne doit pas traiter de questions de fond; seulement des questions de style. Il ne devrait spécifier que les éléments arbitraires et ambigus. p.ex. placement d'accolade, profondeur d'indentation, espaces par rapport aux tabulations, conventions de dénomination, etc.
  2. Les questions de style sont locales et non mondiales. Chaque équipe doit adopter son propre style, adapté à sa tâche et à sa personnalité. Cela maintient les normes simples et légères. Les normes d'entreprise sont surchargées de considérations, de configurations et d'exceptions possibles.
  3. Au sein d'une équipe, la seule raison d'écrire un document de style de codage distinct est si le code produit par l'équipe ne respecte pas la norme. Dans ce cas, vous n'avez pas de standard. Pour être efficace, la norme devrait être exprimée par le code lui-même. Et si tel est le cas, il n'est pas nécessaire de disposer d'un document séparé.
  4. Dans les systèmes existants, les équipes et les styles changent avec le temps. Il n'y a rien de mal à ça. Ancien code aura un style plus ancien. Le code le plus récent aura un style plus récent. L'équipe doit être consciente des styles et de leur âge. Chaque fois que le nouveau code est écrit, il doit être dans le nouveau style, quel que soit son emplacement dans le code.

J'ai peu de perplexités: 1) pour être utile, une norme de codage ne devrait pas parler uniquement de formatage (question de guerres saintes mais facile à comprendre du code de lecture), mais de constructions à éviter, de modèles de codage (pour éviter les erreurs courantes, difficile à comprendre le langage) fonctionnalités) et les problèmes de sécurité. Ce sont des directives de codage (plus utiles que les problèmes de formatage). 2) Étant donné le postulat du point 1, il n’est pas question de personnalité (mais de tâches ), vous pouvez avoir une norme d’entreprise légère, c’est à vous de le faire.
Adriano Repetti

3) Le code peut vous dire quoi faire, mais il ne peut pas transmettre ce que vous ne devriez pas faire (à moins que vous souhaitiez étudier une base de code complète et même dans ce cas ... vous n'avez pas eu à utiliser X construct ou c'est un non-non?) Une autre chose importante est le raisonnement: pourquoi pas? et pourquoi oui? Les choses peuvent changer avec le temps, mais comment savoir si les locaux initiaux sont toujours valables? 4) et quand vous êtes un nouveau membre de l'équipe et que vous écrivez un nouveau code ... étudiez-vous la base de code avec le même âge pour conserver ce style de code? Le lendemain, vous passez à un autre composant plus récent et étudiez à nouveau le code de base (filtrage par date de création?)
Adriano Repetti,

BTW si, au contraire, vous suggérez de ne pas alors écrire que le code des styles de formatage , je peux d' accord (bien, pas vraiment , mais avec pas de bonnes raisons en plus des souvenirs de discussions interminables et inutiles qui surgiront inévitablement chaque fois - et qui une entreprise directive éviter une fois pour toutes) mais vous devez le préciser ou les gens interpréteront vos mots trop littéralement (voir la plupart des réponses + commentaires ici). En outre, cette remarque sur "goto" est un peu trompeuse en ce sens (IMO)
Adriano Repetti

4

Pourquoi ne devrais-je pas écrire une norme de codage?

Il y a plusieurs raisons à cela. Voici quelques considérations:

  1. Combien de temps les gens passent-ils "à apprendre" les normes de code pour ne pas perdre beaucoup de temps dans l'ensemble de l'équipe pour réviser, discuter, documenter, réviser, etc., les normes de code. C'est comme si vous discutiez constamment de votre "Manuel de l'employé" - à quelle fréquence cela le fait-il à l'ordre du jour d'une réunion d'équipe?

  2. Lorsqu'un projet est financé / mis de côté / etc. alors les quelques personnes qui restent ne peuvent généralement pas continuer à respecter (ou peut-être même pas lu) les normes. La prochaine chose que vous savez, tous ces efforts pour "garder le code propre" a été assez gaspillée de toute façon.

  3. Si le projet est bloqué ou si un nouveau chef de file est introduit, il est fort probable que cette personne ignore totalement les règles précédentes et souhaite procéder de manière différente. Encore une fois, qu’a-t-on gagné en codifiant des normes?

Vous devriez être sûr de lire # 6:

Après les premières itérations, demandez à l’équipe de décider.

En d'autres termes, lorsqu'il est temps de démarrer un projet, suivez le flux pendant un moment. Ensuite, discutez des règles générales des normes de codage utilisées par l’équipe actuelle et respectez-les. De cette façon, vous optimisez les efforts nécessaires pour améliorer le produit tout en minimisant les efforts nécessaires pour écrire, réviser et documenter le "sucre syntaxique" utilisé pour obtenir du code exécutable.

Très peu d’équipes tirent d’énormes avantages des normes de codage. Habituellement, la "lisibilité" est beaucoup trop vague - et la plupart des développeurs ne bénéficient pas de règles exactes en matière d'espacement, de nouvelles lignes, etc., mais vous pouvez éviter de gêner constamment les développeurs en ayant au moins quelques règles.


4

Une autre réponse qui, à mon avis, n’a pas été suffisamment clairement énoncée, est que cela signifie également que les gens ne respectent pas les règles à l’aveugle. Cela signifie que les utilisateurs doivent trouver des justifications concrètes pour leurs décisions de conception et leurs conventions de codage, plutôt que de simplement compter sur le fait que cela a été écrit pour le justifier.


4

Tout d’abord, pour autant que je sache, oncle Bob est une personne de Java, c’est très important pour comprendre ce qu’il dit.

Lorsque vous travaillez dans une équipe Java ou C #, si le code actuel a été écrit par des développeurs expérimentés, il est facile pour moi de choisir le style de code et de le suivre. Si je ne le souhaite pas, je ne suis peut-être pas la bonne personne pour le poste. S'il n'y a pas de révision de code ni de programmation par paire pour me récupérer quand je ne respecte pas le style, la société a problème plus important que la façon dont je nomme les champs membres!

Java et C #, ainsi que la plupart des langages modernes, ont été définis de sorte qu’il existe peu de pièges "simples" dans lesquels un programmeur puisse tomber.

Cependant, lorsque j'ai commencé à programmer, j'utilisais le C (et plus tard le C ++). En C, vous pouvez écrire du code comme

if (a = 3);
{
   /* spend a long time debugging this */
}

Le compilateur ne générera pas d'erreur, ce qui est difficile à repérer lors de la lecture de beaucoup de code. Cependant, si vous écrivez:

if (3 = a)
{
   /* looks odd, but makes sense */
}

Le compilateur donne une erreur et il est facile de changer le code en 3 == a. De même, si la norme de codage ne permet pas =d’être utilisée dans une ifcondition ou une " ifinstruction vide ", un vérificateur de code peut être utilisé dans le cadre du système de construction pour suivre cette erreur.

Mon point de vue sur les normes de codage a beaucoup changé lorsque je me suis éloigné du C / C ++: j’aimais les normes de codage qui étaient appliquées de manière stricte et qui comportaient de nombreuses pages. Je pense maintenant qu'il suffit de répertorier les outils utilisés et d'obtenir un accord informel entre les membres de l'équipe d'origine sur quelques conventions de dénomination. Nous ne vivons plus dans un monde d'équipes de plus de 30 développeurs écrivant des applications en C / C ++ ...

Il y a une raison pour laquelle je n'ai jamais aimé JScript et je pense que TypeScript est la meilleure chose à faire pour le développement Web depuis des années. Je m'attends à ce que les développeurs d'interface Web aient toujours besoin de normes de codage en raison des défauts de conception de HTML / CSS / JScript, etc.


4
"Le compilateur ne provoquera pas d'erreur", la plupart des compilateurs C et C ++ modernes prennent en charge le signalement de ce comportement avec des avertissements ou, le cas échéant, des erreurs complètes. gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
JAB

2
"D'abord, pour autant que je sache qu'Oncle Bob est une personne de Java, c'est très important pour comprendre ce qu'il dit", ce n'est pas vrai, Oncle Bob a écrit de fantastiques articles sur C ++ et il a certainement travaillé plusieurs années avec C aussi.
Alessandro Teruzzi

@JAB, Heureusement, le C / C ++ a cessé d'être utilisé pour de nouvelles "applications métier" il y a longtemps (par exemple, avant les compilateurs C / C ++ par modem) et n'est plus utilisé que par des experts en C / C ++, plutôt que par des experts en interface utilisateur. (MFC) par exemple.
Ian

1
@AlessandroTeruzzi Un test unitaire vous dira qu'une méthode échoue. La raison pour laquelle cela échoue est une autre affaire - même si vous aviez des tests unitaires pour une méthode avec ce genre de code, vous auriez beaucoup de difficulté à essayer de savoir ce qui ne va pas. C ++ est l’un des langages les plus pénalisants à déboguer.
T. Sar

2
Je pense qu'il y a un malentendu ici, vous ne pouvez pas prendre une seule phrase de OncleBob et l'analyser de manière isolée. Si vous avez le logiciel SOLID avec de petites classes, une méthode courte et une couverture de test unitaire à l'épreuve des balles, la norme de codage est redondante. Si vous avez un code faible, une interface énorme, des fonctions étendues et une couverture faible, la norme de codage peut vous apporter certains avantages. Cependant, UncleBob ne suggère pas de ne pas en avoir un, mais de le diffuser verbalement avec la collaboration et le refactoring (supprimer le code faible de la base source). Faites de votre code la norme de programmation vivante.
Alessandro Teruzzi

3

Avoir la source comme norme de codage auto-documentée implique deux choses.

  1. Les personnes doivent consulter la base de code et la réviser afin de devenir des contributeurs compétents. C'est incroyablement important. Lire les directives de codage est une perte de temps par rapport à plonger dans la base de code.
  2. Il concède que les différences mineures sont sans importance. Il est important de s’entendre sur les principes de base et de les comprendre. Le maintien d'un style cohérent n'est pas poursuivi comme l'art pour l'art. Il ne permet pas aux nitpickers non créatifs d'ennuyer et de distraire les autres. Il s'agit de faciliter la communication par le code en équipe.

2

Un document de normes de code fréquemment mis à jour et bien écrit peut être très utile, mais ce n'est généralement pas le cas. Le document de normalisation ne reflète pas les normes de codage réellement utilisées par la société, car il est très difficile de créer un bon document de normalisation et encore plus difficile de le tenir à jour.

Au lieu d'avoir un document de normes de codage médiocre et trompeur, il est préférable de n'en avoir aucun et de laisser le code lui-même représenter ces normes. Quoi qu’il en soit, le plus important est d’appliquer les normes du code, ce qui nécessite bien plus qu’un simple document. La motivation, les processus, les formations, les outils, etc. sont beaucoup plus importants.


2

Une chose très importante qui n’a pas été suffisamment clairement définie est que les normes de codage sont comme la langue: elles évoluent. Une norme de codage écrite est un obstacle, sinon, elle est continuellement obsolète et inutile.

Ne pas avoir une norme de codage clouée n'est pas si mal. Si vous effectuez des examens par les pairs lors de l'enregistrement, chaque fois que quelque chose non conforme à la norme de codage entre dans le référentiel, cela signifie que 2 personnes y ont réfléchi * et ont décidé que l'avantage de cette variation l'emportait sur l'incohérence avec le reste du code.

Le fait de ne pas avoir de norme écrite supprime également les formalités administratives qui empêcheraient une équipe d’une entreprise d’essayer une nouvelle version de la norme de codage pour un nouveau projet, soit parce qu’elles veulent essayer quelque chose, soit peut-être parce qu’une norme différente a des applications pratiques. sur certains des outils automatisés qu’ils utilisent.

Ecrire une norme a tendance à supprimer plus de flexibilité que prévu à l'origine, tout en prenant un temps considérable qui pourrait être consacré à d'autres tâches. Je ne dis pas que vous ne devriez jamais écrire de normes de codage, les normes écrites ont certainement leurs avantages, en particulier si des équipes travaillant dans des endroits différents travaillent sur la même base de code.

Fortement lié: évolution des normes de codage, comment les gérez-vous?


* Si les gens ne réfléchissent pas pendant que leurs pairs examinent le code à l'enregistrement, vos problèmes vont bien au-delà des normes de codage.


1

Les changer devient un obstacle majeur, et les gens adhéreront en toute sécurité à la lettre de la loi plutôt que d’engager leurs cerveaux et de faire ce qui est bien.

Il viendra un jour où une partie de la norme sera inutile et aggravera le code. Certaines personnes adhéreront à la norme, car elle est écrite et sécurisée, et parce que les règles doivent être respectées. Les personnes qui veulent écrire du bon code plutôt que du code conforme à la norme seront frustrées et en colère. Il y aura des arguments et des désaccords, alors que si la norme n'était pas écrite, il y aurait une exploration et une discussion.


0

Je pense que de nombreux articles ici confondent norme de codage avec guide de style .

S'assurer que les modules développés par différentes équipes ont les mêmes options de compilateur et qu'ABI est différent du nombre d'espaces mis en retrait.

Des éléments comme la bonne manière de structurer les fichiers #include et de ne pas polluer l'espace de noms global dans un fichier d'en-tête doivent être documentés afin qu'ils puissent être utilisés comme liste de contrôle lors du codage initial et de la révision du code.

En particulier, "n'utilisez pas XXX, car cela entraîne des problèmes de compatibilité avec YYY", ne serait pas ce que vous verriez par exemple si vous suivez un autre code, car il n'est pas là. Alors, que le code soit la manière dont les normes sont capturées peut ne pas être clair ou totalement absent pour certains types de normes, et donc cela ne peut pas être un plan universel.

Quelque chose de grave, qui est omniprésent et important, comme ne pas utiliser d'exceptions ou ne pas utiliser newdans certains systèmes intégrés, ne peut pas être simplement considéré comme un savoir culturel commun, car cette "information est culturelle (seulement)" est en contradiction avec les principes fondamentaux des normes de fabrication telles que développeur de ces systèmes embarqués utilise (par exemple pour les applications automobiles). Ces choses importantes doivent être documentées, validées et classées de manière formelle.

Mais cela s’applique au codage , pas au style .

Les inventeurs de C et C ++ montrent, par exemple, l’utilisation de noms en minuscules et non de CaMelCaSe. Alors pourquoi tant de développeurs ne suivent-ils pas l'exemple implicite de la source? Le style de la bibliothèque standard et du matériel didactique canonique ne devrait-il pas être le style implicite à suivre?

Pendant ce temps, les gens font suivre l'exemple des en- têtes de la bibliothèque standard pour des choses qui ne doivent pas être copiées, comme l'utilisation des __Uglynoms des paramètres macro et le fichier à inclure motif non répétition.

Donc, avoir des choses n'est souvent pas considéré comme un style important, ou inversement, avoir des exemples peut ne pas être clair quant à ce qui ne devrait pas être suivi dans le code de projet. Les deux sont des contre-exemples à la thèse selon laquelle il est préférable de laisser implicitement le "style" (ou les conventions de codage).

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.