L'obsession de rendre le code «joli» présente-t-elle un avantage?

Parfois, je passe des heures ridicules à agoniser à rendre le code "joli". Je veux dire rendre les choses symétriques. En fait, je vais rapidement faire défiler toute une classe pour voir si quelque chose sort de ce qui ne semble pas "joli" ou "propre".

Est-ce que je perds mon temps? Y at-il une valeur dans ce genre de comportement? Parfois, les fonctionnalités ou la conception du code ne changent même pas, je vais simplement le restructurer pour qu'il soit plus joli.

Suis-je en train de subir un TOC total ou existe-t-il un avantage caché dans tout cela?

Utilisez un formateur automatique. Si vous passez vraiment beaucoup de temps à éditer manuellement le code, je serais prêt à deviner que vous n'êtes pas très défié / ennuyé, car il n'y a absolument aucune raison de le faire. Ctrl + K, Ctrl + D sous VS formateront un document entier. Vous pouvez utiliser quelque chose comme Style Cop si vous voulez quelque chose d'un peu plus lourd.

Il est bon d'avoir la fierté de votre code, mais pas quand il se fait au détriment d' être intelligent (recherche de la solution la plus efficace. Dans ce cas, l' aide d' un outil pour automatiser un processus fastidieux) et faire avancer les choses (quoi d' autre pourrait vous avez travaillé pendant ces heures?).

Si vous ne changez rien qui permette de mieux le comprendre, alors vous perdez votre temps.

Rien de caché, un joli code est facile à lire et à maintenir.

"Heures" semble un peu excessif, sauf si vous avez une base de code énorme. Tout ne doit pas être parfait, il doit simplement être bon

C'est une question de jugement. si vous passez des heures, je dirais que vous en faites trop. Cependant, un utilisateur peut faire certaines choses qu'un outil de mise en forme automatique ne peut pas, et vous pouvez faire pour rendre votre code plus lisible, ce qui est difficile à saisir dans les normes de codage d'entreprise.

Par exemple, lors de la déclaration de variables dans une classe, j'aime bien avoir des regroupements logiques - cela facilite le suivi de la logique.

Le code est généralement considéré comme "écrivez une fois, lisez plusieurs", ce qui rend bien une expérience de lecture agréable est une bonne habitude - mais la mise en page est, à mon avis, beaucoup moins problématique que des conventions de dénomination claires, des abstractions claires et des signatures de méthodes bien structurées.

J'ai vu du code magnifiquement formaté qui a provoqué de graves moments de WTF parce que le processus de pensée sous-jacent était imparfait. Si vous avez des heures à passer, je le consacrerais à la conception et à la refactorisation, plutôt qu'à la mise en page ....

Non, vous n'êtes pas totalement atteint de TOC. Le plus grand compliment que j'ai jamais entendu en tant que programmeur était: "Votre code est si propre que mon petit frère pourrait le comprendre."

Un jour, quelqu'un devra supporter votre code. Le code propre est beaucoup plus facile à supporter. Et un jour, ce sera peut-être toi. Dans 6 mois ou un an, vous ne vous souviendrez pas de ce que vous avez fait. Mais s'il est propre et facile à lire, il reviendra rapidement.

Cela dit, si le code est un déchet, il ne sert à rien d’être beau. Mais s'il est bien structuré et ne pose que des problèmes de fonctionnalité, il sera beaucoup plus facile d'améliorer la fonctionnalité.

Non - être obsédé par l'idée de rendre le code joli, c'est passer à côté de l'essentiel .

Voici quelques morceaux de sagesse que j'ai trouvés utiles:

Demandez pourquoi le code doit être bien rangé.

Vous perdez peut-être votre temps en fonction de votre définition de jolie.

Le théorème fondamental du formatage dit qu'une bonne présentation visuelle montre la structure logique du programme. Rendre le code plus joli vaut quelque chose, mais ça vaut moins que de montrer la structure du code. [Page 732, Code Complete 2nd Edition, Steve McConnell]

Si vous utilisez le système de versions simultanées pour suivre les modifications dans le code, ne mélangez pas les modifications de mise en forme du code avec des modifications logiques / d'ajout de fonctionnalités dans la même validation.

Cela rendra les changements plus difficiles à repérer et causera des conflits de fusion inutiles si d'autres membres de l'équipe modifient le fichier. Si vous devez apporter des modifications de mise en forme, vérifiez que les autres membres de l'équipe ne travaillent pas sur ce fichier. [Paraphrasé, page 93, Contrôle de version pragmatique avec Subversion, 2e édition]

Martin Fowler a également parlé de «porter deux chapeaux» et de passer d'un chapeau à l'autre toute la journée. Un chapeau pour ajouter des fonctionnalités, un chapeau pour la refactorisation.

1. Vous envisagez d'ajouter une nouvelle fonctionnalité (Feature Hat)
2. Vous parcourez le code existant pour mieux comprendre et ranger au fur et à mesure. (Chapeau de refactoring)
3. Commettez les modifications.
4. Ajouter la fonctionnalité. (Chapeau caractéristique) et ainsi de suite ....

[Paraphrasé p. 57ish, Refactoring, Martin Fowler]

Alors, ne passez pas des heures à essayer d’embellir toute la base de code. Précisez juste assez de code pour pouvoir ajouter la fonctionnalité suivante.

En bref, laissez chaque élément de code dans un état plus agréable que lors de votre arrivée.

S'il s'agit simplement de formatage, vous feriez probablement mieux d'investir un peu de temps pour enseigner à une jolie imprimante comment vous voulez que votre code soit formaté. Cela coûte un peu cher au départ, mais j'imagine que vous récupérerez cette minuterie en 2-3 utilisations.

Si c'est le refactoring réel, peut-être pas. Le code conceptuellement propre a tendance à être plus facile à modifier à l'avenir et avoir «toujours propre» diminue la tentation de laisser passer quelque chose simplement parce qu'il y a un autre code malodorant.

Ça aide un peu, mais ça ne vaut pas la peine de passer beaucoup de temps dessus. Assurez-vous également que vos améliorations ajoutent également une portée variable, RAII, un code copié / collé de groupe, etc. Si vous faites tout cela, cela devient 1000 fois plus facile lorsque vous devez comprendre ce que le code fait après environ un an.

Vous devriez produire du code propre, mais cela ne devrait pas prendre des heures.

Pour C, il y a le programme gnu gnu-indent gnu-indent , dans eclipse, il existe au moins un formateur de code pour Java, et je suppose qu'il existe également des outils pour la plupart des autres langages. Quelques clics suffisent pour indenter un fichier correctement, et quelques minutes si vous souhaitez enfreindre les règles à des fins spécifiques - comme je le fais pour de courtes instructions case-switch:

 switch (foo) {
      case a:  foo (a);             break; 
      case b:  foob ();             break;
      case c:  /* intent. empty */
      case d:  foocd ();            break; 
      default: allPrettyAligned (); break; 
 }

ce qui est difficile à spécifier.

Si vous pensez que quelque chose a l'air propre en l'écrémant, vous vous concentrez sur quelque chose de superficiel qui peut être automatisé.

Lisez cet article classique sur «Faire en sorte que le mauvais code ait l'air mauvais» et vous verrez exactement pourquoi les gens pensent généralement que l'indentation (qui peut être faite automatiquement) est triviale:

http://www.joelonsoftware.com/articles/Wrong.html

En particulier cette liste:

D'accord, jusqu'à présent, j'ai mentionné trois niveaux de réussite en tant que programmeur:

1 . Vous ne savez pas impur.

2 Vous avez une idée superficielle de la propreté, principalement au niveau de la conformité aux conventions de codage.

3 Vous commencez à sentir des traces subtiles de malpropreté sous la surface et ils vous dérangent suffisamment pour tendre la main et corriger le code.

Il y a cependant un niveau encore plus élevé, et c'est ce dont je veux vraiment parler:

4 Vous avez délibérément conçu votre code de manière à ce que votre nez contre la malpropreté rende votre code plus vraisemblable.

C'est le véritable art: créer du code robuste en inventant littéralement des conventions qui font que les erreurs ressortent à l'écran.

"Heures"? Eh bien, je dirais que votre réponse est "et", pas "ou": ouais, vous êtes un TOC, mais il y a un avantage à cela.

Probablement.

Cela rend-il votre code plus facile à lire rapidement? Est-ce qu'il est plus facile de survoler, de déterminer ce qui s'arrête et de commencer où, de trouver des fonctions, des variables, etc.? Cela rend-il la façon dont votre code fonctionne plus clair? Le processus de préparation vous oblige-t-il à revoir certaines décisions de conception et à supprimer du code mort ou des solutions à moitié cuites que vous avez finalement abandonnées? Si c'est le cas, cela a une valeur absolue.

D'un autre côté, si vous avez trouvé une façon perverse de faire appel à votre propre sens de l'esthétique sans rendre le code plus facile à travailler, alors c'est une grosse perte de temps.

Quant à moi, j'ai tendance à tomber moi-même au-delà du TOC - mais je ne vais pas m'arrêter. Le fait de fournir de la documentation pour une classe ou une fonction m'oblige à réfléchir au fonctionnement réel de la chose. Je l'écris pour que quelqu'un qui n'est pas moi puisse la comprendre, après tout. Et si je me jette dans un tas de mises en garde, d'avertissements et d'excuses pour expliquer pourquoi le code fonctionne de la même manière, c'est un avertissement assez fort qui nécessite une nouvelle série de modifications avant que je ne déclare qu'il est terminé.

Tout d’abord, il n’ya rien de mal à rendre votre code joli, car vous voulez être fier de votre création et la présentation / mise en forme du code en fait partie.

Cependant, je ferais attention à ne pas sur-formater votre code pour le bénéfice de vos collègues ou des futurs développeurs. Jolie pour toi pourrait ne pas être jolie pour moi. :)

Vous reconnaissez le problème (comportement compulsif) et le symptôme (mise en forme obsessionnelle).

Qu'en est-il de la cause et du traitement?

• Travaillez-vous trop d'heures?
• Êtes-vous frustré, ennuyé, anxieux?
• Quelle est votre prochaine tâche? Est-ce quelque chose que vous ne voulez pas faire?
• Quand as-tu eu des vacances pour la dernière fois? Promotion? Reconnaissance pour un accomplissement?
• Est-ce un problème lié au burn out?
• Êtes-vous sur une marche de la mort?

Parfois, ces symptômes sont un signe qu'il est temps de faire des changements audacieux ou d'aller de l'avant.

En dépit de son titre déprimant, le livre de Yourdon contient de nombreuses suggestions utiles et, pour de nombreuses organisations, en fait une description assez réelle.

http://dev.co.ua/docs/Edward%20Yourdon%20-%20Death%20March.pdf

Vous semblez assez perspicace et je pense que vous connaissez peut-être la réponse.

Maintenant, donnez-vous la permission d'agir.

Bovin sacré!
Vous n'avez jamais entendu parler de retrait?

c'est un utilitaire de formatage de code qui existe depuis plus de 20 ans. Son méga-seau d'options permet à votre code d'être formaté comme vous le souhaitez, automatiquement.

ermm - mais cela ne fonctionne que sur le C et certains mais pas tous les C ++ .... (wtf? pourquoi GNU ne le met-il pas à jour?)