Récemment, j'ai basculé entre plusieurs projets et environnements de développement. Les attentes pour le style de codage dans chacun sont différentes.
Maintenant, ma question est en trois parties, la première, juste par curiosité:
Réponses:
№1. # Comment avez-vous défini et trouvé votre style de codage?
Grâce à des exemples de code d'abord dans des livres, puis dans des textes et articles MSDN, puis des blogs et autres sites Web.
№2. Comment continuez-vous à l'augmenter et à l'améliorer?
Je garde l'œil ouvert sur toutes les suggestions des gens. Je les essaie, s'ils travaillent pour moi, ils collent. J'expérimente aussi de temps en temps, ce qui semble s'améliorer reste avec moi.
№3. Comment l'entretenez-vous? (À partir de notes mentales, conserver un document, utiliser un outil comme StyleCop, etc.)
Je me souviens en quelque sorte de mon style et je l'applique automatiquement partout.
Remarque 1. Il est extrêmement important de garder l'œil ouvert et l'oreille bien aiguisée pour rester à jour. Il y a des années, j'ai appris des autres que la notation hongroise était un must donc je l'ai suivie. Lorsque la communauté a réalisé que ce n'était pas si bon, j'ai changé avec tout le monde.
Remarque 2. Il n'est souvent pas si important quels éléments de style particuliers vous adoptez mais plutôt que vous gardiez votre style cohérent tout au long de vos codes. Il en va de même pour une équipe. Choisissez un style mais respectez-le.
Remarque 3. Les styles de codage pour différentes langues peuvent varier. C ++ mérite un style, Java l'autre. HTML et CSS ont leurs caractéristiques nécessitent à nouveau un style différent.
Remarque 4. Quel que soit le style que vous choisissez, comprenez et acceptez qu'il ne fonctionnera pas à 100%. Parfois, vous avez du code qui nécessite un style différent juste en place, soit un fractionnement multiligne, un alignement différent ou autre pour que ce morceau de code particulier soit plus lisible. Ne poussez pas votre style partout, concentrez-vous sur la lisibilité du code. Si c'est évident, le style ne fonctionne pas à cet endroit particulier, faites une exception.
Remarque 5. Ne faites pas suivre un style de code à une religion. Les outils permettant d'appliquer un style de code sont bons, mais peuvent parfois vous rendre fou. J'ai par exemple désactivé la mise en forme automatique du code de Visual Studio car cela me rendait fou. Si un outil devient un obstacle, ajoutez simplement une exception et ne vous inquiétez pas que votre code n'est pas conforme à 100%. Ce n'est pas vraiment important et la perfection n'est pas réalisable de toute façon.
Je ne pense pas qu'il y ait eu un moment où j'ai dit: "Ok, ça va être mon style". Concentrez-vous sur un environnement ou un langage spécifique. Votre style doit refléter la façon dont vous faites face à un certain problème.
J'ai travaillé dans une équipe avec un jeu en source fermée que j'aimais et le développeur principal m'a encadré et m'a aidé à améliorer mes compétences après que je lui ai aussi demandé.
Il a suggéré, et j'ai adopté le style de codage du framework Zend (http://framework.zend.com/manual/en/coding-standard.html)
J'ai fini par adopter les caractéristiques de différents styles - y compris les styles reflétés sur MSDN. J'ai ensuite mis en place des modèles dans VS qui fournissent mes #region/#endregionblocs et tout ce qui est préférable.
Je continue d'étudier d'autres styles que je rencontre à travers la recherche et la lecture. Si je pense qu'il y a quelque chose qui se démarque et qui pourrait améliorer mon style en termes de lisibilité, de maintenance ou d'organisation, je l'essaie. Si un nouvel ajustement de style est en ordre, je mettrai à jour les modèles en VS ou prendrai des notes mentales.
En codant seul, je vise la brièveté; La programmation spartiate est peut-être complète, une folie folle ... Mais c'est probablement la chose la plus proche de ma croyance.
Lors du codage avec d'autres, en particulier le codage de maintenance, je vise à être un caméléon - mes changements devraient améliorer ce qu'ils modifient, sans regarder à leur place.
Comment avez-vous défini et trouvé votre style de codage?
En se concentrant sur la simplicité et la lisibilité (lisibilité! == compréhensibilité, voir Programmation Spartan )
Comment continuez-vous à l'augmenter et à l'améliorer?
En examinant les autres et mon propre code (et même les normes de codage elles-mêmes).
Comment l'entretenez-vous? (À partir de notes mentales, conserver un document, utiliser un outil comme StyleCop, etc.)
J'utilise dokuwiki , un jeu d'enfant à configurer (pas de base de données), une structure hiérarchique, un contrôle granulaire (ACL prêt à l' emploi ), un look vraiment sympa, et bien, c'est un wiki, donc tout le monde peut contribuer. De plus, les contributions / changements sont toujours consensuels et justifiés, basés sur la simplicité et la lisibilité.
C'est une sorte de réponse bizarre, mais j'ai vraiment mis beaucoup de temps à choisir la programmation. J'ai passé beaucoup de temps à travailler dans les «arts» avant de me considérer comme programmeur.
Lors du codage, j'ai tendance à penser en unités comme l'écriture - paragraphes, phrases, etc. Pour cette raison, je vais étaler le code sur plus de lignes dans le but de le rendre lisible comme une histoire / un essai / etc. Je suis vraiment ennuyé lorsque les développeurs essaient de charger autant que possible sur une seule ligne ou dans un petit espace, car cela ne fait rien d'autre que de rendre l'écrivain intelligent et ennuyeux pour les futurs lecteurs.
Si je dois faire quelque chose de bizarre pour des raisons d'efficacité, je vais le commenter pour expliquer pourquoi c'est comme ça.
Je n'obtiendrai probablement pas de votes positifs pour cela, mais peut-être que cela suscitera une discussion de toute façon.
Quant au côté technique, comme le placement des supports et autres, je les garde alignés car le résultat est une lisibilité accrue.
1. How did you define and find your coding style?
Je choisis d'adopter un guide de style déjà développé qui est largement développé et largement accepté ou popularisé par une grande entreprise / projet.
Je le fais pour de nombreuses raisons, mais principalement parce que de tels guides de style peuvent être immédiatement adoptés par les développeurs. Un guide de style ne vaut autant que les développeurs sont prêts à s'y tenir.
Le PEP 8 de Python , le guide de style Android pour Java , le guide de style jQuery Core ou le guide de style Python de Google en sont des exemples .
2. How do you keep augmenting and improving it?
Le plus grand argument pour de tels guides de style est qu'ils n'ont pas été inventés ici et non inventés par moi. Il a fallu des dizaines de développeurs, des lignes de code intimidantes et plus de temps que votre entreprise / équipe ne serait prête à investir pour développer et maintenir un guide de style.
En ce qui concerne les améliorations, il n'y a jamais eu de guide de style qui répond immédiatement à tout ce que vous pourriez avoir besoin de savoir. Mais, dans la plupart des cas, les améliorations que j'ai vues être poussées vers l'avant n'étaient qu'une version plus détaillée de ce que le guide de style avait déjà présenté avec son approche de l'écriture de code.
Dans de tels cas, lorsque vous rencontrez un bloc de bizarrerie, vous devez le coller dans un résumé ou dans un autre outil de partage d'extraits de code approprié avec prise en charge de la syntaxe des couleurs et en discuter quelque part avec d'autres développeurs. Ce qui est génial, c'est que dans de tels cas, vous n'êtes pas intéressé par ce que fait le code, mais par la façon dont le code apparaît, afin que vous puissiez sortir ce bloc de son contexte et discuter de la façon dont vous devriez l'améliorer, en le comparant à ce qui est déjà spécifié dans le guide de style comme point de départ principal des discussions.
3. How do you maintain it?
Eh bien, la grande chose est que vous aurez déjà des documents existants qui sont publiquement mis à jour en ligne.
En ce qui concerne le formatage du code, vous pouvez également aller plus loin et fournir à votre équipe des configurations de formateur pour leur éditeur préféré, ce qui devrait éliminer les difficultés et les conjectures sur le maintien d'apparences de pointe. En fait, je n'appellerais pas cela un effort supplémentaire, mais une partie intégrante du développement - il n'y a rien de pire que de faire un diff où 90% des changements de code étaient une vérification par quelqu'un du code correctement formaté / stylé parce que quelqu'un avait oublié de nettoyer avant d'avoir commis une énorme nouvelle fonctionnalité.
Si vous faites partie d'une équipe, vous devez toujours respecter la norme de l'équipe. Il y a beaucoup à dire pour utiliser une disposition générique et non la vôtre. Cela rend votre code plus facile à lire et à comprendre par les autres, ce qui est essentiel.