Discussion :

[hegros]

En effet RAII ca y'est ce billet m'a convaincu définitivement pour l'adopter dans ma bibliothéque de bonnes pratiques de programmation.


au départ je pensais qu'il s'agit d'une technique propre au c++ ou un concept trop complexe à appréhender rapidemment


Lorantus oui surement, un savoir faire sans un faire savoir ne sers à rien non ?

[hegros]

il y a d'autres pratiques ou sens comme les odeurs de code qui sont en rapport avec code propre.

une technique facile à utiliser pour reconnaître un code propre c'est le tape à l'oeil quand il y a un doute c'est qu'il n'y a pas de doute refactor process

[chaplin]

une technique facile à utiliser pour reconnaître un code propre c'est le tape à l'oeil quand il y a un doute c'est qu'il n'y a pas de doute refactor process

- J'appelle ça, l'intuition et l'instinct de survie avant que tout n'explose à la figure .

[srahal]

Non, il ne faut pas bannir le goto de façon si définitive. En certaines circonstances, son utilisation est tout à fait légitime

Un programme "SPAGHETTI" est un programme qui contient trop de goto
est aussi un programme qui devient illisible

[ZIED]

un code simple est un code qui utilise un standard ou des conventions claires, des noms de variables significatives (exp : Désignation claire , nature de la variable à travers l'utilisation des préfixes...)
Il présente une structure modulaire pour faciliter l'extensibilité et améliorer la maintenabilité...
Une architecture avec séparation des couches (exp Modèle MVC...) est très appréciée.

[Astr0]

Génial ce débat sur le code propre

A titre personnel, dans la nébuleuse "code propre / lisible / efficace", je trouve que le livre "Code Complete, Second Edition" de Steve McConnell (http://www.cc2e.com/) donne pas mal d'éléments qui peuvent contribuer à avoir un code propre.

Je lisais ça de manière sporadique il y a quelques mois pendant mes études, pour les projets et en lisant ce thread, je vais m'y remettre maintenant que j'ai un pied dans le monde professionnel.

Un exemple de bonne idée / pratique dont je me souviens est la réduction de la distance entre la déclaration d'une variable et son utilisation. Ça permet de voir très vite comment est utilisée la variable.
Ou regrouper des instructions qui agissent sur un même ensemble de données. Ça permet de voir sur des lignes contiguës ce qui est fait des données. Ça peut aussi être utile pour mettre en évidence des portions de codes qui peuvent être factorisées. Il y a davantage d'explications dans le livre mais là de tête je ne sais plus

C'est un peu une redite des posts précédents mais c'était avant-tout pour citer le livre

[srahal]

Génial ce débat sur le code propre

A titre personnel, dans la nébuleuse "code propre / lisible / efficace", je trouve que le livre "Code Complete, Second Edition" de Steve McConnell (http://www.cc2e.com/) donne pas mal d'éléments qui peuvent contribuer à avoir un code propre.

y' aussi ce livre que je lis en ce moment
http://www.eyrolles.com/Informatique...-9782744023279

[Matthieu Brucher]

Ca va, ça ne fait que la quatrième fois qu'on le cite ici

[Garulfo]

Ca va, ça ne fait que la quatrième fois qu'on le cite ici

C'est symptomatique des personnes qui répondent sans prendre le temps de lire -_- Inévitable donc.

[Gtrwld]

Sous la pression du temps, il m'est arrivé de commettre quelques infâmes bouses

Finalement, un code propre c'est un code auquel on a réfléchi au lieu de le pisser comme un malade. (Même si c'est toujours possible de faire n'importe quoi après avoir réfléchi )

[viking1404]

Il n'y a qu'une seule vraie réponse à cette question et elle se trouve ici :
http://sexycoders.com/2008/07/19/cod...-commentaires/

il y a aussi ca :
http://sexycoders.com/2008/12/11/coding-horror/

et enfin ceci :
http://sexycoders.com/2008/01/04/le-...un-sexy-coder/

Quand j'ai lu ces articles pour la première fois, je me suis dit : c'est un peu extrémiste quand même.
Finalement, quand je vois ce que font certaines personnes personnes de mon entourage, je me dit que ces articles ne sont pas si bêtes.

Sinon pour un avis personnel et plus constructif je dirais que
- Un code propre est un code bien indenté.
- Ou les accolades sont placée après le saut de ligne.
- Les commentaires ne sont pas trop nombreux et bien placé.
- Les algorithmes sont bien réfléchis.
- La conception du programme est logique.

[chaplin]

Parmis les remarques des "sexycoders", l'un a donné un lien sur une vidéo très ludique.
J'avoue être impressionné par la démonstration, mais c'est l'exemple d'une conception logique pour arriver au but.

[styvsun]

un code propre, c'est avant tout la structuration de ce dernier, c'est -à-dire de la declaration de variables, classes, methodes, fonction à leurs utlisations doit etre le resultat d'une approche systematique. en ajoutant à cela une documentation (commentaire) suffisante.

[pseudocode]

Question : est-ce que quelqu'un à un exemple de code source qu'il considère comme étant du "code propre" ?

[programmeur94]

Un code "propre" est un code pour lequel les symboles (identificateurs de variables, fonctions, méthodes, classes), sont correctement choisis. Plus le choix des symboles sera pertinent et plus le code sera lisible et maintenable, bref compréhensible. On peut observer que les auteurs des APIs Java ou .NET ont un souci particulier pour le choix des noms et verbes utilisés. Trop souvent, les développeurs choisissent des noms trop abstraits ou génériques, qui ne nuisent pas au fonctionnement du code, mais nuise à sa compréhension.

[mayayu]

Un code propre rime pour moi avec code maintenable.

Voilà quelques règles que je m'applique pour obtenir un "code propre" selon mes critères :

• un fichier CPP et un fichier H par classe (aussi petite soit-elle),
• utiliser la notation hongroise pour les noms de fonctions et de variables,
• utiliser les commentaires format "doxygen" pour documenter chaque classe, fonction, variable,
• essayer de faire des fonctions lisibles intégralement sur un écran (30/40 lignes max) mais c'est pas toujours possible,
• aérer le code en sautant des lignes entre chaque groupe d'instructions ayant un sens à être regroupées ensembles,
• commenter systématiquement ces groupes d'instructions,
• une indentation systématique de taille 4 (8 c'est trop) pour chaque boucle ou instructions de test.

Moral de l'histoire : Commentez, commentez, commentez...

[Matthieu Brucher]

• utiliser la notation hongroise pour les noms de fonctions et de variables,

Moral de l'histoire : Commentez, commentez, commentez...

Mouais...
Plus aucune personnalité reconnue du monde de la programmation ne dit de programmer avec la notation hongroise, au contraire, il faut l'éviter comme la peste.
Pourquoi devoir renommer une variable si on a changé son type (passage d'une liste à un vecteur parce que plus adapté) ?

Et les commentaires, c'est la même chose, trop de commentaires tuent le commentaire. Le commentaire doit être présent de manière parcimonieuse pour qu'il ait un impact. Autrement, la fonction doit pouvoir se suffire à elle-même.

[Matthieu Brucher]

Un code "propre" est un code pour lequel les symboles (identificateurs de variables, fonctions, méthodes, classes), sont correctement choisis. Plus le choix des symboles sera pertinent et plus le code sera lisible et maintenable, bref compréhensible. On peut observer que les auteurs des APIs Java ou .NET ont un souci particulier pour le choix des noms et verbes utilisés. Trop souvent, les développeurs choisissent des noms trop abstraits ou génériques, qui ne nuisent pas au fonctionnement du code, mais nuise à sa compréhension.

Complètement d'accord.

[hegros]

Petite remarque sur RAII : c'est bien spécifique au c++ certains langages ne le permettent pas garbages collector ou pas.

Bien que RAII me semble aussi applicable à un niveau au dessus du code c'est à dire quand je conçois mes classes déjà les problématiques de lisibilité/portée de variables/paramètres sont exposées.

[mayayu]

Mouais...
Plus aucune personnalité reconnue du monde de la programmation ne dit de programmer avec la notation hongroise, au contraire, il faut l'éviter comme la peste.
Pourquoi devoir renommer une variable si on a changé son type (passage d'une liste à un vecteur parce que plus adapté) ?

Et les commentaires, c'est la même chose, trop de commentaires tuent le commentaire. Le commentaire doit être présent de manière parcimonieuse pour qu'il ait un impact. Autrement, la fonction doit pouvoir se suffire à elle-même.

Au contraire, je trouve la notation hongroise très utile, ça évite d'avoir à consulter systématiquement la documentation pour connaître le type des variables.
Par ailleurs, si on change sans arrêt les liste en vecteurs, c'est qu'il y a un problème de conception.

Pour les commentaires, je suis d'accord qu'il ne faut pas commenter tout ce que l'on a fait, mais fournir quelques explications peut s'avérer très utile quand ça fait 3/4 ans qu'on a pas mis le nez dans l'application, ou quand c'est une autre personne qui doit le mettre.