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 ...)