Mon équipe doit-elle utiliser une norme de codage commune bien considérée comme base pour la sienne?


9

L'équipe R&D dans laquelle je suis a décidé d'adopter une norme de codage. Nous venons de nous former et avons trop peu de code et de temps de codage commun pour fonder notre document de normes / conventions sur ce qui s'est développé organiquement dans notre équipe et sur de bons exemples de notre propre code, etc.

Maintenant, chacun de nous a une certaine expérience des lieux de travail passés - bien qu'aucun de nous ne soit en train de dire "adoptons ce document complet ici que j'ai trouvé adapté au type de travail que nous faisons ici" (*). De plus, certains d'entre nous (y compris moi-même) n'ont d'expérience que dans des endroits sans norme de codage officielle, ou écrivent dans différentes langues dans un cadre différent (environnement de production à haute pression hebdomadaire par opposition à un travail de développement davantage axé sur la recherche)

Donc, l'une des options auxquelles j'ai pensé consiste à prendre un document relativement bien connu et bien considéré, à couper ce dont nous ne nous soucions pas / à prendre soin, et à apporter des modifications en fonction de nos préférences.

Est-ce une pratique courante? Croyez-vous que c'est une bonne idée? Dans l'affirmative, quelle serait une norme de codage «de base» raisonnable (ne me dites pas laquelle est la meilleure, je ne veux pas déclencher un conflit religieux ici; montrez simplement ce qui serait suffisamment complet ou «neutre» pour s'appuyer sur .)

Remarques:

  • Nous nous attendons à travailler avec C, C ++, OpenCL, CUDA, Python.
  • Nous sommes une équipe de 4 personnes + manager, qui devrait atteindre environ 5-6 en un an environ.
  • Dans notre entreprise, les équipes sont presque entièrement autonomes et n'interagissent généralement pas du tout (même pas en utilisant le code de l'autre - le travail porte sur des projets entièrement différents); donc - pas de considérations à l'échelle de l'entreprise à faire.
  • En ce qui concerne les outils, ce que nous savons pour le moment, c'est que nous allons utiliser Eclipse , donc son formateur de code sera au moins un outil. Ctrl + Shift + F est depuis longtemps mon ami
  • Lorsque j'écris Java, j'ai adopté la pratique d'adhérer le plus strictement possible au Java efficace de Bloch . Maintenant, ce n'est pas tout à fait une norme de codage, mais vous pouvez appeler des briques, du ciment et du mortier pour une norme de codage. Je pensais éventuellement inclure quelque chose comme ça dans le «mix» (sachant que nous ne faisons pas Java).
  • Je veux dire des normes de codage dans le sens large du mot, par exemple l' adoption de suggestions faites dans les réponses à cette question P.SE .
  • J'ai trouvé une grande liste de documents sur les normes de codage C ++ ; peut-être que je devrais exploiter notre base de référence.
  • (*) Ce n'est pas tout à fait vrai, mais je ne veux pas compliquer cette question avec trop de détails.

9
L'utilisation d'une norme de codage créée en externe permet de réduire les guerres sacrées concernant des styles de codage particuliers.
Gort the Robot

4
La ligne directrice que vous utilisez n'a pas vraiment d'importance. Ce qui compte, c'est que vous en utilisiez un et que tout le monde accepte de l'utiliser de la même manière . Cette dernière partie est plus facile à faire si vous en choisissez une saine d'esprit.
Joachim Sauer

3
Les conventions de dénomination sont surévaluées. Si vous avez un module où les fonctions sont CamelCase et un autre où elles sont snake_case, ce n'est pas grave si vous acceptez au moins de suivre la convention déjà en place pour chaque composant. Donc, si la guerre sainte devient trop chaude, arrêtez-la et laissez-la incohérente.
Jan Hudec

1
J'ai très peu d'expérience Eclipse, mais le standard de code (pas le style) pour Eclipse peut être utile
Dan Pichelman

1
Donc, votre choix est d'utiliser une norme existante ou de dépenser du temps et de l'argent pour en créer une? Je ne vois pas de choix ici. Allez avec l'option gratuite.
Ramhound

Réponses:


9

Autrement dit, vous demandez si vous devez relancer les normes de codage de votre équipe en empruntant les normes externes que vous avez trouvées. Il ne semble pas que quiconque dans l'équipe ait (encore) des opinions très fortes sur ce que devraient être ces normes.

Sans équivoque, la réponse est oui.

Une norme d'origine externe est supérieure à rien. Regardez les réponses dans " https://softwareengineering.stackexchange.com/q/84203/53019 " afin de voir certains des avantages d'avoir une norme. La cohérence et la base de changement sont essentielles de votre point de vue.

Jetez également un coup d'œil à " Gestion des normes de codage au travail (je ne suis pas le patron) ", car il aborde certaines des dynamiques d'équipe que votre équipe doit prendre en compte lors de la sélection de la ou des normes. L'équipe doit posséder sa ou ses normes de codage afin que chacun se conforme volontiers aux restrictions qu'elle impose sur la façon dont chaque personne code.

Vous avez lié cette question, mais il vaut la peine de souligner la réponse la plus importante et de se concentrer sur la compréhension de la raison pour laquelle les exigences sont en place. Si vous utilisez une norme externe, il sera difficile pour votre équipe de comprendre la base de toutes ces exigences. Mais si vous acceptez qu'ils sont là simplement parce que votre équipe avait besoin de quelque chose pour commencer, il est facile de passer à la modification de cette norme externe en quelque chose qui fonctionne mieux pour votre équipe.

Avoir une norme en place vous permet de remplir les règles de formatage que vous utiliserez avec votre IDE (Eclipse dans votre cas). " Avantages et inconvénients du reformatage forcé du code " présente les avantages pour tous les membres de l'équipe d'avoir cette cohérence avec le code sur lequel ils travaillent et vous donne la possibilité de reformater les extraits de code que vous pouvez emprunter à d'autres projets. Un avantage supplémentaire de l'utilisation d'une norme externe est qu'elle peut déjà être pré-remplie dans la partie de formatage de code de votre IDE.

Un membre de l'équipe se plaindra probablement d'une partie particulière de la norme et le blâmera du fait que vous avez utilisé une norme externe comme base. Demandez-leur de lire:
- Je déteste l'une de nos normes de codage et cela me rend fou, comment la traiter?
- Comment surmontez-vous vos propres biais de codage lors de la remise du code hérité?
et ensuite se rendre compte qu'ils se seraient probablement plaints de quelque chose dans la norme, peu importe d'où elle venait. Dans le nombre d'équipes sur lesquelles j'ai travaillé, je n'ai pas encore vu de norme que tout le monde a) a universellement appréciée et b) a accepté avec chaque partie de la norme. Reportez-vous à certains des premiers liens pour voir comment répondre à ces préoccupations.


Addendum, vous avez demandé «lequel» utiliser. Je ne vais spécifiquement pas répondre à cette question, car toute réponse est potentiellement entachée de guerres de flammes alimentées par l'opinion. Cependant, vous pouvez regarder votre IDE (Eclipse) et voir quelles options il fournit comme configuration standard. Je chercherais également un peu et verrais s'il y a des projets qui se connectent à votre IDE et fournissent des options de normes supplémentaires à choisir. À tort ou à raison, ces normes sont déjà remplies pour vous et peuvent économiser à votre équipe une grande partie du travail de configuration pour tout le monde.


6

Je commencerais par python. Python a des directives de codage que presque tous les programmeurs Python suivent. Ils font partie de la documentation officielle appelée PEP8 .

C / C ++ est un énorme gâchis pour des raisons historiques, mais comme python ne l'est pas, je vous recommande également de suivre la convention de dénomination python en C / C ++ pour des raisons de cohérence.

Maintenant, pour C ++, il est en fait plus important de se mettre d'accord sur des idiomes communs et de s'assurer que tout le monde comprend un style C ++ moderne raisonnable que toutes les guerres sur les conventions de dénomination. Vous devriez commencer par les normes de codage C ++ et à partir des ressources en ligne, assurez-vous de lire la FAQ C ++ .


En fait, je pense que nous aurons des conventions de dénomination différentes pour chacun de C, C ++ et Python - au moins, des choses comme la capitalisation, l'utilisation de soulignements, etc. MyTypeNameest sans doute mieux en C ++ que my_type_name_t, et l'inverse vaut pour C. Mais merci pour les references.
einpoklum

Pour C ++, vous pouvez utiliser la norme utilisée par la STL et boost. Tout le monde ne l'aime pas, mais comme vous utiliserez très certainement des conteneurs stl, cela sera cohérent avec cela.
Laurent Bourgault-Roy

@einpoklum: Pour les non-types, toutes les bibliothèques standard C, C ++ et Python utilisent "snake_case"; aucune différence là-bas. La seule différence est de savoir si vous souhaitez utiliser "MixedCase" pour les types ou également "snake_case". Les bibliothèques C et C ++ utilisent "snake_case", mais sinon "MixedCase" est très courant.
Jan Hudec

@einpoklum Utilisez le standard défini par la bibliothèque standard pour C ++.
Miles Rout

3

Vous ne pouvez même pas discuter de ce sujet sans faire la distinction entre une norme de codage et une norme de style de codage .

Une norme de codage est un ensemble de règles définissant les mécanismes de langage que vous êtes autorisé à utiliser, ceux que vous n'êtes pas autorisé à utiliser et comment les utiliser. En d'autres termes, vous définissez un sous-ensemble du langage utilisé, et / ou un sur-ensemble, si la norme de codage adresse certaines extensions non standard.

Une norme de style de codage ne concerne que les problèmes esthétiques: où placer les accolades et les espaces, comment nommer les identificateurs, comment placer les commentaires, etc.

Ces deux choses différentes peuvent se trouver dans le même document. Cependant, les normes de codage les plus sérieuses ne se préoccupent pas du style - celles que je recommande ci-dessous ne le font pas. Très probablement parce que le style de codage est très subjectif et provoque donc beaucoup de friction lorsque les opinions entrent en collision.

Pour C / C ++, les normes de codage ayant la meilleure réputation sont celles de MISRA . Ils sont principalement conçus pour les applications critiques pour la sécurité / la mission, mais comme la clé pour rendre les programmes plus sûrs est de supprimer et d'éviter les bogues, les normes MISRA s'appliquent à toute branche de programmation où les bogues ne sont pas souhaités.

Les normes du CERT sont également assez bien connues et plus orientées vers la programmation de bureau et la sécurité des logiciels (plutôt que la sécurité). CERT a des normes pour C, C ++, Java et Perl, et les normes sont gratuites.

Je commencerais par regarder MISRA et CERT, plutôt qu'une norme de garage aléatoire trouvée sur le Web.


1
Je n'ai jamais entendu parler de MISRA auparavant, et je ne vois pas que ses électeurs sont des acteurs trop importants. Pouvez-vous expliquer leur réputation? En ce qui concerne les documents CERT, pouvez-vous préciser s'il s'agit de normes spécifiques aux programmes sécurisés ou de normes plus générales?
einpoklum

@einpoklum Pour commencer, MISRA-C est utilisé par à peu près tous les constructeurs automobiles du monde. Il devient une norme "de facto" pour la programmation C dans l'ensemble de l'industrie des systèmes embarqués, où il est le plus connu. Pourtant, rien dans le document MISRA ne l'empêche d'être utilisé dans n'importe quelle forme de programme C. MISRA et CERT sont tous deux assez généraux, ils visent en fin de compte à réduire le nombre de bogues, de mauvaises pratiques et de vulnérabilités dans un programme. Ces normes encouragent également l'analyse de code statique.

1

L'utilisation d'une norme existante comme base pour la vôtre présente plusieurs avantages. Votre code sera probablement plus similaire au code externe, ce qui facilitera la lecture / l'intégration du code. De plus, si vous choisissez un bon standard, il aura été examiné par des experts qui ont eu de bonnes raisons de décider de leurs règles particulières. Tant que personne dans votre équipe n'est particulièrement lié à une norme, il n'y a aucune raison de ne pas utiliser une norme existante comme base pour la vôtre.

Si vous n'êtes pas sûr des normes de codage à utiliser, il existe des premiers choix idéaux évidents. Dans aucun ordre particulier:
1. Quelle que soit la norme déjà prise en charge par votre IDE. Ceci est probablement configurable.
2. Quel que soit le standard utilisé / recommandé par l'auteur de votre compilateur.
3. Quel que soit le standard utilisé / recommandé par l'auteur de votre framework principal (s'il en existe un).
4. Quelle que soit la norme utilisée / recommandée par les auteurs / concepteurs de votre langage de programmation.
5. Quelle que soit la norme utilisée / recommandée par une très grande entreprise.

Je recommande à quelqu'un ayant une expertise technique de lire la norme que vous utilisez comme base pour votre propre norme. Une bonne norme aura souvent une justification pour chaque règle, ce qui vous aidera à modifier la norme pour mieux l'adapter à vos besoins.


0

Une norme facilite généralement la communication et la maintenance. À mon avis, il devrait faire l'objet de quelques concessions mutuelles, en particulier dans les petites équipes, et devrait évoluer. Les appeler directives peut aider :-)

Jetez un œil aux directives de Google pour trouver l'inspiration.


5
Il est très subjectif de choisir les directives de codage pour C / C ++. Et s'il y en a un que je ne choisirais pas , c'est celui de Google. Ils interdisent beaucoup de choses généralement considérées comme un bon style C ++ moderne par d'autres, comme boost.
Jan Hudec

1
Comment votre réponse répond-elle aux préoccupations du PO concernant l'utilisation d'une norme externe? Suggérer un changement de nom pour les normes de codage n'aide pas les problèmes de base qu'ils devront résoudre.

1
@JanHudec Je suis d'accord. Il interdit notamment l'utilisation d'exceptions.
BЈовић

-3

NON, cela ne me dérangerait pas - je pense que le seul avantage serait que votre équipe déménage dans un endroit où ces normes ont également été utilisées, ce qui n'est pas ce que vous voulez faire :)

Les normes ne sont là que pour encourager une collaboration plus facile, donc si vous savez qu'une macro #define est toujours en majuscule, alors quand vous voyez un identifiant en majuscule dans le code, vous aurez une bonne idée que c'est une macro. De même, d'autres conventions de dénomination ou conventions de style vous rappelleront à quoi vous avez affaire.

Je trouve que les normes comme l'emplacement et le nom du fichier sont plus utiles1 que celles du code (après tout, le code est de toutes formes et tailles, et vous devez toujours le lire) alors que ne pas savoir que le fichier readme.txt se trouve dans / bin / doc / debug / release / documents est une vraie douleur (tout comme un chemin merdique, mais c'est une autre histoire).

Je vous recommanderais de créer vos propres normes au fur et à mesure. De cette façon, vous obtenez non seulement ceux que vous aimez tous, mais vous obtenez ceux qui conviennent parfaitement à vous, à votre équipe et au travail que vous faites. Si vous décidez que vous ne vous souciez pas vraiment de ce à quoi ressemble une boucle while, ou que les déclarations de cas doivent être mises en retrait d'une certaine manière, alors vous êtes bon. Si vous décidez que les opérateurs ++ sont interdits, tant mieux. Tout votre choix.

Vous devriez le rendre facile à trouver et à mettre à jour, un wiki peut-être ou une page Web générée automatiquement à partir d'une description textuelle, mais sinon - allez-y. Les normes ont une attitude mythique de la part de certaines personnes qui sont plus intéressées à suivre fanatiquement la norme qu'à écrire du bon code, ne leur ressemblez pas - créez votre propre norme qui vous aide là où vous en avez besoin.

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.