Ecriture du code maintenable [fermé]

écrivez - le pour que les autres le lisent. Cela signifie une combinaison de bons noms, de bons commentaires et des énoncés simples.

autrefois, la mémoire était rare et les cycles étaient lents. les programmeurs ont été encouragés à écrire des lignes simples complexes de code qui ont fait beaucoup de choses. Aujourd'hui la mémoire est abondante et les temps de cycle sont rapides. Vous devriez écrire 5 lignes de code simple que les gens peuvent suivre au lieu d'une ligne qu'ils ne peuvent pas comprendre.

bon les commentaires ne doivent pas être longs, mais ils doivent être utiles.

soit cohérent. Ne changez pas de style dans votre code. Par exemple, ne changez pas les styles de nommage d'une section à l'autre.

séparation des préoccupations (chaque méthode fait une chose) - cela arrête le code Spaghetti.

EDIT: (En réponse à sacha commentaire) La clé de la maintenabilité est d'être capable de comprendre rapidement ce que fait le code et comment faire des changements afin d'accomplir une tâche.

avoir le code séparé de sorte que chaque tâche soit traitée par une méthode qui lui est dédiée rend cela un claquement.

Par exemple, si je veux changer la comme un coude est plié sur un logiciel pour un robot, avoir une méthode appelée BendElbow en fait un no-brainer où le changement doit être fait.

tests unitaires Automatisés.

vous pouvez changer lentement la conception du code via le remaniement si vous l'avez couvert avec des tests automatisés qui vous dit quand il vous brise la fonctionnalité existante. Les tests automatisés rendent le changement de code moins risqué.

bonne abstraction

Bon amont de la conception. Rien ne peut sauver un mauvais design.

Unité de test haut la main. Si votre unité teste votre code à partir du go, alors vous aurez une suite de test que vous pouvez exécuter pour valider la validité de votre code à chaque fois que vous faites un changement.

aussi, quand vous écrivez un code avec un test unitaire, les méthodes ont tendance à être plus petites car elles sont plus faciles à tester. En outre, il devrait vous encourager à faire vos méthodes à une seule tâche - encore une fois, car il est plus facile de tester de cette façon.

étant sur le premier ou deuxième niveau de soutien pour le logiciel que vous venez d'écrire, pour un an ou deux après la publication.

croyez-moi, j'y suis allé moi-même. La" peur " que je puisse avoir de maintenir ou d'améliorer mon propre code dans les années est toujours une grande motivation pour améliorer la maintenabilité.

Bonne méthode "de noms d'151910920"

il y a une tendance à écrire du code pensant que l'ordinateur est votre public.

à proprement parler, c'est vrai puisque le code doit fonctionner. Mais si vous écrivez avec votre public humain à l'esprit, juste cet état d'esprit aide à produire du code plus lisible.

si vous êtes inquiet que cela va produire du code lent, gardez à l'esprit que la plupart des programmes presque tout leur temps dans de très petites portions de code. Commencer à écrire pour lisibilité, puis utiliser un profileur pour identifier les bonnes sections à optimiser.

ne pas faire de ce genre de choses! merci à Roedy Green pour les rires cependant.

il n'y a pas de" facteur unique le plus important", c'est une combinaison de plusieurs facteurs, comme indiqué ci-dessus.

maintenant, la plupart de ces règles peuvent être condensées en: "Écrivez votre code pour le lire plus tard".

Ou pour paraphraser un conseil drôle mais bon: "écrivez votre code comme si il doit être maintenu par un maniaque homicide savoir où vous vivez."...

lire le Code complet-il couvre tout à ce sujet à partir de la variable nommer jusqu'à la chose vraiment grande et il est tous nécessaire. Il n'y a pas une chose.

mon approche se résume actuellement à écrire du code pour faire le travail qui doit être fait ( pas pour chaque travail futur que le code peut avoir besoin potentiellement de faire ) en utilisant des noms de variables informatives et une portée variable minimale et en essayant de s'assurer que mon code a besoin aussi peu documentation supplémentaire si possible. Parfois, cela rend mes noms de variables et de méthodes un peu plus verbeux qu'ils ne l'étaient ( ma sortie de débogage est très compressive quand je l'utilise ) mais ils sont beaucoup plus faciles à comprendre.

maintenabilité est également généralement un résultat de la bonne pratique à d'autres égards - si vous écrivez votre code d'une manière sèche et agréable, alors les problèmes sont plus faciles à trouver, si vous avez un ensemble solide de tests, alors vous pouvez voir si la maintenance les changements vont tout casser.

en fin de compte, il s'agit d'essayer d'être réfléchi et d'écrire pour l'avenir - le code n'est écrit qu'une seule fois, après tout, c'est de la maintenance...

Je ne pense pas qu'il y ait un seul facteur sur lequel vous pouvez vous concentrer. S'il y en a une, je pense que ce serait un bon jugement. Même s'il est bien documenté, le code facile à lire peut être difficile à maintenir si un développeur a fait preuve d'un mauvais jugement pendant la phase de conception. Quelle que soit la qualité de la documentation et du test unitaire, une mauvaise conception d'une application de production peut être presque impossible à corriger.

vous pouvez aussi jeter un coup d'oeil à quelque chose comme le Guide du code irréalisable pour les idées de quoi ne pas faire. Instructif et amusant!

http://mindprod.com/jgloss/unmain.html

j'ai en fait travaillé dans des entreprises qui ont" normalisé " certaines des choses mentionnées. Vous penseriez que la plupart de ces trucs sont du bon sens, mais vous pourriez être surpris.

je dirais que le facteur le plus important est la sécheresse. glenatron le Mentionne déjà sur sa réponse parmi d'autres facteurs, mais je pense que c'est le plus important.

la programmation est une performance; vous ne devez jamais oublier qui est votre auditoire. "Code comme si la personne qui finit par maintenir votre code est un psychopathe violent qui sait où vous vivez."

• " consignez les hypothèses lorsque vous les formulez - deux jours plus tard, vous allez tenir ces hypothèses pour acquises, mais la personne qui maintient votre code ne fera pas nécessairement les mêmes hypothèses, et se demandera pourquoi vous avez fait ce que vous avez fait...

• Code les gens - l'ordinateur va faire tout ce que vous dites; code pour humains peut comprendre votre code - qui le sait ça pourrait être toi dans 6 mois!

Bons commentaires.

remaniement continu

consistance.

à mon avis, La règle fondamentale dans l'écriture du code maintenable est que votre code devrait être très facile à comprendre. Ce n'est pas aussi facile que ça en a l'air, et vous devrez utiliser toutes les autres techniques mentionnées ici pour le faire. Cela requiert un certain degré d'empathie parce que vous devrez apprendre comment les autres développeurs voient votre code, et comment il diffère de la façon dont vous le voyez. Un bon moyen de comprendre cela est de revenir en arrière et de regarder un code que vous avez écrit il y a quelques années.

maintenant, je suppose qu'il serait possible, en théorie, d'écrire du code qui est très facile à comprendre et qui exécute exactement la tâche à laquelle il est destiné mais qui est aussi difficile à modifier de quelque manière que ce soit. Je n'ai jamais vu de code comme ça.

beaucoup d'espace blanc. - Le code haute densité est difficile à comprendre. Si vous avez plus de 6 lignes sans aucune ligne blanche, alors ce groupe n'est probablement pas une pensée/idée/opération cohérente.

Bon les noms de variables explicites, mais concis. Énorme les noms de variables sont aussi mauvais que les minuscules.

sans aucun doute, code d'écriture conçu pour être lu par d'autres personnes. Cela inclut éviter le golf, la syntaxe de mystère, et des noms de variables réfléchies qui signifient quelque chose. Vous pouvez complètement éviter d'écrire des commentaires si le code est assez propre, IMO. \

[choisir une langue avec OO construit en opposition à cloué sur aide trop]

pour moi écriture code testable (checkout Google testing blog) est le meilleur code maintenable

J'ai déjà voté la réponse de Matt "bonne Abstraction" mais je voulais ajouter quelque chose.

documentant tout sur expliquant choses. Je suis tout à fait en faveur de Doxygen et d'autres outils de documentation automatique, mais des listes rudimentaires de fonctions dans une API sont tout simplement mieux que rien.

si vous voulez que votre code soit maintenable, décrivez votre solution au niveau approprié d'abstraction et affinez ce niveau jusqu'au niveau code pour qu'il soit évident ce qu'il fait.

petites fonctions et classes bien définies.

c'est assez facile de s'habituer aux différentes conventions de codage des autres, mais si tout est dans une classe ou une fonction géante, ma tête explose.

je préfère quand les gens taillent et façonnent le code comme il grandit. Trop souvent, vous trouverez une colonne originale d'architecture décente avec un énorme désordre cludgy accroché au dessus.

ça fait longtemps, mais j'ai une réponse à donner: n'exagère pas. cela peut sembler stupide, mais trop de commentaires expliquant des choses simples peuvent rendre le code confus que tous sortent. De bons commentaires peuvent faire des miracles, mais ceux qui ne servent à rien font tout le contraire.

de bons commentaires peuvent rendre même le pire code spaghetti 10x plus facile à maintenir.

Bons commentaires. Les bons commentaires aident à l'abstraction en indiquant le but visé par le code, les mauvais commentaires ne font que reformuler ce que le code fait. Les commentaires pourraient en fait prendre la forme de tests unitaires bien conçus et nommés.

ayant une bonne documentation. Cela comprend le code qui est auto-documenté (compartimenté, nommé de façon descriptive et clair), les bons commentaires, un document de conception détaillé qui est exact à la version finale (la plus récente) du code, et des notes descriptives de changement dans votre contrôle de source.

si vous en demandiez deux, le second serait certainement des tests unitaires. C'était un choix difficile à faire entre les deux.