Et toutes ces règles de codage?


10

J'ai toujours soutenu l'idée d'avoir des règles de codage pour les développeurs dans une entreprise ou un projet spécifique. Surtout si l'entreprise a une taille supérieure à 10. Plus l'entreprise est grande, plus le besoin est grand. Je sais que beaucoup de gens seront en désaccord, mais j'ai vu des projets qui n'en ont pas et le code ressemble à un désastre total.

Le vrai problème qui en découle est de savoir comment rendre ces têtes dures qui n'aiment pas utiliser les crochets dans les instructions if, ou utiliser la même chaîne de connexions partout dans le code, ou autre, pour utiliser les règles de codage sans les opposer l'idée?


3
Si vous utilisez C # comme langage, utilisez alors StyleCop. Si vous utilisez Java ...
Job

@Job - Oui, nous utilisons principalement C #. StyleCop semble intéressant.
TheBoyan

Réponses:


9

Faites-les participer à la résolution d'un problème plutôt qu'à la lutte contre les règles. Personnellement, je préfère l'idée de «guides de style», de «normes de codage» ou quelque chose de similaire, dans l'espoir que cela empêche la réaction «règles = mauvaise» de la secousse du genou.

Mais même si c'est le cas - j'ai tendance à penser que les règles sont en place pour une raison, et la manière d'inciter les personnes à la tête dure à se retourner est de leur faire réaliser qu'en suivant les directives, elles aident à rendre le code plus facile à lire pour tout le monde.

Parfois, la pression des pairs est la meilleure solution pour cela.


En jouant l'avocat du diable ici, il est toujours possible que les règles soient tout à fait erronées (par exemple, quelque chose de mis en place pour un projet passé mais est un fardeau pour les développeurs du projet actuel) - donc avoir un processus de révision / abrogation des règles - même si cela est rarement utilisé - peut également aider à rassurer les gens sur le fait que les règles sont une directive utile plutôt qu'une imposition à la liberté du développeur.
Beekguk

Absolument - et je pense que si vous vous en tenez aux conseils pour vous concentrer sur les raisons pour lesquelles vous avez besoin de la règle, alors si vous comprenez que vous n'avez pas besoin de la règle, vous savez que l'équipe ou la personne est venue d'un état d'esprit ouvert, plutôt que juste être défensif en raison d'un processus de règles inexplicable.
bethlakshmi

6

Dans mon travail, nous utilisons les trois solutions suivantes:

1) Adoptez un vérificateur de style de code tel que l'excellent Checkstyle (pour Java) ou StyleCop (pour C #). Ce sont des outils faciles à configurer qui peuvent automatiquement mettre en évidence les écarts de style / règle de codage. Il donne à chacun une tierce partie neutre pour déterminer ce qui est et n'est pas acceptable.

2) Adoptez un modèle de code de reformatage à sauvegarde automatique (voici un exemple utilisant Eclipse) (et un autre pour Visual Studio) qui formatera automatiquement votre code lors de la sauvegarde. C'est génial pour permettre à quelqu'un de coder comme il le souhaite, mais d'avoir tout le code formaté de la même manière lors de l'enregistrement / de la validation. J'aime vraiment celui-ci et notre code n'a jamais été aussi cohérent.

3) Revues de code. J'espère que vous le faites de toute façon, mais une chose que cela devrait souligner, c'est où les règles / styles de codage enfreignent les conventions.

En plus de ce qui précède, il est important que tout le monde soit sur le même bateau et ait convenu des styles / règles vers lesquels ils travaillent. Faites comprendre que vous n'obtiendrez pas l'accord de tout le monde sur tout, mais demandez à l'équipe de s'engager à respecter ce que l'équipe décide. Assurez-vous de revoir de temps en temps les styles / règles choisis pour tenir compte de l'expérience réelle dans leur utilisation et du roulement d'équipe.


Vous pouvez configurer certains systèmes de contrôle des révisions pour appliquer des éléments comme Checkstyle lors de l'enregistrement. Si vous le faites, commencez par les règles les plus critiques et ajoutez des règles plus pointues plus tard.
BillThor

4

Le vrai problème qui en découle est de savoir comment créer des têtes dures qui n'aiment pas utiliser les crochets dans les instructions if, ou utiliser la même chaîne de connexion partout dans le code, ou autre chose,

Sont-ils "durs" en n'utilisant pas de crochets ou s'agit-il d'une demande "dure"?

Choisissez vos batailles. Je doute que ce soit l'un de ceux qui mérite d'être choisi. Je n'apprécierais pas de travailler n'importe où qui m'attendait n'importe où près de ce niveau de détail sur le "premier code d'enregistrement". Il s'agit d'un indicateur de drapeau rouge indiquant que l'équipe ne comprend pas le refactoring.

OO 101 : "Refactoriser lorsque le produit fait ce qu'il doit faire". Pas avant.


Le fait de ne pas utiliser de crochets n'était qu'un exemple :) bien que j'ai travaillé pour une grande entreprise qui avait un livre de> 200 pages de règles de codage et c'était l'une d'entre elles. Quoi qu'il en soit, je suis sûr que vous conviendrez avec moi que quelqu'un qui utilise délibérément la même chaîne de connexion (un exemple encore) encore et encore dans le code simplement parce qu'il est trop paresseux pour le mettre dans un fichier de configuration et lire à partir de là, a besoin d'attention et il faut savoir comment faire face à ce genre de situations.
TheBoyan

2

Il est assez difficile de s'asseoir sur l'épaule de chaque développeur dans de grandes équipes, en s'assurant qu'ils mettent des accolades là où vous pensez qu'ils devraient aller - faites-moi confiance à ce sujet;).

Si c'est quelque chose que vous sentez vraiment gêner votre développement, alors vous allez avoir besoin d'un "gardien". Ne laissez pas les gens s'enregistrer sans un examen du code par exemple. Demandez à l'architecte technique ou au chef d'équipe de revoir le code et de le rejeter jusqu'à ce qu'il "corrige" le style de code. Ils s'en lasseront bientôt et s'adapteront aux règles, cependant, peut-être aussi longtemps qu'ils seront contrôlés.

Bien sûr, certaines entreprises retirent complètement les privilèges d'enregistrement aux programmeurs juniors. Lorsqu'ils apprennent enfin les règles de codage des entreprises, ils obtiennent le privilège.


2
Si le placement de l'accolade est votre plus gros problème de qualité, je suppose que vous avez de la chance. Est-ce le bon niveau sur lequel se concentrer?
Bo Persson

Un exemple purement tiré de la question. Le principe étant que les «directives» de conception de code, comme le dit bethlakshmi ci-dessous, ne sont que des directives. Si vous êtes vraiment préoccupé par la façon dont ils sont suivis, alors des points dans le processus doivent se produire pour les rappeler / enseigner / les appliquer.
Martin Blore

Mais des accolades où vous pensez qu'elles devraient aller ... Cela en dit long. Je pense qu'il y a des aspects plus fondamentaux de la lisibilité du codage / des normes de codage que le placement des accolades. Je suis d'accord que tout le monde sur le projet devrait suivre la même norme mais l'un sur l'autre n'a pas beaucoup d'importance ici. Peut-être pouvez-vous les laisser "gagner" la bataille du placement des accolades en échange de leur acceptation de vos autres suggestions sur les normes de codage? Non seulement cela, mais ils se sentiront partie de la solution si leur idée de placement des accolades est dans les normes.
Gilles

1
Exactement. J'ai renoncé à convaincre un développeur de faire des crochets sur sa propre ligne, au lieu de crochets en ligne, en échange de son apprentissage de SOLID et TDD ... un excellent métier, je dirais;).
Martin Blore

1
"Bien sûr, certaines entreprises retirent complètement les privilèges d'enregistrement aux programmeurs juniors. Lorsqu'elles apprennent enfin les règles de codage des entreprises, elles obtiennent le privilège." - c'est la seule façon de le faire quand ça compte.
ocodo

2

Je pense que vous parlez de problèmes de niveaux très différents:

comment faire ceux à tête dure qui n'aiment pas utiliser les crochets dans les instructions if,

Il s'agit principalement d'un problème de style / lisibilité, sauf en cas de problème de priorité explicite de l'opérateur. Ce dernier ne devrait pas être très courant, et est testable de toute façon, donc facile à réparer. Les premiers peuvent facilement régresser dans une guerre sainte avec peu à gagner, mais de graves conséquences négatives pour le moral de l'équipe. Alors méfiez-vous - ne faites que pousser des règles éprouvées, qui ont été acceptées par au moins certaines équipes / communautés et qui ont fait leurs preuves.

ou utilisez la même chaîne de connexions partout dans le code,

Si vous parlez de Magic Constants, il s'agit en effet d'un problème de maintenance (plus potentiellement de sécurité), et à ce titre, à mon humble avis, tout développeur chevronné comprendra et acceptera qu'il s'agit d'une mauvaise chose.

ou quoi que ce soit, pour utiliser les règles de codage sans les contraindre à l'idée?

Vous ne pouvez pas forcer les gens à accepter les règles de codage - votre seule chance est de parvenir à une compréhension commune et à l'adhésion des membres de l'équipe via une discussion et un débat (parfois féroce) . Vous devez utiliser des arguments logiques et convaincants , en montrant la valeur derrière chaque règle et en expliquant comment le suivre va payer pour l'inconvénient d'ajuster des habitudes enracinées. D'un autre côté, nous nous efforçons de rendre la transition aussi simple que possible , en introduisant par exemple un formatage de code automatisé lors de l'enregistrement, conformément aux règles acceptées.

Pourtant, il suffit parfois d'accepter que les gens ont des opinions différentes , donc les règles de codage que tout le monde peut accepter seront indulgentes à certains égards. Acceptez cela et concentrez-vous sur les domaines où vous pouvez améliorer les choses avec moins d'effort.


"introduire un formatage de code automatisé lors de l'enregistrement, selon les règles acceptées" ... cela semble intéressant, d'autres idées sur l'endroit où je peux trouver quelque chose comme ça.
TheBoyan

@bojanskr, la plupart des IDE courants prennent actuellement en charge les règles de formatage de code dans une moindre ou plus grande mesure, et peuvent formater automatiquement votre code lors de l'enregistrement ou de l'archivage. Pour Java, Eclipse et IntelliJ le font, je suppose que NetBeans aussi, mais je n'ai pas beaucoup d'expérience avec cela. Pour C #, voir le commentaire de @ Job ci-dessus. Mais il existe également des outils autonomes, tels que le style artistique pour C / C ++. Et la plupart des SCC que je connais prennent en charge l'exécution de scripts / déclencheurs spécifiques à l'utilisateur lors de l'enregistrement par exemple.
Péter Török

2

Faites-les participer à l'établissement des règles. Cela aide généralement à encourager les gens à les suivre.


1

C'est à cela que sert la révision du code. Les réviseurs de code ne devraient pas laisser passer un code qui ne répond pas aux normes. Assurez-vous de ne pas assouplir les règles pour les correctifs urgents. Le fait d'avoir à refaire plusieurs fois sous pression pour le faire résoudra ceux qui hésitent à faire leur travail correctement la première fois.


1

La même chaîne de connexion partout? La solution à cela est de refactoriser jusqu'à ce que vous ayez supprimé toute la duplication. Les codeurs copier-coller devraient aller en prison pour programmeurs. (Ne riez pas! Steve Ballmer est le gardien.)

Mais le vrai problème ici est votre verbe "faire" . Vous ne pouvez pas obliger les programmeurs à faire quoi que ce soit, et si vous le faites, vous gaspillez leur caractéristique la plus précieuse: l'engagement intellectuel profond qui vient de travailler sur quelque chose qui vous tient à cœur.

La façon dont je le résoudrais:

  1. Insistez pour que l'équipe ait une norme de codage commune. Cela peut être long de 5 lignes, mais ils doivent tous être d'accord.
  2. Chaque fois que vous remarquez un argument, insistez pour qu'ils le règlent ensemble et le mettent dans la norme de codage. Si vous remarquez que les gens reformatent les choses dans les deux sens, traitez cela comme un argument.
  3. Chaque fois qu'un élément standard est convenu, voyez s'il existe un outil qui nettoiera la base de code entière à la fois.
  4. Tous les deux mois, passez en revue la norme de codage et voyez lesquels sont toujours vrais et pertinents. La norme documente simplement ce que les gens font. Et il est inutile de conserver dans la norme des éléments qui sont devenus évidents.

La programmation est un sport d'équipe ou une œuvre artistique collective. Ce sur quoi les gens s'accordent n'a pas autant d'importance que ce qu'ils sont d'accord, et ils parviennent à conclure de nouveaux accords si nécessaire.

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.