Pensez-vous qu'une société de logiciels devrait imposer aux développeurs un style de codage? [fermé]

https://stackoverflow.com/questions/145508

02-07-2019
|

Question

Si vous pensez que cela ne devrait pas être le cas, expliquez pourquoi.

Si oui, quelle est la profondeur des directives à votre avis? Par exemple, l'indentation du code devrait être incluse?

La solution

Je pense qu'une équipe (plutôt qu'une société ) doit se mettre d'accord sur un ensemble de directives pour un style raisonnablement cohérent. Cela facilite les choses pour la maintenance.

Quelle est la profondeur? Aussi peu profond que vous pouvez être d'accord. Plus il est clair et clair, plus il est probable que tous les membres de l’équipe puissent l’accepter et le respecter.

Autres conseils

Vous voulez que tout le monde lise et écrit du code de manière standard. Vous pouvez y parvenir de deux manières:

Clonez plusieurs fois un même développeur et assurez-vous qu'il subisse le même entraînement. J'espère qu'ils seront tous capables d'écrire le même code.
Donnez à vos développeurs existants des instructions explicites sur ce dont vous avez besoin. Onglets ou espaces pour l'indentation. Où les accolades sont assis. Comment commenter. Consignes de validation du contrôle de version.

Plus vous restez indéfini, plus la probabilité que l'un des développeurs se heurte à un style se heurte.

La société devrait imposer un certain style. Le style et la profondeur des directives doivent être décidés collectivement par la communauté des développeurs de la société.

Je fixerais certainement des directives sur les accolades, l'indentation, les noms, etc. Vous écrivez du code pour la lisibilité et la maintenabilité. Supposez toujours que quelqu'un d'autre lise votre code. Il existe des outils qui vont automatiquement formater votre code magiquement, et vous pouvez obliger tout le monde à utiliser l'outil.

Si vous êtes sur .Net, regardez stylecop, fxcop et Resharper

Pensez-vous qu'une société de logiciels devrait imposer aux développeurs un style de codage?

Pas de manière descendante. Les développeurs d’une entreprise de logiciels devraient s’entendre sur un style de codage commun.

Si oui, à votre avis, quelle devrait être la profondeur des directives?

Ils ne doivent décrire que les différences par rapport aux conventions bien connues, en essayant de minimiser les écarts. C’est facile pour des langages comme Python ou Java, un peu flou pour C / C ++ et presque impossible pour Perl et Ruby.

Par exemple, l'indentation du code devrait être incluse?

Oui, cela rend le code beaucoup plus lisible. Conservez la mise en retrait de manière cohérente en termes d'espaces par rapport aux tabulations et (si vous optez pour des espaces) en nombre d'espaces. En outre, convenez d’une marge (par exemple, 76 caractères ou 120 caractères) pour les lignes longues.

Oui, mais dans des limites raisonnables.

Tous les IDE modernes offrent une jolie impression du code en une seule frappe, donc & "; l'indentation &"; le point est tout à fait hors de propos, à mon avis.

Le plus important est d’établir les meilleures pratiques: par exemple, utilisez aussi peu " out " ou " ref " Les paramètres possibles ... Dans cet exemple, vous avez 2 avantages: améliorer la lisibilité et corriger beaucoup d'erreurs (beaucoup de paramètres sortants sont une odeur de code et devraient probablement être refactorisés).

Aller au-delà, c’est, à mon avis, un peu & "anal &"; et inutilement ennuyeux pour les développeurs.

Bon argument de Hamish Smith:

Le style est assez différent du meilleur les pratiques. C'est dommage que 'coder les normes ont tendance à rouler les deux ensemble. Si les gens pouvaient garder le partie de style à un minimum et se concentrer sur les meilleures pratiques ajouterait probablement plus de valeur.

Je ne crois pas qu'une équipe de développement devrait avoir des règles de style à suivre en règle générale. Il existe des exceptions, par exemple utilisation de & Lt; & Gt; " " dans #include statement , mais ces exceptions devraient provenir de la nécessité.

La raison la plus souvent invoquée par les gens pour expliquer la nécessité de directives de style est que le code écrit dans un style commun est plus facile à gérer que le code écrit dans des styles individuels. Je ne suis pas d'accord. Un programmeur professionnel ne va pas s’embourber quand il voit ceci:

for( int n = 0; n < 42; ++42 ) {
 // blah
}

... quand ils ont l'habitude de voir ceci:

for(int n = 0; n < 42; ++42 )
{
 // blah
}

De plus, j’ai trouvé qu’il était en fait plus facile de gérer le code dans certains cas si vous pouviez identifier le programmeur qui avait écrit le code original en reconnaissant simplement leur style. Allez leur demander pourquoi ils ont implémenté le gizmo de manière si compliquée en 10 minutes au lieu de passer la plus grande partie de la journée à déterminer la raison très technique pour laquelle ils ont fait quelque chose d'inattendu. Certes, le programmeur aurait dû commenter le code pour expliquer son raisonnement, mais dans la réalité, ce n’est souvent pas le cas des programmeurs.

Enfin, si cela prend à Joe 10 minutes d’arrière-plan & amp; déplaçant ses accolades pour que Bill puisse passer 3 secondes de moins à regarder le code, est-ce que cela a vraiment fait gagner du temps à Bill pour qu'il fasse quelque chose qui ne lui semble pas naturel?

Je pense qu’il est important d’avoir une base de code cohérente. Cela augmente la maintenabilité du code ur. Si tout le monde attend le même type de code, il peut facilement le lire et le comprendre.

En outre, ce n’est pas très compliqué, étant donné les IDE actuels et leurs capacités de mise en forme automatique.

P.S: J'ai cette habitude ennuyeuse de mettre mes accolades à la ligne suivante :). Personne ne semble aimer cela

Je pense que les programmeurs devraient être capables de s’adapter au style des autres programmeurs. Si un nouveau programmeur est incapable de s'adapter, cela signifie généralement que le nouveau programmeur est trop obstiné pour utiliser le style de la société. Ce serait bien si nous pouvions tous faire notre propre chose; Cependant, si nous codons tous selon certaines directives, cela facilitera le débogage et la maintenance. Cela n’est vrai que si la norme est bien pensée et pas trop restrictive.

Bien que je ne sois pas d'accord avec tout, ce livre contient un excellent point de départ pour les normes

La meilleure solution serait que les IDE considèrent ce formatage comme des métadonnées. Par exemple, la position de l’accolade (ligne actuelle ou suivante), l’indentation et les espaces blancs autour des opérateurs doivent pouvoir être configurés sans modifier le fichier source.

À mon avis, je pense que cela est absolument nécessaire avec les normes et les guides de style. Parce que lorsque votre base de code grandira, vous voudrez l’être cohérent.

En note de bas de page, c’est pourquoi j’aime Python; car il impose déjà pas mal de règles sur la structuration de vos applications et autres. Comparez cela avec Perl, Ruby ou peu importe où vous avez une liberté extrême (ce qui n’est pas si bon dans ce cas).

Il existe de nombreuses bonnes raisons pour que les normes définissent la manière dont les applications sont développées et la forme que devrait avoir le code. Par exemple, lorsque tout le monde utilise la même norme, un vérificateur de style automatique peut être utilisé dans le cadre du projet CI. L'utilisation des mêmes normes améliore la lisibilité du code et contribue à réduire la tension entre les membres de l'équipe à propos de la refactérisation du même code de différentes manières. Par conséquent:

Tout le code développé par l'équipe concernée doit respecter exactement le même standard.
Tout le code développé pour un projet particulier doit suivre exactement la même norme.
Il est souhaitable que les équipes appartenant à la même société utilisent le même standard.

Dans une entreprise de sous-traitance, une équipe travaillant pour un client peut faire exception à la règle si celui-ci souhaite appliquer une norme qui lui est propre. Dans ce cas, l'équipe adopte le standard du client qui pourrait être incompatible avec celui utilisé par leur société.

Comme d’autres l’ont mentionné, je pense que cela doit être fait par l’ingénierie ou par l’équipe - la société (c’est-à-dire les unités d’affaires) ne devrait pas être impliquée dans ce type de décision.

Mais j'ajouterais que toute règle mise en œuvre devrait être appliquée par des outils et pas par des utilisateurs. Le pire scénario, IMO, est un snob grammatical zélé (oui, nous existons; je sais parce que nous pouvons sentir le nôtre) écrit une documentation décrivant un ensemble de directives de codage que personne ne lit ni ne suit réellement. Ils deviennent obsolètes avec le temps, et à mesure que de nouvelles personnes s’ajoutent à l’équipe et que des personnes âgées partent, elles deviennent simplement obsolètes.

Ensuite, un conflit surgit et quelqu'un est mis dans une position inconfortable lorsqu'il doit confronter quelqu'un d'autre à propos du style de codage - ce type de confrontation doit être fait par des outils et non par des personnes. En bref, cette méthode de mise en application est la moins souhaitable, à mon avis, car il est beaucoup trop facile de l'ignorer et elle demande simplement aux programmeurs de discuter des choses stupides.

Une meilleure option (encore une fois, IMO) consiste à faire émettre des avertissements au moment de la compilation (ou quelque chose de similaire), tant que votre environnement de génération le permet. Il n’est pas difficile de configurer cela dans VS.NET, mais je ne connais pas d’autres environnements de développement dotés de fonctionnalités similaires.

Les directives de style sont extrêmement importantes, qu’elles soient de conception ou de développement, car elles accélèrent la communication et les performances des personnes qui travaillent en collaboration (ou même seules, de manière séquentielle, comme lorsqu’il s’agit de reprendre les éléments d’un projet ancien). Ne pas avoir un système de convention au sein d'une entreprise, c'est simplement demander aux gens de ne pas être aussi productifs que possible. La plupart des projets nécessitent une collaboration, et même ceux qui ne le font pas peuvent être vulnérables à notre désir naturel d’exercer nos talents de programmeurs et de rester à jour. Notre désir d'apprendre nuit à notre cohérence - ce qui est une bonne chose en soi, mais peut rendre fou un nouvel employé qui essaie d'apprendre les systèmes sur lesquels il se lance.

Comme tout système conçu pour le bien et non pour le mal, le véritable pouvoir du guide repose entre les mains de son peuple. Les développeurs eux-mêmes détermineront quels sont les éléments essentiels et utiles et les utiliseront ensuite, si tout va bien.

Comme la loi. Ou la langue anglaise.

Les guides de style doivent être aussi profonds qu’ils le souhaitent. Si cela se produit au cours de la séance de remue-méninges, il doit être inclus. C'est étrange comment vous avez formulé la question car à la fin de la journée, il n'y a aucun moyen d'imposer & "Imposer &"; un guide de style car ce n'est qu'un GUIDE.

RTFM, glanez les bonnes choses et continuez.

Oui, je pense que les entreprises le devraient. Les développeurs doivent peut-être s'habituer au style de codage mais, à mon avis, un bon programmeur devrait être capable de travailler avec n'importe quel style de codage. Comme l'a dit Midhat: Il est important d'avoir une base de code cohérente.

Je pense que cela est également important pour les projets opensource. Aucun superviseur ne vous dit comment écrire votre code, mais de nombreuses langues ont des spécifications sur la manière dont la dénomination et l'organisation de votre code devraient être. Cela aide beaucoup lors de l’intégration de composants opensource dans votre projet.

Bien sûr, les directives sont bonnes et, à moins que la notation hongroise soit mal utilisée (ah!), cela améliorera probablement la cohérence et facilitera la lecture du code des autres utilisateurs. Les directives ne devraient cependant être que des directives, pas des règles strictes imposées aux programmeurs. Vous pouvez me dire où placer mes accolades ou ne pas utiliser de noms tels que temp, mais vous ne pouvez pas forcément me forcer à laisser des espaces autour des valeurs d'index entre crochets de tableau (ils ont essayé une fois ...)

Oui.

Les normes de codage sont un moyen courant d’assurer que le code d’une organisation donnée respecte le principe de moindre surprise: cohérence des normes, de la dénomination des variables à l’indentation, en passant par l’utilisation des accolades.

Les codeurs ayant leur propre style et leurs propres normes produiront uniquement une base de code incohérente, source de confusion et frustrante à lire, en particulier pour les projets plus importants.

Ces sont les normes de codage d'une entreprise pour laquelle je travaillais auparavant. Ils sont bien définis et, même s’il m’a fallu un certain temps pour m’y habituer, cela signifiait que le code était lisible par tous et uniforme.

Je pense effectivement que les normes de codage sont importantes au sein d'une entreprise. Si aucune règle n'est définie, il y aura des conflits entre développeurs et des problèmes de lisibilité.

Le fait que le code soit uniforme à tous les égards offre un meilleur code à l'utilisateur final (il semble donc qu'il ait été écrit par une seule personne - ce qui, du point de vue de l'utilisateur final, devrait le faire - cette personne étant & "la société &" et cela contribue également à la lisibilité au sein de l'équipe ...

Un style de codage commun favorise la cohérence et facilite la compréhension, la maintenance et l’extension de la base de code pour différentes personnes, et pas seulement pour leurs propres morceaux. Cela facilite également l'apprentissage rapide du code par les nouvelles personnes. Ainsi, chaque équipe devrait avoir des directives sur la manière dont le code devrait être écrit.

Les instructions importantes incluent (sans ordre particulier):

les espaces et l'indentation
commentaires standard - en-têtes de fichier, de classe ou de méthode
convention de dénomination - classes, interfaces, variables, espaces de noms, fichiers
annotations de code
organisation du projet - structures de dossiers, fichiers binaires
bibliothèques standard - quels modèles, génériques, conteneurs, etc. utiliser
traitement des erreurs - exceptions, résultats, codes d'erreur
threading et synchronisation

Aussi, méfiez-vous des programmeurs qui ne peuvent pas ou ne vont pas s'adapter au style de l'équipe, aussi brillante soit-elle. S'ils ne respectent pas les règles de l'équipe, ils ne joueront probablement pas non plus selon les règles de l'équipe.

Je conviens que la cohérence est la clé. Vous ne pouvez pas vous fier à l'impression IDE pour faire des économies, car certains de vos développeurs peuvent ne pas aimer utiliser un IDE, et parce que lorsque vous parcourez une base de code contenant des milliers de fichiers source, il est tout simplement impossible de le faire. imprimez tous les fichiers lorsque vous commencez à travailler dessus, puis effectuez une restauration ultérieure afin que votre VCS n'essaye pas de restituer toutes les modifications (encrassant le référentiel de mises à jour inutiles qui surchargent tout le monde).

Je suggérerais de normaliser au moins les éléments suivants (par ordre d'importance décroissante):

Espace blanc (il est plus facile de choisir un style qui se conforme à l’impression automatique jolie d’un outil partagé)
Dénomination (fichiers et dossiers, classes, fonctions, variables, ...)
Commentaires (en utilisant un format permettant la génération automatique de documentation)

Mon avis:

Certaines règles de base sont bonnes car elles aident tout le monde à lire et à maintenir le code
Trop de règles sont mauvaises car elles empêchent les développeurs d'innover avec des moyens plus clairs de structurer le code
Un style individuel peut être utile pour déterminer l'historique d'un fichier de code. Des outils diff / blame peuvent être utilisés, mais la suggestion est toujours utile

Les IDE modernes vous permettent de définir un modèle de formatage. S'il existe une norme d'entreprise, développez un fichier de configuration qui définit toutes les valeurs de mise en forme qui vous intéressent et assurez-vous que tout le monde exécute le formateur avant d'insérer son code. Si vous souhaitez être encore plus rigoureux à ce sujet, vous pouvez ajouter un crochet de validation pour que votre système de contrôle de version indente le code avant qu'il ne soit accepté.

Oui, en ce qui concerne l’utilisation d’une norme de dénomination commune, ainsi que d’une présentation commune des classes et du code derrière les fichiers. Tout le reste est ouvert.

Chaque entreprise devrait. Un style de codage cohérent assure une lisibilité et une maintenabilité supérieures du code sur l'ensemble de votre équipe.

Le magasin dans lequel je travaille n’a pas de norme de codage unifiée, et je peux dire que nous (en tant qu’équipe) en souffrons énormément. Lorsqu'il n'y a pas de volonté de la part des individus (comme dans le cas de certains de mes collègues), le chef d'équipe doit taper du poing sur la table et imposer une forme ou une autre de directives de codage normalisées.

Chaque langue a des normes générales qui sont utilisées par la communauté. Vous devez suivre ces instructions autant que possible afin que votre code puisse être mis à jour par des personnes habituées au langage, sans qu'il soit nécessaire d'être dictatorial.

La création d'une norme officielle est fausse, car une norme de codage d'entreprise est généralement trop rigide et incapable de s’adapter à la communauté en utilisant le langage.

Si vous rencontrez un problème avec un membre de l’équipe dans le style de codage, c’est une excellente chose à suggérer gentiment au groupe. Ce n’est pas une bonne idée de procéder à une révision du code.

Normes de codage: OUI. Pour des raisons déjà abordées dans ce fil de discussion.

Normes de style: NO. Votre lisible, est mon ordure ahurissant, et vice versa. De bons commentaires et l’affacturage ont un avantage bien plus grand. Également indent.

J'aime la réponse de Ilya car elle intègre l’importance de la lisibilité et l’utilisation de l’intégration continue comme mécanisme d’application. Hibri a mentionné FxCop, et je pense que son utilisation dans le processus de construction comme l’un des critères permettant de déterminer si une construction réussit ou échoue serait plus souple et plus efficace que la simple documentation d’une norme.

Je suis tout à fait d’accord pour dire que les normes de codage devraient être appliquées et qu’elles devraient presque toujours se faire au niveau des équipes. Cependant, il existe quelques exceptions.

Si l'équipe est en train d'écrire du code qui sera utilisé par d'autres équipes (et je veux dire par là que les autres équipes devront regarder la source, pas seulement l'utiliser comme une bibliothèque), il est avantageux de créer des normes communes pour tous. toutes les équipes l'utilisant. De même, si la politique de la société est de déplacer fréquemment les programmeurs d’une équipe à l’autre, ou si une équipe souhaite fréquemment réutiliser le code d’une autre équipe, il est probablement préférable d’imposer des normes à l’ensemble de la société.

Il existe deux types de conventions.

Conventions de type A: & "S'il vous plaît, faites-les, il vaut mieux &";

et Type B: & "Conduisez s'il vous plaît du côté droit de la route &"; alors que vous pouvez conduire de l'autre côté, tant que tout le monde fait de même.

Il n’existe pas d’équipe distincte. Tout le code dans une bonne entreprise est lié d'une manière ou d'une autre et le style doit être cohérent. Il est plus facile de vous habituer à un nouveau style qu'à vingt styles .

De plus, un nouveau développeur devrait être capable de respecter les pratiques de la base de code existante et de les suivre.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow