Ecrivez-vous réellement du «code propre»?
J'ai vu des programmeurs peaufiner leur code encore et encore non seulement pour le faire "bien fonctionner", mais aussi pour le faire "bien paraître".
OMI, le "code propre" est en fait un compliment indiquant que votre code est élégant, parfaitement compréhensible et maintenable. Et la différence apparaît lorsque vous devez choisir entre un code esthétiquement attrayant et un code stressant à regarder.
Alors, combien d'entre vous écrivent réellement du "code propre"? Est-ce une bonne pratique? Quels sont les autres avantages ou inconvénients de cela?
Je dirais que beaucoup d'entre nous n'écrivent pas de code propre . Et généralement, ce n'est pas notre travail. Notre travail en tant que développeurs de logiciels est de fournir un produit qui fonctionne, dans les délais.
Je me souviens du billet de blog de Joel Spolsky: The Duct Tape Programmer .
Il cite Coders at Work :
À la fin de la journée, expédiez le truc f ***** g! C'est génial de réécrire votre code et de le rendre plus propre et pour la troisième fois, ce sera vraiment joli. Mais ce n'est pas le sujet - vous n'êtes pas ici pour écrire du code; vous êtes ici pour expédier des produits. - Jamie Zawinsky
Je me souviens aussi de réponse du blog de Robert Martin :
Donc. Soyez intelligent. Sois propre. Soit simple. Navire! Et gardez un petit rouleau de ruban adhésif prêt à l'emploi, et n'ayez pas peur de l'utiliser. - Oncle Bob
Si le code écrit par un développeur se trouve être propre ET fonctionner (est livrable), qu'il en soit ainsi, bon pour tout le monde. Mais si un développeur essaye de créer du code propre et lisible au détriment de pouvoir le livrer en temps opportun, alors c'est mauvais. Faites-le fonctionner, utilisez du ruban adhésif et expédiez-le. Vous pouvez le refaçonner plus tard et le rendre super magnifique et efficace.
Oui, c'est une bonne pratique d'écrire du code propre, mais jamais au détriment de la livraison. L'avantage de livrer un produit scellé à temps dépasse de loin les avantages d'un code propre qui n'a jamais été fini et livré.
Un bon morceau de code que j'ai rencontré n'est pas propre. Certains sont carrément moches. Mais ils ont tous été libérés et utilisés dans la production. Certains peuvent dire qu'il n'est pas professionnel d'écrire du code désordonné. Je ne suis pas d'accord. La chose professionnelle est de fournir du code qui fonctionne, qu'il soit propre ou salissant. Le développeur doit faire de son mieux, compte tenu du temps qui lui a été alloué avant la livraison. Ensuite, revenez pour nettoyer - c'est professionnel. Espérons que le code fourni ne soit pas du pur ruban adhésif et qu'il soit "suffisamment propre".
Vous devez vous assurer que votre code est très lisible, propre et maintenable. C'est ce que tous les programmeurs doivent faire.
Mais vous parlez de over styling (comme ce terme mieux que girl-code ) qui ne sert que l'ego de son auteur.
J'ai vu de nombreux développeurs dans le passé si fiers de leur création (vous savez, comme dans les toilettes;)), ils ont passé des heures à nettoyer et à polir leur code. Certains d'entre eux étaient si méticuleux qu'ils ont veillé à ce que les espaces blancs corrects entre les membres soient respectés.
C'est trop.
Je trouve ce genre de comportement contre-productif. Dans un contexte professionnel , vous devez être professionnel . Vous pouvez obtenir votre satisfaction en écrivant du code propre, très lisible et maintenable et en discutant avec des utilisateurs ou des collègues heureux.
Je ne suis pas d'accord avec la réponse acceptée sur cette question.
Votre responsabilité est évidemment d'expédier, mais généralement vous avez également la responsabilité d'expédier quelque chose qui est maintenable aussi rentable que possible par vous-même et les futurs développeurs.
J'ai passé des périodes en tant que pauvre programmeur de maintenance ou consultant sur site qui doit comprendre et déboguer un énorme système non documenté, et je peux vous dire que des conceptions médiocres et un code confus et désordonné peuvent entraîner des heures voire des jours d'efforts inutiles. Je peux penser à beaucoup de situations où N heures supplémentaires d'effort de la part du développeur initial auraient pu conduire à une économie de 5N en termes de temps.
Je sais qu'il existe une statistique à ce sujet, mais d'après mon expérience sur plusieurs projets, chaque ligne de code écrite est lue 5 à 20 fois pendant l'extension et la maintenance.
Je dirais donc nettoyer le code à un pouce de sa vie. Cela prend du temps, mais c'est probablement une économie nette sur la durée de vie du projet.
Est-ce que n'importe lequel d'entre nous achèterait une voiture si nous savons que sous le capot, tout est difficile et difficile à dépanner, à entretenir ou à réparer et qu'il faut plus de ressources pour fonctionner qu'il ne le devrait?
Pourquoi devrait-il en être autrement pour un logiciel?
Ce n'est pas parce que les utilisateurs finaux ne peuvent pas regarder sous le capot qu'ils ne le sauront jamais. Tôt ou tard, il apparaîtra.
Répondre à la question "Écrivez-vous réellement du" code propre "?" -- Oh oui.!
Si par "code propre" vous voulez dire que je fais tout mon possible pour m'assurer que le code est aussi clair que possible?
Heck oui.
Plus le code est propre et clair, plus il est facile à maintenir et vous fait ainsi gagner du temps à long terme. Ne regardez pas le code propre comme une vanité; considérez-le comme un investissement pour économiser du temps et des efforts futurs.
Honnêtement, cela dépend. J'aime la façon dont tout le monde parle de la façon dont "rien de moins qu'un code propre et bien documenté est une pure parodie!", Mais je travaille dans une entreprise avec des cycles de déploiement ridicules et sans surveillance: je fais de mon mieux, mais j'écris ainsi beaucoup de code, il est extrêmement difficile d'écrire le code propre parfait que tout le monde prétend qu'ils écrivent.
J'essaie d'écrire du code qui peut être facilement maintenu par quelqu'un qui a à peu près mes capacités. Je commente les parties délicates, je nomme les programmes, les variables et les noms conviviaux des classes, je déploie et je continue. Je n'ai pas le temps de faire autre chose.
Parfois, je me sens un peu coupable, mais pas très. Vous devriez voir certaines des horreurs auxquelles je fais face quotidiennement. Des décennies de code personnalisé dans des langages obscurs sans aucune documentation. Un de mes collègues développe exclusivement dans Visual Basic 6.0 et déploie des binaires nommés de manière cryptique partout. La femme que j'ai remplacée a programmé exclusivement en RPG .
Il est juste extrêmement difficile pour moi de croire, autant de conneries horribles que j'ai vues pendant mes années en tant que programmeur, que tout le monde ne génère que du code propre.
Je ne pense pas que j'aime le terme "code fille", mais code propre = code maintenable. Rien de moins n'est pas professionnel.
En règle générale, je considère le prochain développeur qui doit regarder mon désordre.
La plupart du temps c'est moi ... plusieurs mois plus tard ... quand je ne me souviens plus comment ça marche ... et j'ai encore moins de temps pour faire un changement.
J'essaie d'écrire du "code propre" dans le sens de Bob Martin (par exemple OO design). Il y a grand valeur dans l'écriture de code propre. Il est beaucoup plus facile à maintenir.
Ensuite, je laisse ReSharper en faire un "joli code" pour moi (par exemple, l'alignement, les sauts de ligne, etc.). Il y a bon valeur dans l'écriture de joli code. Mais il y a des rendements décroissants. Une certaine amélioration le rend un peu plus facile à entretenir en raison de la facilité de lecture.
Si vous estimez qu'il est nécessaire d'aligner soigneusement d'énormes blocs de code pour le rendre lisible, alors le problème est votre énorme bloc de code! C'est trop grand. Je vois de nombreux exemples de personnes qui se donnent beaucoup de mal pour embellir un code très mal conçu.
Si je n'avais pas ReSharper, j'aurais toujours du code propre, mais ce ne serait pas aussi joli.
Je ne pense pas que je devrais consacrer plus de ~ 5% de mon temps de codage à la mise au point. Ce qui signifie que plus mon éditeur est puissant et plus je suis compétent avec lui, plus je peux faire de raffinements.
Il semble que personne ne soulève la question de ce qui est dans le meilleur intérêt de votre entreprise?
Souvent, sinon toujours, les programmeurs ne sont que des employés, et bien que les décisions de gestion puissent nous frustrer, nous n'avons souvent pas toutes les données dont ils disposent.
Par exemple, disons que la société est contractée avec une clause selon laquelle si le logiciel n'est pas prêt à temps, vous ne serez pas payé (cela nous est juste arrivé, même si je pense que nous avons reçu le paiement après tout). Oui, un code propre est important, mais le plus important est de le faire fonctionner le jour du paiement!
Autre exemple: l'entreprise est en mauvaise situation financière et doit lever des fonds. Devinez qui se soucie de la qualité? Vous pouvez le réparer plus tard, si vous le devez, expédiez-le!
Un argument pourrait être "Pourquoi devrais-je vendre et écrire du code merdique?". Eh bien, pourquoi votre entreprise devrait-elle vous payer un chèque de Nice chaque mois? Des choix, mon ami. Si vous recherchez l'idéalisme, essayez la Free Software Foundation ; J'ai entendu dire qu'ils faisaient des trucs plutôt sympas (je veux dire celui-ci, et je respecte la FSF et l'OSS).
D'un autre côté, si vous travaillez sur un projet où une croissance explosive de l'utilisation est attendue (bien que de telles projections ne soient presque jamais précises), vous feriez mieux de jeter des bases solides avec la meilleure qualité de code requise, car il est presque certain que la maintenance sera être le plus grand coût pour le projet.
Les programmeurs adorent le code "propre", quoi que cela signifie. Nous ne pouvons même pas nous mettre d'accord sur ce qui est propre, mais nous l'adorons. Cependant, parfois, cela n'a pas autant d'importance que la convivialité et l'exactitude. Ceux-ci peuvent sembler synonymes, mais ils ne le sont pas - si vous avez vu du code écrit par un vrai pirate Perl en 4 heures avec l'intention d'être utilisé deux fois et jeté, vous reconnaissez qu'il n'est pas propre, mais cela fonctionne.
Parfois, mis à part l'ego, nous devons simplement le faire fonctionner. Notez que je ne recommande pas d'écrire du mauvais code par habitude; Je souligne simplement que cela pourrait être nécessaire. La perfection prend du temps que votre entreprise pourrait ne pas avoir. Donc, si votre employeur ne vous dérange pas, créez des logiciels, mais si vous en avez besoin, écrivez simplement du code de travail, tant pis pour la "propreté". Ce n'est tout simplement pas une réponse 'taille unique' - vous devez prioriser.
Trop de quoi que ce soit n'est jamais bon.
Cependant, une chose importante à garder à l'esprit avec le code "impur" est qu'il peut facilement conduire à " fenêtres cassées ". Si le code est très mal formaté, je pense que de nombreuses personnes nouvelles dans la base de code pourraient se sentir moins enclines à faire du bon travail avec la maintenance et l'évolution, provoquant une spirale descendante qui pourrait éventuellement affecter l'état de fonctionnement du logiciel.
Par conséquent, le maintien d'un certain niveau de propreté dans le code est bénéfique pour plus que vos collègues développeurs. Ne passez pas trop de temps dessus (~ 5% a été mentionné). Apprenez à utiliser les outils de votre métier pour automatiser les tâches manuelles (formatage du code dans ce cas). Prenez la responsabilité de ce que vous faites et faites toujours ce que vous jugez le plus avantageux pour votre entreprise/clients/utilisateurs.
Voici une citation de Clean Code, par Bob Martin:
Pour ramener ce point à la maison, que se passerait-il si vous étiez médecin et que vous aviez un patient qui exigeait que vous arrêtiez tout le stupide lavage des mains en préparation à la chirurgie parce que cela prenait trop de temps? De toute évidence, le patient est le patron; et pourtant le médecin doit absolument refuser de se conformer. Pourquoi? Parce que le médecin en sait plus que le patient sur les risques de maladie et d'infection. Il ne serait pas professionnel (même criminel) que le médecin se conforme au patient.
De même, il n'est pas professionnel pour les programmeurs de se plier à la volonté des gestionnaires qui ne comprennent pas les risques de faire des dégâts.
Je ne suis pas sûr que "bien paraître" et être "élégant, parfaitement compréhensible et maintenable" soit équivalent.
J'essaie d'écrire du code, c'est "élégant, parfaitement compréhensible et maintenable". Je refactorise mon propre code pour mieux correspondre à ces critères.
Je ne vois aucun inconvénient, sauf le coût résultant en temps.
Pour que le code "paraisse bien", il existe de nombreux outils automatisés, qui vont correctement mettre en retrait et espacer tout comme vous le souhaitez.
J'aime que le code soit lisible, mais le plus important est la cohérence. Pour moi, cela signifie la cohérence avec les conventions de dénomination et espacement entre les fonctions, parenthèses sur la même ligne ou la ligne suivante de l'instruction if, etc.
Bien sûr, il y a des moments où quelqu'un programme quelque chose avec un style de code cohérent et cela me rend toujours fou. Surtout un code qui ne "souffle" pas. Par exemple:
void function1(){
//whatever code
}
int fooBar(){
//whatever else
}
Foo* someOtherFooBar(int value){
if(value){
//do something
}
return ...;
}
Eh bien ... Cela semble pire avec les méthodes Objective-C, et avec beaucoup, beaucoup d'instructions if imbriquées et des lignes beaucoup plus longues que 80 caractères. Mais ça m'ennuie encore :)
Je pense que le "code propre" devrait être aussi propre ou plus propre que la façon dont vous écriviez lors de vos examens de physique/ingénierie/mathématiques. S'il est trop salissant, le correcteur ne comprendra pas votre travail et le marquera probablement mal même s'il est juste.
Je fais beaucoup d'efforts pour nettoyer le code. Je pense que cela aide grandement les bogues à se démarquer.
Je ne suis pas d'accord avec le concept "expédier la putain de chose maintenant", car le code propre est un investissement pour l'avenir. Trop de logiciels sont également livrés avec trop de bogues. À mon avis, résoudre un bogue est préférable à l'implémentation d'une nouvelle fonctionnalité.
De plus, si vous regardez estimations de la productivité du programmeur , je ne pense pas que je marque très mal. Écrire du code propre est une habitude, et plus il y a d'expérience en tant que programmeur, plus il devient efficace. Si on ne l'essaye jamais, évidemment, on n'en aura jamais l'expérience.
Un autre point à prendre en compte est que la plupart du temps du développeur est consacré à la lecture de code, donc le code lisible réduit considérablement le temps passé à lire. Par exemple, comprendre des algorithmes non documentés peut être coûteux et inviter de nouveaux bugs.
Une chose qui me manque vraiment et que j'aimerais avoir un jour est un formateur de code automatique que je pourrais adapter à mon style, qui me ferait vraiment gagner du temps, surtout lors de la lecture du code des autres.
Le codage propre a un lien avec le perfectionnisme, qui a un risque de ne jamais se matérialiser, mais je pense que c'est principalement un problème au début, parce que vous investissez dans plus tard et lorsque vous réutilisez vos propres morceaux de code élégants, combinés à votre expérience , en vieillissant, vous serez très productif et beaucoup moins hanté par les bugs que les codeurs en désordre.
Ceci est un morcea de code démontrant mon style de codage.
Évitez simplement le "code de vanité". Il y a beaucoup de développeurs qui font les choses uniquement par vanité (ou à cause d'un TOC) et rien d'autre. Ma culotte se tord vraiment avec ces gens.
J'écris du code qui tente de résoudre le problème donné de la manière la plus efficace et théoriquement "élégante". En ce sens seulement, c'est propre. S'il se trouve que c'est "joli" quand j'ai fini, tant pis.
Ce que j'ai trouvé dans mes expériences limitées, c'est que lorsque les gens se plaignent de "code propre", la laideur est généralement le résultat d'une solution terrible plutôt que d'une convention de codage.
Je dirais que je fais un effort pour écrire du code plus propre, mais cela peut changer en raison de contraintes de temps ou si je travaille sur quelque chose de difficile. Cela a tendance à devenir désordonné lorsque l'on se concentre sur son fonctionnement. Ensuite, je reviendrai et nettoierai en l'examinant. Si vous revenez au code et devez passer trop de temps à rafraîchir votre mémoire, vous ne l'avez pas suffisamment commenté.
Le code propre est bon mais comme tout le reste, il doit juste être suffisamment propre. L'indentation de 5 lignes de code 4 espaces et d'une ligne 5 espaces n'augmente pas la difficulté de lecture.
Je pense que cela dépend de ce que vous faites. Si j'écris une application de preuve de concept, je suis en train de coder mon cul de cowboy et de ne pas regarder en arrière. Si je travaille sur une application sur laquelle je vais travailler pendant un certain temps, je m'assure de la coder suffisamment bien et de la rendre compréhensible dans un mois.
Je pense que styliser votre code est un peu douteux. Comme certains l'ont dit ci-dessus, votre travail consiste à créer un produit, pas un code formaté, mais je dirais au moins que l'on devrait s'en tenir à un style défini de commentaires et de codage. Je détesterais voir la moitié des variables chameau enfermé et l'autre moitié hongroise.
Mais aussi, cela dépend de ce que vous entendez par "code propre".
Refactoriser votre code pour le rendre élégant le rend plus facile à lire et à entretenir. Même des choses mineures telles que l'alignement de vos affectations de variables:
int foo = 1;
int bar = 2;
int foobar = 3;
est plus facile à lire que
int foo = 1;
int bar = 2;
int foobar = 3;
ce qui signifie qu'il est plus facile de survoler lorsque vous déboguez plus tard.
De plus, en PHP vous êtes autorisé à utiliser n'importe quel nombre de blocs de code aléatoires. Je les utilise pour regrouper les tâches logiques:
// do x
{
// ...
}
// do y
{
// ...
}
Cela ajoute une définition claire au code pertinent.
Edit: En prime, il est facile de précéder l'un de ces blocs de code logique avec une if (false) si vous voulez le sauter temporairement.
J'avoue avoir fait ça; et l'avantage ne s'énerve pas chaque fois que je le vois. Je suppose que c'est aussi plus facile à lire, et donc les bugs deviennent plus évidents; mais la vraie raison est que je ne supporte pas le code laid.