Je suis personnellement un très grand fan de la suite de normes de codage internes lorsque vous travaillez avec un groupe de développeurs. J'entreprise que cela apporte une continuité au code et permet aux personnes de développer plus facilement la base de code, d'éteindre le travail et de s'entraider avec des tâches difficiles. D'autre part, je suis conscient qu'un ensemble de personnes conviennent à la conviction que tant que le codage se fait à temps et cela fonctionne que nous devrions embrasser les différences dans le style de codeur individuel.
Voir les deux côtés de la pièce, je trouve qu'il est difficile de décider si un style de programmer vaut quelque peu la valeur (parfois marginale et parfois grande) gagnée en ayant une base de code compatible équitablement compatible. Surtout lorsque vous travaillez dans le cadre de développement agile où la vitesse est importante, je pense que cela devient une question encore plus importante.
Exacerber la situation Je suis un programmeur PHP, vous allez donc très rarement rencontrer deux codeurs avec le même style puisqu'il s'agit en grande partie d'une discipline autodidacte.
est-il préférable d'avoir un ensemble de normes lâches comme des suggestions et ne manda que les éléments très importants (comme restreindre la notation hongroise dans des noms variables) ou est-il préférable d'être du fer fisté et de nécessiter des trindages et non des espaces et de ce supports toujours être sur une ligne de leur propre.
EDIT:
aurait dû voir mon erreur dans la question - je suppose que je suis intéressé à la manière dont la norme devrait être stricte - devrait-elle avoir beaucoup de latitude ou devrais-je le verrouiller fort?
13 Réponses :
Oui, ils devraient suivre la norme. Sinon, c'est un gâchis.
Si vous démarrez une équipe - vous pouvez créer un document basé sur votre style de codage .
Si ce n'est une équipe existante, vous feriez mieux de trouver la norme que tout le monde est convenu en le discutant d'abord.
Oui, une équipe (que ce soit une équipe professionnelle ou open source ou groupe de loisirs, ou autre) devrait avoir ses règles de codage que chaque membre suive, sinon ce sera un gros gâchis; Encore plus si vous n'utilisez pas de système de contrôle source (qui, même en tant que développeur unique, vous êtes utile de toute façon).
Il existe certaines zones que vous n'avez pas à être si stricte (par exemple, formatage, espaces, que vous pouvez "appliquer" par un logiciel dans votre contrôle source commettrie, alors alors qu'ils codent, ils peuvent faire cependant ils Comme, mais le moment où il atteint le contrôle de la source, il est normalisé), mais d'autres domaines, en particulier les conventions de dénomination doivent être très strictes, car cela n'est pas changeant par un programme qui facilement. Par exemple, utilisez des noms descriptifs au lieu d'une lettre simple
vs
Ce dernier est beaucoup plus lisible et descriptif que le premier.
Quelle que soit la forme ou la forme de vos conventions, assurez-vous que tout le monde peut donner leur propre adpinion lorsque vous les implémentez, mais ne dépensez pas trop de temps en discutant. De cette façon, les gens peuvent énoncer leur propre adpinion et ne pas se sentir avancés. pour (int i = 0; i pour (int comptage = 0; Nombre
J'espère vraiment que vous ne considérez pas le code que vous avez fourni un bon exemple d'utilisation des noms de variables descriptifs.
Actalle au fil du temps (lorsque vous vous y habituez), le premier devient plus lisible parce que tout le monde sait que je suis une variable de suivi en boucle alors que le nombre est un peu plus générique et sera souvent utilisé pour d'autres choses pouvant être comptées. De plus, je suis plus court, votre cerveau est capable de le traiter visuellement avec un coup d'œil rapide (à temps) plutôt que de devoir le lire.
Nul doute @IntPerd, je n'utilise pas ce dernier non plus, était probablement un mauvais exemple pour la dénomination des conventions.
En pratique, j'ai découvert qu'il était beaucoup plus important d'être strict quand il s'agit de nommer que d'être strict sur formatage . .
Heureusement, il est beaucoup plus facile de rassembler un ensemble de normes pour la dénomination.
Tant que le code de quelqu'un n'est pas un chemin du sentier battu en ce qui concerne la lisibilité, je ne vois pas pourquoi il serait nécessaire de restreindre leur propre style personnel.
+1, la plupart des arguments sur le formatage sont muet si vous avez un bon éditeur / IDE. Ne vous battez pas sur les préférences personnelles, en particulier Pas quand il y a des outils pour atténuer ou annuler la question.
+1 - Standardiser uniquement ce qui a du sens. Évitez la tentation de tout dicter pour des raisons de cohérence. @Volkerk - Vous voulez dire moot
@Scott: Oups, Ops, Bien sûr ...
Je conviens qu'il devrait y avoir des normes. J'ai choisi un ensemble particulier d'options de formatage automatique dans Visual Studio 2008 et si tous les autres développeurs importent ces paramètres.
Parmi les problèmes que vous pouvez facilement rencontrer avec des styles différents est les espaces infâmes VS onglets. Dans VS 2008, il existe parfois une situation dans laquelle vous pouvez avoir des styles d'indentation mixtes et frapper Avoir une similitude de style forcée empêche également les commits dans votre nettoyeur de contrôleur de contrôle source préféré, car vous n'avez pas de développeurs qui changent en formatage de chaque autre.
EDIT: concernant la latitude, j'ai quelques directives pour mes développeurs concernant la dénomination des conventions et la lisibilité, mais pas de règles strictes, à l'exception de la mise en forme (quelle ligne une attelle d'ouverture se passe et ainsi de suite). Cela ne me dérangerait pas si l'un d'entre eux mettait des champs privés en bas ou au sommet. Si j'étais ajouté un nouveau, je voudrais imiter.
Votre question est simplement vague et générale, vous obtiendrez donc des réponses générales. Je dis juger chaque aspect du style individuel séparément et quelles sont ses conséquences. ctrl-e, d pour formater l'ensemble du document peut causer à VS to crash.
Les normes de codage ou tout autre type de processus ne sont pas de remplacement pour les compétences. Si votre équipe est compétente et que vous obteniez le travail (et que je veux dire, cela signifie également que ce qu'ils produisent est maintenu), les normes de codage ne vous obligent pas vraiment nulle part.
Ne pas être disposé à coder à la norme est une indication du genre d'inflexibilité que vous ne voulez pas vraiment sur votre équipe de développement. Si votre équipe est qualifiée, il y a une assez bonne chance qu'ils codent déjà de la norme. S'ils ne sont pas habiles, vous aurez beaucoup d'autres problèmes,
Liz - Exactement. Des projets récents que j'ai travaillé avec des équipes qualifiées avec peu de normes de codage ont changé d'avis sur les normes. (20 ans et plus de ce genre de choses)
Quoi que vous disiez que vos normes sont, vos normes réelle sont ce que vous appliquez.
La créativité de personne n'a été blessée par des règles sur le nombre d'espaces ni où les accolades vont. D'autre part, il peut être utile d'obtenir un éditeur qui remplacera les onglets avec des espaces (ou inversement).
Un problème avec permettant à tous les développeurs d'exprimer leur créativité par le biais de la mise en forme, c'est que c'est ce qu'ils vont faire: Passez du temps à reformater des choses pour correspondre à leurs idées, plutôt que de refactoriser.
Vous ne voulez pas ça.
Assurez-vous que le code est examiné et qu'une partie de l'examen est format. Si vous avez des développeurs qui se sont pliés de la forme par cela, ils ne sont probablement pas si spectaculaires qu'ils se considèrent comme eux-mêmes.
Peut-être que j'ai travaillé sur des trucs particulièrement odieux, mais parfois je ne peux pas refroidir avant d'avoir également reformaté. Je pense que la norme devrait être "Ne sois pas stupide avec la latitude que tu as".
@Shea Yep. J'ai aussi eu l'expérience de formats si hideux que je ne pouvais pas comprendre ce que l'auteur signifiait.
Selon la langue que vous utilisez, vous pouvez acheter des reformateurs intelligents hors-the-étagère qui prendra le code source et le masser, sans changer le sens réel (DUH!), à peu près de toute "norme de codage" ( Lire: Règles arbitraires concernant l'indentation, le style de la corset et ce que vous voulez.
Une fois que j'ai examiné les coûts d'autre jour à propos de US $ 35 Qté 1, 1000 USD pour une licence de site. C'est le poulet. Vous dépenserez probablement plus que cela sur du papier toilette.
Créer une partie de la réforme de votre procédure de vérification du code source et ne vous inquiétez pas.
Je pense que c'est un mauvais conseil - le formatage automatique d'un travail d'ingénieurs sans leur connaissance va se retrouver avec eux de détenir le travail lorsque quelque chose doit avoir besoin d'entretien / fixation.
@Jbrwilkinson - Si vous laissez les développeurs format de leur code (Ala Keystroke dans l'IDE avec un ensemble partagé de règles de formatage), ils peuvent voir ce que le formateur effectue avec leur code et ajusté pour obtenir un résultat qu'ils sont satisfaits.
Le désavantage est une métaphore intéressante. J'ai toujours pensé que l'une des bonnes choses sur les normes de code est que cela indique clairement les développeurs qu'ils ne possèdent pas le code qu'ils écrivent sur le temps de l'entreprise, ce qui ne les absolite pas le moins de la responsabilité des décisions de codage qu'ils Fabriquer.
@Donal - mais le grand code n'est-il pas écrit par les développeurs qui ressentent un sentiment de propriété? Pourquoi voudriez-vous quelque chose pour rappeler constamment les développeurs qu'ils n'ont aucune propriété sur ce qu'ils créent. Cela ne les encouragera-t-il pas à devenir 9-5'ers au lieu de codage dédié - dans la nuit des héros de classe ouvrière?
Si je rencontrais la fonction d'annotation / blâme SVN / CVS, qui serait l'auteur du code?
@Scott, je ne suis pas en désaccord. Je suppose que ce que j'essayais d'avoir à passer était que si le développeur dédié au codage dans la nuit tombe sous un bus, la chose qu'ils travaillaient ne seront pas considérées comme un grand roman inachevé - le code doit être laissé dans un état où un collègue pourrait ramasser là où ils se sont arrêtés. Styles personnels pour des projets personnels, styles d'entreprise pour les projets d'entreprise, espérons toujours la fierté et l'accomplissement dans son travail.
@Donal: Dans le travail séminal "La psychologie de la programmation informatique", Weinberg soutient, entre autres choses, ce "désavantage" du code est exactement ce qui devrait être fait. Il appelle cela "Programmation Egoless". Ce que vous voulez, c'est pour tout (ou au moins plusieurs) de vos programmeurs de pouvoir choisir un code donné et courir avec elle. Certaines personnes pensent que cela nécessite des «normes de codage». Je soutiens que cela nécessite des programmeurs éduqués, qui sont cru par la direction d'être beaucoup plus coûteux que les normes de codage arbitraires.
Premièrement, puisque vous soulevez la notation hongroise, voici le lien obligatoire de Joel fausse code Regardez mal article. :-) Il discute de l'utilisation de Hongrois dans ce que Joel considère les bonnes et les mauvaises manières.
En principe, je vais accepter qu'une norme de groupe est une bonne chose. En pratique, mon expérience a été difficile d'accepter - par ex. Une personne va devenir religieux sur l'ouverture des parens étant à la fin de la ligne, tandis qu'un autre sera tout aussi religieux de les avoir sur une ligne par elles-mêmes. Ils sont également difficiles à appliquer, surtout s'il n'y a aucun cri de code ni autre mécanisme pour vous assurer que le code est conforme à la norme. Je dirais que je ferais de quoi ce qui fonctionne mieux; par exemple. Dans mon exemple précédent, la seule méthode semble raisonnablement lisible, alors laissez peut-être cette diapositive, mais si vous utilisez une convention de nommage variable, ne le laissez pas glisser lorsque quelqu'un essaie d'utiliser «A» pour une variable contenant un nom de client! / p>
+1 pour le faire un mauvais code look faux lien
Je collerais des normes en vrac. Aucun programmateur que j'ai jamais travaillé a eu des problèmes d'adaptation au style de codage utilisé par un autre, il ne vaut donc pas la peine d'irriter tout le monde en essayant d'être draconique. Les choses importantes à appliquer sont des conventions de dénomination cohérentes et de l'indentation sain d'esprit, car la lisibilité du code est importante. Bien entendu, la correction de code et la maintenabilité sont encore plus importantes, des critiques de code, qui peuvent couvrir tous les aspects de la qualité du code, sont essentiels.
Vous pouvez utiliser l'option de mise en forme du code dans Eclipse si le code de lecture formaté différent de celui utilisé est important.
Nous avons fait cela sur un projet; passé autour des paramètres de format Eclipse pour tout le monde à utiliser. Certes, c'était agréable d'avoir cette cohérence et d'éviter les deltas inutiles dans le contrôle de la source. Les codeurs moche ont toujours eu tendance à ne pas l'utiliser, même si c'était juste un Keystroke unique ... (soupir)
Jon (ci-dessus) est absolument juste que la nommée est la chose importante à standardiser. Mais il doit y avoir un certain degré de normalisation dans le codeBase pour tout produit donné. Soutenir les nouveaux développeurs de l'équipe.
Si vous n'avez pas raccroché sur une construction vraiment rapide et que vous trouverez des «formateurs automatiques» disponibles pour votre langue, vous pouvez créer de la méta-code dans le cadre de la construction.
Vous pouvez garder deux arbres distincts, un pour référence seulement et un pour travailler réellement. Les développeurs écrivent dans n'importe quel style qu'ils veulent ( Un autre outil que j'ai trouvé utile dans les commentaires du code est le réflecteur pour .NET qui me permet de choisir la langue de voir un assemblage décompilé. Je ne suis généralement pas intéressé par des noms de variables privés et cela garantit que je ne suis plus jamais Examiner "Code compilable"
Oups .... presque oublié ... Toujours mandater que les développeurs utilisent les fonctions de documentation sur les langues dans la mesure du possible au lieu de commentaires qui ne seront disponibles que dans le code source. Le processus de construction doit toujours mettre à jour la documentation disponible pour le reste de l'équipe.
Je ne suis pas sûr que quelqu'un ait encore couvert cela, mais dans mon expérience, l'aspect le plus important des normes de codage est que tous les membres de l'équipe sont d'accord avec eux . Oui, il est vraiment difficile d'obtenir un groupe de programmeurs intelligents à tous d'accord sur quelque chose de plus litigieux que les normes de codage, mais je le découvre que cela paie des dividendes pour en discuter jusqu'à ce que quelque chose de fonctionnement soit convenu.
Dans un rôle précédent, j'ai eu une variété de programmeurs qualifiés utilisant un certain nombre de plates-formes différentes pour le développement sur une variété d'objectifs. Le travail était principalement basé sur C et était complexe. Nous avons convenu de choses comme:
Les avantages étaient:
Dans les rôles plus récents, j'ai constaté qu'il était presque impossible de «appliquer» les normes de codage, cela doit être faite doucement.
Pour ce que ça vaut la peine, j'ai constaté que lorsque vous aurez une durée limitée et de l'énergie à consacrer à la qualité du code d'une équipe, elle peut être utilisée plus efficacement sur les critiques de code. Correctement nommé, le code médiocre espacé n'est toujours pas un code médiocre. Si vous avez le temps pour les deux, par tous les moyens font les deux. Mais si vous deviez choisir ...
Comme vous pouvez le voir de ma réponse: tout ce que vous êtes strict, c'est la norme. Donc, si vous n'allez pas être «strict», vous n'avez pas de norme. Cela étant dit, il ne faut pas plus de temps pour nommer des choses, indenter les choses et mettre des accolades sur les choses de manière «standard» qu'un non-standard. Je crois que votre norme devrait être tout ce qui vous fera démanger pour le changer s'il n'est pas appliqué.
Je suis tout à fait d'accord avec ce que vous avez dit là-bas - mais je suis également préoccupé par des choses comme le moral de l'équipe et que les gens se sentent étouffés lorsqu'ils demandent de changer les habitudes de longue date en raison de mon style (ou d'un autre codeur). Personnellement, je mets tous les accolades sur des lignes individuelles - me rend fou quand je vois quelque chose comme si () {, mais difficile pour moi d'expliquer que quelqu'un d'autre est "faux" de faire ça.
Si de nouvelles personnes rejoignent une équipe, il y a une chance raisonnable que certains d'entre eux auront des habitudes différentes de la norme de l'équipe. Donc, l'attitude envers les normes de codage devient une partie de votre pratique d'entrevue. Je dis cela comme une personne avec des sentiments assez forts sur le "droit" était de placer des accolades, etc., qui a dû modifier cela sur différentes équipes.