Est-ce que vous écrivez réellement «code propre»? [fermé]

J'ai vu des programmeurs peaufiner leur code encore et encore, non seulement pour que tout fonctionne bien, mais aussi pour que tout soit beau.

OMI, «code propre» est en réalité un compliment indiquant que votre code est élégant, parfaitement compréhensible et facile à gérer. Et la différence ressort 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’écrivons pas de code propre . Et généralement, ce n'est pas notre travail . En tant que développeurs de logiciels, notre travail consiste à 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 de Coders at Work :

À la fin de la journée, expédiez la chose f ***** g! Il est bon de réécrire votre code et de le rendre plus propre et à la troisième fois, il sera vraiment joli. Mais ce n'est pas la question - vous n'êtes pas ici pour écrire du code; vous êtes ici pour expédier des produits. - Jamie Zawinsky

Je pense également à la réponse du blog de Robert Martin :

Alors. Soyez intelligent. Sois propre. Soit simple. Navire! Et gardez un petit rouleau de ruban adhésif à la main, et n’ayez pas peur de l’utiliser. - Oncle Bob

Si le code écrit par le développeur est propre ET fonctionne (est livrable), qu’il en soit ainsi, il convient à tout le monde. Mais si un développeur essaie de créer un code propre et lisible au détriment de pouvoir le livrer rapidement, c'est mauvais. Faites-le fonctionner, utilisez du ruban adhésif et expédiez-le. Vous pouvez le refacturer plus tard et le rendre super beau et efficace.

Oui, c'est une bonne pratique d'écrire du code en clair, mais jamais au détriment de pouvoir livrer. L'avantage de livrer un produit à gaine collée à temps dépasse de loin les avantages d'un code propre qui n'a jamais été fini et livré.

Une bonne partie du code que j'ai rencontré n'est pas propre. Certains sont carrément laids. Mais ils ont tous été libérés et utilisés dans la production. Certains diront peut-être qu’il n’est pas professionnel d’écrire du code compliqué. Je ne suis pas d'accord. La chose professionnelle est de fournir un code qui fonctionne, qu'il soit propre ou en désordre. Le développeur doit faire de son mieux, compte tenu du temps alloué avant la livraison. Ensuite, retournez pour nettoyer - c'est professionnel. Espérons que le code fourni ne soit pas du ruban adhésif pur et qu'il est «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 over styling(comme ce terme mieux que ce code de fille ) qui ne sert que l'ego de son auteur.

Dans le passé, j'ai vu de nombreux développeurs 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 un 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 vous avez généralement également la responsabilité d’expédier quelque chose qui soit maintenable de la manière la plus rentable possible, par vous-même et par les futurs développeurs.

J'ai passé des périodes sur ce site en tant que programmeur ou consultant chargé de la maintenance qui doit comprendre et déboguer un énorme système non documenté, et je peux vous affirmer que des conceptions médiocres et des codes compliqués peuvent engendrer des efforts gaspillés. Je peux penser à de nombreuses situations dans lesquelles un effort supplémentaire de N heures par le développeur initial aurait pu entraîner une économie de 5N en termes de temps.

Je sais qu'il existe une statistique à ce sujet, mais d'après mon expérience dans plusieurs projets, chaque ligne de code écrite est lue 5 à 20 fois au cours de l'extension et de la maintenance.

Je dirais donc de nettoyer le code à un pouce de sa vie . Cela prend du temps, mais cela représente probablement une économie de coût net sur la durée du projet.

Certains d'entre nous achèteraient-ils une voiture si nous savions que sous le capot, ils sont difficiles à résoudre, à entretenir ou à réparer, et qu'il leur faut plus de ressources que prévu pour le faire tourner?

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épondant à la question "écrivez-vous réellement du" code propre "?" -- Oh oui.!

Si vous voulez dire par «code propre», est-ce que je fais tout ce qui est en mon pouvoir 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, ce qui vous fait gagner du temps à long terme. Ne regardez pas le code propre comme une vanité; considérez-le comme un investissement permettant d’économiser du temps et des efforts futurs.

Honnêtement ça dépend. J'aime la façon dont tout le monde jure que "tout code qui n'est pas propre et bien documenté est une pure parodie!", Mais je travaille dans une entreprise avec des cycles de déploiement ridicules et une absence totale de surveillance: je fais de mon mieux, mais j'écris pour beaucoup de code, il est extrêmement difficile d’écrire le code parfait que tout le monde prétend écrire.

J'essaie d'écrire du code pouvant être facilement mis à jour par quelqu'un qui a à peu près mes capacités. Je commente les parties difficiles, je nomme les programmes, les variables et les noms conviviaux des classes, je les déploie et je passe à autre chose. 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 que je traite 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 fichiers binaires nommés de manière cryptique partout. La femme que j'ai remplacée a programmé exclusivement en RPG .

Il est extrêmement difficile pour moi de croire, pour ne pas dire une merde aussi horrible que celle de mes années de 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 un code propre = code maintenable. Rien de moins est non professionnel.

En règle générale, je considère le prochain développeur qui doit regarder mon désordre.

Souvent, c’est moi… plusieurs mois plus tard… quand je ne me souviens pas comment cela fonctionne… et j’ai encore moins de temps pour faire un changement.

J'essaie d'écrire "code propre" dans le sens de Bob Martin (par exemple, conception OO). Il est très utile d’écrire du code propre. C'est beaucoup plus maintenable.

Ensuite, j'ai laissé ReSharper me fabriquer un "joli code" (par exemple, alignement, sauts de ligne, etc.). Il est très utile d'écrire du joli code. Mais il y a des rendements décroissants. Certaines prétentions le rendent un peu plus facile à maintenir en raison de la facilité de lecture.

Si vous pensez qu'il est nécessaire d'aligner d'énormes blocs de code pour le rendre lisible, le problème est votre énorme bloc de code! C'est trop grand. Je vois de nombreux exemples de personnes qui s'efforcent d'assainir 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 confection. Ce qui signifie que plus mon éditeur est puissant et plus je suis compétent, plus je peux faire de la jalousie.

Il semble que personne ne soulève la question de savoir ce qui est dans l'intérêt de votre entreprise?

Souvent, sinon toujours, les programmeurs ne sont que des employés et, même si les décisions de gestion peuvent nous frustrer, nous ne disposons souvent pas de toutes les données dont ils disposent.

Par exemple, supposons que la société contracte une clause stipulant que si le logiciel n'est pas prêt à temps, vous ne serez pas payé (c'est ce qui nous est arrivé, bien que je pense que nous avons reçu le paiement après tout). Oui, le code propre est important, mais le plus important est de le faire fonctionner avant le jour du paiement!

Autre exemple: la société est dans une mauvaise situation financière et doit collecter des fonds. Devinez qui se soucie de la qualité? Vous pouvez le réparer plus tard, si vous devez le faire, envoyez-le!

Un argument pourrait être "Pourquoi devrais-je vendre et écrire du code de merde?". Pourquoi votre entreprise devrait-elle vous payer un chèque chaque mois? Des choix, mon ami. Si vous recherchez l'idéalisme, essayez la Free Software Foundation ; J'entends dire qu'ils font des trucs plutôt sympas (je parle de celui-ci et je respecte la FSF et l'OSS).

D'autre part, si vous travaillez sur un projet dans lequel 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 la maintenance est presque certaine être le plus gros coût pour le projet.

Les programmeurs aiment le code "propre", peu importe ce que cela signifie. Nous ne pouvons même pas nous mettre d'accord sur ce qui est propre, mais nous l'aimons. Cependant, parfois, cela n'a pas tellement d'importance que la facilité d'utilisation et l'exactitude. Celles-ci peuvent sembler synonymes, mais elles ne le sont pas - si vous avez vu le code écrit par un véritable pirate informatique Perl en 4 heures avec l'intention d'être utilisé deux fois et jeté, vous reconnaissez que ce n'est pas propre, mais cela fonctionne.

Alors parfois, côté ego, nous devrions simplement le faire fonctionner. Notez que je ne recommande pas l'écriture de mauvais code comme habitude; Je signale simplement que cela pourrait être nécessaire. La perfection prend du temps, votre entreprise pourrait ne pas avoir. Donc, si votre employeur ne vous dérange pas, créez un logiciel, mais si vous en avez besoin, écrivez simplement un code qui fonctionne, sans parler de la «propreté». Ce n'est tout simplement pas une réponse «taille unique» - vous devez définir des priorités.

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 "élégant, parfaitement compréhensible et maintenable". Je refacture mon propre code pour mieux répondre à ces critères.

Je ne vois aucun inconvénient, sauf le coût qui en résulte dans le temps.

Pour que le code soit "beau", il existe de nombreux outils automatisés, qui vont correctement indenter et tout espacer à votre guise.

Trop de tout n'est jamais bon.

Cependant, il est important de garder à l’esprit que le code "malpropre" peut facilement conduire à des " fenêtres brisées ". Si le code est très mal formaté, je pense que de nombreuses personnes débutant dans la base de code se sentiraient peut-être moins enclines à faire un bon travail de maintenance et d'évolution, ce qui provoquerait une spirale descendante pouvant éventuellement affecter les conditions de fonctionnement du logiciel.

Par conséquent, maintenir un certain niveau de propreté dans le code est avantageux pour plus que vos collègues développeurs. Ne passez pas trop de temps dessus (environ 5% ont été mentionnés). Apprenez à utiliser les outils de votre métier pour automatiser des tâches manuelles (formatage du code dans ce cas). Assumez la responsabilité de ce que vous faites et faites toujours ce que vous estimez être le plus bénéfique pour votre entreprise / vos clients / utilisateurs.

Voici une citation de Clean Code, de Bob Martin:

Pour ramener ce point à la maison, que se passerait-il si vous étiez médecin et avez un patient qui vous a demandé d'arrêter de vous laver les mains de façon idiote en vue de l'opération parce que cela prenait trop de temps? Il est clair que le patient est le patron. et pourtant, le médecin doit absolument refuser de se conformer. Pourquoi? Parce que le médecin sait plus que le patient sur les risques de maladie et d’infection. Il serait peu professionnel (sans parler du criminel) que le médecin se conforme au patient.

De même, il est peu professionnel pour les programmeurs de se plier à la volonté des gestionnaires qui ne comprennent pas les risques de faire des dégâts.

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. Si c'est trop compliqué, le correcteur ne comprendra pas votre travail et le marquera probablement mal même s'il est correct.

J'aime que le code soit lisible, mais le plus important est la cohérence. Pour moi, cela signifie cohérence avec les conventions de dénomination et l' espacement entre les fonctions, parenthèses sur la même ligne ou la ligne suivante de l'instruction if, etc.

Bien sûr, il arrive parfois que quelqu'un programme quelque chose avec un style de code cohérent et que cela me rend toujours fou. Surtout du 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, avec beaucoup d’instructions if imbriquées et des lignes beaucoup plus longues que 80 caractères. Mais ça m'agace toujours :)

Je me donne beaucoup de mal à nettoyer le code. Je pense que cela aide grandement les insectes à se démarquer.

Je ne suis pas d'accord avec le concept "expédiez ce putain de truc maintenant", car un code propre est un investissement pour l'avenir. Aussi, trop de logiciels sont livrés avec trop de bogues. À mon avis, la résolution d'un bogue est préférable à la mise en œuvre d'une nouvelle fonctionnalité.

Aussi, si vous regardez les estimations de la productivité des programmeurs , je ne pense pas que je marque très mal. Écrire du code propre est une habitude, et plus un programmeur a de l'expérience, plus il devient efficace. Si on ne l'essaie jamais, évidemment, on n'en aura jamais l'expérience.

Un autre point à prendre en compte est que la majeure partie du temps des développeurs est consacrée à la lecture de code. Par conséquent, un code lisible réduit considérablement le temps passé à la lecture. Comprendre des algorithmes non documentés, par exemple, peut être coûteux et inviter de nouveaux bogues.

Une chose qui me manque vraiment et que j'aimerais avoir un jour, c'est un formateur de code automatique que je pourrais adapter à mon style, ce qui me permettrait vraiment de gagner du temps, en particulier lorsque je lisais le code d'autres personnes.

Le codage propre a un lien avec le perfectionnisme, qui risque de ne jamais se concrétiser, mais je pense que c'est surtout un problème lorsque vous débutez, car vous investissez plus tard et lorsque vous réutilisez vos propres codes élégants, combinés à votre expérience. En vieillissant, vous serez très productif et beaucoup moins hanté par les bogues que les codeurs malpropres.

Ceci est un morceau de code démontrant mon style de codage.

Évitez juste le "code de vanité". Il y a beaucoup de développeurs qui font des choses purement par vanité (ou à cause d'un TOC) et rien d'autre. Ma culotte est vraiment tordue avec ces gens.

J'écris du code qui tente de résoudre le problème donné de la manière la plus efficace et la plus élégante sur le plan théorique. Dans ce sens seulement c'est propre. S'il s'avère que c'est «joli» quand j'ai terminé, qu'il en soit ainsi.

Ce que j’ai constaté au cours de 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 vous vous concentrez sur le travail. Ensuite, je vais revenir en arrière et nettoyer pendant que je l'examine. Si vous revenez au code et que vous devez passer trop de temps à rafraîchir votre mémoire, vous ne le commentez pas assez.

Le code propre est bon, mais comme tout le reste, il doit être suffisamment propre. Indenter 5 lignes de code 4 espaces et 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 validation de principe, je suis fondamentalement en train de décoder mon cul 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 bien la coder et de la rendre compréhensible dans un mois.

Je pense que le style de votre code est un peu hasardeux. Comme certains l’ont dit plus haut, votre travail consiste à créer un produit, et non un code formaté, mais je dirais qu’au moins nous devrions nous en tenir à un style défini de commentaire et de codage. Je détesterais voir la moitié des variables chameau et l’autre moitié hongroise.

Mais cela dépend aussi de ce que vous entendez par «code propre».

J'avoue l'avoir fait; et l'avantage ne s'énerve pas à chaque fois que je le vois. Je suppose que c'est aussi plus facile à lire, et donc que les bugs deviennent plus évidents; mais la vraie raison est que je ne supporte pas le code laid.

Refactoriser votre code pour le rendre élégant facilite la lecture et la maintenance. 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.

En outre, en PHP, vous êtes autorisé à utiliser un nombre illimité de blocs de code aléatoires. Je les utilise pour regrouper des tâches logiques:

// do x
{
    // ...
}

// do y
{
    // ...
}

Cela ajoute une définition claire au code pertinent.

Éditer : En prime, il est facile de faire précéder l’un de ces blocs de code logique par un if (false)si vous voulez le sauter temporairement.

Je viens d'écrire mon code, en suivant les normes de l'entreprise. Si je le veux "joliment", je peux le faire passer par un embellisseur de code.