Discussion :

[amira]

Bonjour

Il y a quelques temps j'ai eu l'occasion de travailler avec un type et j'ai été impressionnée par la qualité, la clarté et le sens de l'organisation de sa façon de coder. J'ai beau essayer de le faire moi-même j'arrive pas, la "qualité rédactionnelle" de mon code est toujours aussi pourrie, rien à faire.

Avez-vous des astuces, des trucs (hormis le "format" des IDE) pour écrire du beau code?

[kolodz]

Il faut faire la différence entre du "beau" code et du code "clair/lisible".

Mon approche est de faire une fonction pour tout ce qui peut-être réutiliser à un autre endroit.
Si une fonction fait plus de 100/150 lignes, c'est qu'il y a obligatoirement une fonction à créer dans celle-ci.
Pour finir, je nomme mes fonctions avec des noms explicites et des commentaires quand nécessaire.

Cordialement,
Patrick Kolodziejczyk.

[tchize_]

Je rajoute que ça dépend aussi de beaucoup de critère. Tu ne va pas coder de la même manière une application de 300 lignes qui ne changera pas en 5 ans qu'une module de 300 lignes dans une application qui est maintenue et évolue toutes les semaines. Ca dépend aussi fortement de l'urgence du code.

[amira]

Il y a ce liens qui donne quelques astuces, je trouve que c'est très ingénieux certaines car j'y avais jamais pensée.

http://equivalence.co.uk/archives/101

Du coup si vous avez d'autres liens ou d'autres astuces je suis preneuse !

[deathness]

D'après le lien que tu donnes ta définition de beau code est juste visuel.
Et ça c'est subjectif, typiquement le point A je préfère l'autre solution.

De plus avec un IDE comme Eclipse tu peux définir tes propres templates de mise en forme automatique, et ainsi avoir un visuel qui te correspond (sauter une ligne après une accolade ou non, longueur d'une ligne, ...).

C'est une vision très réductrice, et en tant que professionnel ce sont d'autre critères qui vont compter. Du genre donnée au-dessus, des critères comme la modularité, simplicité, maintenabilité, flexibilité, robustesse...

[Robin56]

Ca dépend aussi fortement de l'urgence du code.

Bien d'accord avec ça, la difficulté réside dans le fait d'avoir un code propre par rapport au temps donné (si nous avions du temps, nos applications auraient toujours un code assez propre). Et là pas de miracle, l'expérience permet de mieux saisir les bonnes pratiques, l'organisation et la clarté, ...

[bpy1401]

pour ma part, je pense qu'au début on est toujours plain de bonnes volontés.
Au départ, on veut faire bien, un beau code, bien commenté et et bien architecturé. Puis, vient ensuite le moment ou l'on s'aperçoit que l'on a mal pensé l'architecture , et on doit reprendre notre magnifique travail. Du coup, on n'est pas content donc on bâcle un peu les modification pour que l'on reprendre pour poursuivre. En final, on se retrouve avec un tas de nouille qui arrive à fonctionner, mais , qui franchement, ne respecte pas les règles de l'art, (les règles tout court d'ailleurs).

pour simplifier, c'est un peu comme le cycle en racine carré.