Quel est le meilleur conseil quand on programme ?

[Charvin]

..."write less code"...

Je ne suis pas tout à fait d'accord avec ce conseil :
- une code "simple" n'est pas forcement le plus lisible.
- réutiliser trop de "choses" prises ailleurs, conduit à une perte de la maîtrise de son code.

Pour moi, le conseil n°1, ça reste quand même :

...d'abord rendre son code fonctionnel avant de vouloir l'améliorer !

J'ai l'habitude de dire à mes jeunes développeurs de :
1) écrire un code qui fait ce que l'on demande.
2) écrire un code maintenable, c'est à dire, avant tout, compréhensible par un autre développeur.
3) optimiser si nécessaire.

[DotCertis]

J'ajouterai un truc 'basique" que je n'ai pas vu dans les discussions ni dans l'article : écrire des commentaires. D'abord en début de programme en expliquant de façon succincte le but de programme (avec les inputs et les output) et à l'intérieur en disant ce que je vais faire dans les lignes de code qui suivent et comment.

Oui c'est basique mais le fait de mettre un commentaire avant d'écrire les lignes de codes qui font ce qui dans le commentaire permet de réfléchir à ce qu'on va faire et oblige à prendre un minimum de recul. Quand à celui du début ça rejoint l'idée de Bill Wagner, en s'obligeant à une réflexion fonctionnelle.

En plus en cas de problème, plutôt que d'avoir à tout de suite plonger dans le code, en relisant tous les commentaires qu'on a mis on retrouve beaucoup plus facilement l'enchainement qu'on a prévu ce qui permet d'identifier rapidement ce qu'on a pu rater ou une étape qu'on aurait oublié.

Et puis c'est bien plus simple pour le gentil codeur qui passera plus tard

[sevyc64]

DotCertis -> Les commentaires dans le code est un autre (vaste) débat, régulièrement alimenter ici même

La dernière discussion en date autour de ce thème --> http://www.developpez.net/forums/d12...entaires-code/

[Pergos]

Envoyé par el_slapper

+1, voire +1000

J'ai 12 ans de bouteille, mais, au final, j'ai toujours plein de limites, et plein de domaines dans lesquels je suis encore débutant. Notre domaine est tellement vaste que nous sommes tous débutants, presque partout. Il y a toujours plys de choses à apprendre que de choses que l'on sait.

Croire que l'on sait, c'est un des plus gros risques, je crois.

+1

Comme le dit le proverbe chinois :

Celui qui sait qu'il sait, écoute-le.
Celui qui sait qu'il ne sait pas, éduque-le.
Celui qui ne sait pas qu'il sait, éveille-le.
Celui qui ne sait pas qu'il ne sait pas, fuis-le.

[Voïvode]

À peine arrivé au milieu de la 2ème page du sujet, on peut déjà lire pas mal de bons conseils.

La lisibilité est un point important car la programmation est un domaine intellectuellement exigent. Bien programmer consiste avant tout à écrire du code avec soin pour éviter de se compliquer la vie.

Par exemple :

• Respecter une convention d'écriture officielle ou non, le but étant d'avoir un style cohérent. Notre cerveau aime avoir ses petites habitudes, un peu de discipline dans la mise en forme rend la lecture moins difficile pour soi-même et pour les autres. Cela commence par des choses aussi banales que l'indentation ou le bon usage des espaces dans une instruction.
• Bien choisir les noms de ses variables et de ses fonctions. Sans rentrer dans du camelCase vs under_score, un nom doit être en mesure d'évoquer encore quelques choses après un week-end arrosé quelques jours sans travailler sur le code.
• Documenter un minimum ne serait-ce que pour se repérer plus facilement. N'est-ce pas frustrant de se remettre à un ancien projet et de ne plus savoir à quoi sert cette foutue méthode ? Sans faire du Proust, une simple phrase descriptive peut nous épargner des épisodes décourageants.

À part ça, il y a aussi jeter un œil sur Developpez.com qui est pas mal.

Edit : J'adore ta citation Pergos.

[VivienD]

Bien que n'étant pas professionnel, j'utilise quelques principes pour programmer.

Premièrement, je comprends et définis clairement le problème à résoudre; et sur ce point je rejoins donc YannPeniguel.
Ensuite, je conçois sur papier mon programme, pour savoir ce que j'ai en entrée et en sortie et comment chaque partie de mon programme doit interagir entre eux et avec l'utilisateur.
Enfin je pisse mon code tout en restant concis et logique. Au passage, je laisse quelques commentaires pour indiquer les quelques parties qui peuvent être complétées par des fonctions supplémentaires ou pour «scinder» mes fonctions en sous-parties (au cas où je veuille retravailler mon code après une cuite dantesque).

Euh... sinon... ça veut dire quoi «factoriser un code» ?

[Gruik]

Coder moins et concevoir plus ?

[monsieurben]

Le conseil qui m'a le plus marqué quand j'étais débutant :

Tu ne codes pas pour toi, tu codes pour l'utilisateur final !

En codant de cette manière, on se rend compte qu'on atteint très vite 2 objectifs :

- Répondre au mieux aux besoins des utilisateurs (on répond mieux à un problème si on en comprend vraiment les enjeux ), ce qui signifie moins d'anomalies fonctionnelles de leur point de vue.

- Produire le code le plus "intelligent" possible : en comprenant le contexte du projet, on peut mieux cerner le problème et y répondre plus efficacement, notamment en termes de performances attendues, de quantité de code nécessaire et de maintenabilité de l'application.

Pour moi, c'est ça qui fait qu'un client retient votre logiciel, pas la qualité de son code ni l'optimisation au petits oignons de chacune de ses fonctions (attention, je ne dis pas que ça ne compte pas, ces 2 points sont ceux qui font que le client garde votre programme et pas celui d'un autre).

[6-MarViN]

Mon prof de C++ : un bon développeur est un développeur feignant.

En gros son conseil portait sur le fait de rendre son code le plus générique possible pour éventuellement pouvoir le réutiliser plus tard dans d'autre projets.

[fcharton]

Envoyé par tomlev

C'est plutôt le meilleur moyen de faire un code imbitable... Commence par faire un code qui marche, élimine les bugs, et seulement à ce moment là tu pourras te préoccuper de l'optimiser.

Premature optimization is the root of all evil
-- D. Knuth

Un code performant, ce n'est pas un code optimisé. A mon avis, il faut produire du premier coup un code raisonnablement efficace, parce que dans la vraie vie, on n'a jamais le temps de faire les optimisations... Et c'est comme ça qu'on se retrouve avec des programmes qui mobilisent des ressources obscenes, et qu'on n'ose plus faire évoluer de peur de mettre la machine à genoux, parce que le premier developpeur n'a pas voulu trier, faire des recherches dichotomiques, écrire ses boucles dans le bon ordre, ou se poser la question de la volumétrie... toutes choses qui ne relèvent pas de l'optimisation mais du métier de base (et qui sont disponibles dans toutes les librairies).

Les algorithmes de Knuth sont d'ailleurs typiques de cette approche. Ils ne sont jamais optimisés, mais toujours efficaces.



Le meilleur conseil qu'on m'ait donné, c'était "ne jamais hésiter à refaire".

Francois

[patate_violente]

Ne devient pas esclave de ton code.

[Guilp]

Envoyé par el_slapper

==>sur l'objectif réel du code : être beau, ou marcher?

Je n'aime pas beaucoup ce genre de question. Déjà parce "beau" a une connotation superficielle, et qu'il est mis en comparaison avec "marcher", comme un pragmatisme superficiel évident justifiant de faire n'importe quoi.

A mon humble avis, dans la majorité des cas, un code brouillon, pas réfléchi, mal pensé, fait perdre du temps et de l'argent à tout le monde (et n'est donc pas "fonctionnel". Et se cacher derrière l'argument de "ça marche", ça revient à, pour moi, entuber tout le monde).

(et je ne parle pas donc pas de passer son temps sur de l'esthétique, bien au contraire, et j'insiste. Je dis juste qu'un code "fonctionnel" est d'abord un code bien pensé. C'est pas toujours évident, mais c'est ça notre boulot...)

[Guilp]

Envoyé par monsieurben

Le conseil qui m'a le plus marqué quand j'étais débutant :

Tu ne codes pas pour toi, tu codes pour l'utilisateur final !

Entièrement d'accord. Et je rajouterais même "pour l'utilisateur final, et pour le gars qui va reprendre ton code". C'est un point distinct, mais tout aussi important à mes yeux.

Parce que :
- un code non maintenable est un code mort.
- En plus, penser à comment le prochain dev comprendra ton code, ça te fera faire un code mieux pensé, même pour toi-même.
- Et même si certains disent que c'est inutile car le client ne paiera pas plus à la livraison du code... Pour moi, premièrement c'est un argument ultra-bidon pour faire de la merde, et deuxièmement, dans tous les autres cas (boite d'édition, ou pour un client qui maintiendra ton code et qui ne te fera plus confiance plus tard s'il voit que tu leur a fait perdre du temps), cet argument ne s'applique plus.

(Donc au final, ça donnerait "ne codes pas pour toi, mais pour les autres" et je crois bien que c'est l'adage que l'on retrouve souvent partout, je pense)

[el_slapper]

Envoyé par Guilp

(.../...)(Donc au final, ça donnerait "ne codes pas pour toi, mais pour les autres" et je crois bien que c'est l'adage que l'on retrouve souvent partout, je pense)

Y compris quand "les autres", c'est "soi-même". Revenir sur un vieux code à soi-même est une expérience qui rend humble - tant qu'on est honnête avec soi-même.

Sinon, quand je parlais de code "beau", je faisais plus référence aux architectes astronautiques(et contrairement à l'auteur de ce texte, je ne crois pas que ça se limite au monde java). une architecture objet poussée, avec des héritages magnifiques, un graphe formidable, tout ça pour faire 3 additions, c'est beau, mais ça n'aide pas à résoudre le problème. Effectivement, un code "lisible" et "bien conçu", voire "bien dimensionné", c'est important aussi(mais par souci de concision, j'ai pu laisser entendre que j'avais un avis différent, désolé).

[Guilp]

Envoyé par el_slapper

Sinon, quand je parlais de code "beau", je faisais plus référence aux architectes astronautiques(et contrairement à l'auteur de ce texte, je ne crois pas que ça se limite au monde java). une architecture objet poussée, avec des héritages magnifiques, un graphe formidable, tout ça pour faire 3 additions, c'est beau, mais ça n'aide pas à résoudre le problème. Effectivement, un code "lisible" et "bien conçu", voire "bien dimensionné", c'est important aussi(mais par souci de concision, j'ai pu laisser entendre que j'avais un avis différent, désolé).

(Juste pour préciser que je suis entièrement d'accord . Je faisais plus un commentaire général en réagissant sur la tournure de phrase qui me titillait les yeux. J'hésitais à préciser, par précaution, que me doutait bien que dans le fond, ça n'est pas ce que tu voulais dire, mais je ne l'ai pas fait...)

EDIT:

Et en fait, quand j'y repense, les architectures "astronomiques" (donc exagérées, pas adaptées au besoins), ça rentre pour moi dans plus dans un concept de "moche" plutôt que "beau" (pour rester dans le subjectif). Pour moi, un code bien pensé est en fait un code simple. (qui fait le plus simplement possible ce qu'il est sensé faire). Ce qui ne veut pas dire qu'un code simple est facile à faire, bien au contraire...

Simple is beautifull. Ca aussi c'est une phrase que mon prof m'enseignait en dernière année de fac et qui m'a marquée.

[ManusDei]

Envoyé par VivienD

Euh... sinon... ça veut dire quoi «factoriser un code» ?

Au lieu de faire une fonction qui ajoute X à tous les élements d'une liste (renvoyant X'), une fonction qui va appliquer une fonction Y à chaque élement d'une liste (renvoyant Y'), une fonction qui va récupérer l'information Z de chaque élément d'une liste (renvoyant Z', liste des informations), tu fais une fonction qui prend en paramètre une liste L et une fonction F, et qui applique F à chaque élement de L, renvoyant L'.

Bref tu factorises 3 fonctions (à but unique) en une seule (qui a plusieurs utilisations possibles).

C'est parfois un poil plus compliqué à relire, mais si il y a un bug dans ta gestion des listes, tu n'auras pas à traquer chacune des fonctions appliquées à X Y et Z pour corriger un bug.

Ca c'est un exemple simple, souvent déjà prévu dans la bibliothèque de base du langage, mais c'est pour expliquer le principe.

[Traroth2]

Comprends ce que tu fais

Ça peut paraitre simple, mais ça ne l'est pas. Parce qu'on peut aller très loin dans la compréhension : Ok, tu fais du Java. Mais est-ce que tu sais comment fonctionne la JVM ? Le garbage collector ? Est-ce que tu connais le bytecode ?

Bien connaitre les fondements des outils, des principes, des langages, des méthodes qu'on utilise, c'est toujours payant, à la fin.

Aborde chaque problème avec naïveté

C'est en supposant plein de choses qu'on obtient un truc pas terrible à la fin.

N'ai pas peur de casser ce que tu as fait

Tout le monde écrit du code qui finit à la poubelle avant d'avoir jamais été utilisé. C'est normal, et même très bien. Si tu trouve une meilleure solution que ce que tu as déjà fait, n'hésite pas à refaire. sur le long terme, tu seras gagnant.

[betadev]

Pour moi , le plus important c'est de réfléchir au étapes à franchir lorsqu'on développe , étape par étape , de ce qui est général à ce qui est très spécifique

[Nemek]

Comme beaucoup, pas un mais plusieurs conseils en tout cas c'est ceux que je suis tous les jours. Ils recoupent ceux déjà cités par les gourous, membres de DVP, et ils recoupent également entre eux mais chacun avec sa petite spécificité :

• DRY
• KISS
• Réduire le problème à sa plus simple expression
• Mieux vaut un qui sait que dix qui cherchent
• Toujours exprimer ses idées par des phrases

Je détaille le dernier tant ca me sert dans mes heures les plus sombres. Si je cherche une solution à un problème, le fait d'exprimer mon problème avec des phrases permet dans 80% des cas de résoudre le problème. Je remercie d'ailleurs tous mes différents voisins pour avoir supporté que je commence une question et de les remercier avant d'avoir fini de la poser ^^
Idem quand je suis un peu perdu dans une réflexion ou que je pars un peu dans tous les sens, ca me permet de remettre les choses à plat.

Pour info :

Envoyé par Willy_XIII

camelCase vs under_score

snake_case

[Golgotha]

Beaucoup de bon conseil

Je rajouterais pour ma part, de toujours travailler avec des briques "simples". Ne faites jamais des fonctions de plus de 20 lignes par exemple. Cela permet de toujours décomposer le problème, d'y voir plus claire.

Quand mon code deviens complexe, je me dis que je vais dans la mauvaise direction.