Qu'est ce que cela veux dire un "code propre" selon-vous ?

J'ajouterai MVC et classe métier là ou c'est utile.

A savoir :

M : Model : Le model métier du site
Idéalement ce model métier est constitué de classes qui permettent de mettre en oeuvre la logique métier.
=> Données (attribut)
=> Logique métiers (fonctions)

V : Vue : XHTML/CSS2
Là je sais pas encore. je vois 4 solutions
1) utiliser les maquettes fournit par le graphiste et repérer tout son horrible code dans chaque page .....
2) Découper la maquette dans des fichiers est faire des includes. (+évolutif, moins souple)
3) Utiliser un système de template générique
4) Créer une classe qui va se charger de l'affichage.

C : Contrôleur
Idéalement toutes les raquettes du client appel un contrôleur qui va construire son model métier (création des classes) effectuer ses traitements (Utiliser les fonction publique de la logique métiers) et appeler un vue.
le contôleur devrait étre un script


Ceci en complément de tout les autres conseilles

Pour moi un code propre c'est un code :
- que j'arrive a comprendre la démarche
- la logique
- qui est épuré (mais pas trop),
qui à été réalisé il y a 6 mois par un parfait inconnu.

Je me permettrais d'ajouter que pour moi, dans le cadre du développement web, un code propre essaye au maximum de distinguer:
- Le code HTML (structure de la page)
- La mise en forme (CSS, ...)
- Les aspects dynamiques de la page (lien vers la BDD et tous les processus dynamique)
Pour cela, ni l'ASP, ni la PHP ne sont les meilleurs... ASP.Net et Java le permettent beaucoup plus !

Pour moi un code propre c'est un code qui respecte les normes (exp: W3C pour le HTML)

Est ce que vous ne travaillez que sur des applications Web ?

Remarque comme ca en passant, les design pattern n'ont pas été inventer que pour faire des applications Web, il en existait avant l'avenement des applications 3 tiers, mais c'est vrai que la maitrise du pattern MVC laisse souvent la plus part des gens perplexes,

Pour ma part je pense que vous avez définit les grandes lignes "d'un code propre",

Respecter des conventions de codages (commentaires, nommage, indentations,...)

Respecter une structure d'applications claires et explicites (utilisation d'un design pattern, redaction de specifications, validation de conceptions, utilisation de cas de test,...)
Et autres remarques fait précedement,

Il manque juste un petit truc, faire preuve de bon sens et d'humilité pour prendre du recul sur ce que l'on fait ou produit pour être sur que c'est compréhensible,et toujours penser que celui qui maintiens n'est pas celui qui fait ;)

Un code propre... Je crois que je parlerai même d'un code "beau".

Ca commence évidement par de la mise en forme. De l'indentation constante (partout la même) et correcte.
Un bloc de commentaire au dessus de chaque fonction qui explique ce qu'elle fait avec à minima les parametres entrant et le résultat (@param et @result).
C'est aussi des fonctions de tailles raisonnables, avec un découpage intelligent.

C'est une façon élégante de résoudre un problème qui ne l'es pas forcément au premier abord. C'est un code clair, facile à comprendre, facile à maintenir, à faire évoluer.

Je crois que le meilleur critère reste encore le fait de revenir sur son code 6 mois plus tard et tout retrouver quasi instantanément.

Bonjour, c'est ici qu'on discute au bar ?

J'aime bien la définition de Rakken. Tout est dit, non ?

--> Je vais remettre une 2eme couche :
Pouvoir reprendre un code 6 mois ou 1 an plus tard, et le comprendre tout de suite est quand meme le principal !
--> Et pour appuyer la dernière remarque de wace :
Il faut aussi penser a celui qui est susceptible de nous remplacer, et reprendre le travail après nous.
(c'est aussi le cas des tutos, et des codes "open source")

NB : la norme WC3 n'est qu'une recommandation.
Alors ... du moment que ca marche !

En y réfléchissant avec le temps, "un code propre propre" ne veut pas dire grand chose. Je m'explique :
Tout dépend de quel point de vue. Est-ce au niveau globale d'un projet ou au niveau loupe. Vous pouvez avoir un projet bien organisé et sur les structures globale est bien pensé. Lorsqu'on regarde sur papier le structure du projet et comment sont géré les éventuelles objets ou librairies ça peut être super propre. Le projet tourne bien, fluide. Mais si nous regardons à la loupe l'intérieur des projets au niveau du code c'est Groznie.
A l'inverse vous pouvez avoir un projet ou tout est complètement retourné ou il est difficile de s'y retrouver mais le code est super propre bien indenté, commenté, etc.
Je rajouterais qu'un code peut être propre pour l'un mais pas pour l'autre car souvent il y a beaucoup de développeur PHP, généralement, qui sont piéger. Le réflexe de vouloir trop automatiser les choses. Et là, vous partez dans des projets qui peuvent partir en sucettes.

Bonjour,

Je ne suis pas d'accord avec toi berceker united, un code propre n'est pas quelque chose de purement subjectif, il ne s'agit pas d'une oeuvre d'art où chacun est libre d'établir sa propre orthographe ou grammaire au détriment de l'autre.

Il ne s'agit pas non plus d'automatiser à outrance des processus, mais de les rationnaliser, les industrialiser.

En suivant ton raisonnement, on pourrait considérer à l'extrème que le langage SMS est une manière tout a fait propre d'écrire, puisque sémantiquement valable.

Un code propre est un code qui répond à des règles, des conventions, des recommandations communes. À des normes si celles-ci sont établies.

(...)

Par ailleurs, on cite souvent l'indentation comme preuve de "code propre" hors, la plus part des IDE propose une fonctionnalité qui indente ou formate le code à la demande...

Pour les commentaires, c'est la même chose. Au lieu d'en mettre partout, il est préférable d'utiliser formélement du Javadoc, PHPdoc, etc. lorsque c'est possible. C'est beaucoup plus efficace.

Dans le fond, un code propre est un code documenté et épuré raisonnablement de sa complexité.

Bonjour je rajouterais juste un truc qui a été dit plus ou moins vaguement c'est la modularité du code.

Citation:

---

La classe faisait >3000 lignes.

---

Je trouve ça totalement anormale, une classe au grand maximum devrait faire entre 300 et 500 lignes maximum.

Je rajouterais également qu'il faudrait que dans l'entête il faudrait expliquer les différents require, include, ... : dire pourquoi on les appelle.

En fin pour ceux qui connaissent les design pattern les classes d'accès à une base de données devrait toujours être une classe singleton et pour les interfaces si on ne passe pas par un modèle MVC, il faudrait au moins passer par une factory pour pouvoir rajouter facile et rapidement du contenu : par exemple une array qui contient les informations nécessaires pour appeler les pages demandées par un menu et la fonction eval pour faire tourner tout ca. Comme ça après plus besoin de se casser la tête à trouver où insérer les autres pages du menu suffit de modifier l'array.

ps : j'espère avoir corrigé toutes les nombreuses fautes que j'avais faites si non veillez m'en excuser

Citation:

---

Envoyé par charlene44

4 - utiliser la méthode MVC et ne pas programmer "en spaghetti"

---

C'est vrai qu'en utilisant la méthode MVC, on doit respecter des règles et la propreté du code s'en trouve améliorée.

Moi je dirais qu'il faut commencer par une indentation rigoureuse.
Dans ces commentaires s'attacher à décrire la fonctionnalité plutot que la procdure de développement. (Typiquement cela veut dire qu'on commence par écrire un bloc de commentaire pour expliquer le but. Ensuite on code et on commente.).
Tenter d'etre aussi dry que possible tout en gardant de la simplicité, dry != usine à gaz.
Ecrire du code cohérent qui nécessite le moins de reflexions possibles.
Par exemple éviter d'utiliser les règles de transtypage à outrance. Ce sont des sources d'erreurs grosses comme des maisons, très très difficile à détecter pour un néophyte en PHP.

ne pas s'attacher à commenter un truc qui n'en nécessite pas.

Ce qui est plus difficile, mais qui aide énormément, c'est d'apprendre à identifier et dissocier les différents composants d'un sous programme.
Par exemple, dans un site Y, vous faites un module maximiles.
Comme c'est un webservice, il vous faudra écouter les évenements et les étudier à posteriori en cas de problemes (donc des logs), de plus il vous faut un moyen simple d'interroger un ws distant(pour le coup extremement simple). Et enfin, avec ces bases, proposer une implémentation du service maximiles.
J'ai bien identifié trois développement distincts, dont deux qui s'appuie sur des généralités.
Faire un code propre c'est aussi identifier ces différents composants afin de les mutualiser pour certains, mieux les découpler pour d'autres.
Derrière cela permettra de créer des tests unitaires mieux cibler et plus utile.

Dans le même genre d'idée, un fichier par classe, des classes groupées par dossier, une regle de nommage à la zend (? c'est plus discutable, mais c'est un moyen comme un autre).
Pour ceux qui travaille en php4, on ne fera pas un fichier par fonction, mais un fichier par objet métier et ces fonctions associés + une regle de nommage pour le coup.

Selon moi un code propre c'est (developpement web) :

Partie HTML valide W3C.
Utilisez la même syntaxe du début à la fin.
Utilisation de la tabulation et des retour à la ligne.
Mise en procedures et en fonctions des opérations redondantes.
Préféré un code multisupport (navigateurs) à différents codes en fonction du navigateur, à condition que l'on obtienne le résultat escompté.
Mais cela passe aussi par une bonne organisation du site au niveau dossier/fichier. De telle sort que les scripts php, Js, ect soit séparé et que les fonction soit regroupé de maniére à être retrouvé plus facilement tout en étant raisonnable bien sur ^^ (pour ceux qui on déjà du reprendre un site c'est quand même bien pratique).
Bien sur un code juste et optimisé.
Et je me répéte éviter les redondance via les appels de fonction ou de fichier (ex: script de connection à la bdd ou script Js pour la visibilité ou chargement d'un bloc);

Coder proprement c'est :
Adopter une convention et s'y tenir au fil du temps.

Par exemple en entreprise j'ai trop souvent vu (de moins en moins certes) du code aux normes stratifiées (période, développeur, modes(?) )

un code propre c'est ça devrait être :

un code que vous pouvez passer en revue et le comprendre fonctionnellement un an après l'avoir écrit ;)

Selon moi, un code propre c'est un code aussi conci, compacte et lisible que possible.
Je considère en effet que toute opération qui diminue la taille du code (tout en conservant sa sémantique) revient à débarasser le code de saleté
ex :
i +=1 est à mon sens plus propre que i=i+1

Ce que jeromeslan appelle coder proprement moi je l'appelle coder avec cohérence.

edenreal a parlé selon moi d'un code valide, cohérent (dans la forme), lisible, propre et optimisé.

Je trouve que slam a répondu de façon très propre à cette discussion, tant dans le fond de sa pensée que dans la forme qu'il a utilisé.

Citation:

---

Je considère en effet que toute opération qui diminue la taille du code (tout en conservant sa sémantique) revient à débarasser le code de saleté
ex :
i +=1 est à mon sens plus propre que i=i+1

---

Là, je vais mettre un bémol (outre le point de détail que pour faire i = i + 1, on fait i++ ou ++i :aie:), parce que je ne suis pas d'accord.

L'exemple le plus flagrant, c'est celui des opérateurs ternaires, qui, assurément, rendent le code plus "petit", par contre, à la lecture, pour la majorité des développeurs (d'expérience), ça prend plus de temps à lire qu'un bête "if" écrit à la main.

Code:

---

1 2 3 4 5 6 7 8 9 10

// code court : $eleve_admis = ($moyenne >= 10) ? true : false;   // Code le plus facile à lire if ($moyenne >= 10) { $eleve_admis = true; } else { $eleve_admis = false; }

---

La première version est plus courte, mais pas nécessairement plus agréable à lire plus la majorité. Ici, l'exemple pris est "fonctionnellement" évident, donc on s'y retrouve bien. Si on complique un tout petit peu le test avec des valeurs moins évidente, ça peut vite piquer la tête.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

// version "courte" $var = (($a / 5) > ($b + 3)) ? $a + $b : (($a > $b) ? 5 : 20);   // version lisible directement. if (($a / 5) > ($b + 3)) { $var = $a + $b; } else { if ($a > $b) { $var = 5; } else { $var = 20; } }

---

La concision n'est nécessairement pas gage de clarté, bien au contraire.

Citation:

---

Envoyé par kagura

Bonjour,

Qu'est ce que cela veux dire un "code propre "selon-vous ?

:merci:

---

C'est un code facilement MAINTENABLE par son créateur ( 6 mois plus tard) ou par un dev qui connait le langage mais pas le fonctionnel.

Après ça il y a toutes sortes de "techniques" pour y arriver.

Citation:

---

Envoyé par Rakken

Là, je vais mettre un bémol (outre le point de détail que pour faire i = i + 1, on fait i++ ou ++i :aie:), parce que je ne suis pas d'accord.

L'exemple le plus flagrant, c'est celui des opérateurs ternaires, qui, assurément, rendent le code plus "petit", par contre, à la lecture, pour la majorité des développeurs (d'expérience), ça prend plus de temps à lire qu'un bête "if" écrit à la main.

...

La concision n'est nécessairement pas gage de clarté, bien au contraire.

---

Je suis entièrement d'accord, c'est vrai que quand on développe des fois on se dit "plus c'est court, mieux c'est". Pour nous même, sur le moment, c'est peut être vrai, on sait ce qu'on fait, pourquoi on le fait etc... Mais si on revient plus tard sur le code, là ce sera beaucoup plus délicat.

Donc pour les opérateurs ternaires, c'est vraiment flagrant mais si en plus on les combines avec des appels de fonction au milieu dans quelque chose du genre:

Code:

---

$var = (($a / 5) > ($b + $this ->getMonParamFor(3)) ? $a + $b : (($a > $b) ? $this ->getMonParamFor(5) : 20);

---

Enfin, des choses du genre, ça devient complètement l'enfer.

Pour revenir au sujet principal je n'ai pas lu absolument toutes les interventions mais j'ai lut que certains affectionnaient les commentaires et là, j'aimerais aussi ajouter un bémol. Quelqu'un m'a dit un jour qu'un code propre c'était un code qui s'auto-suffisait et je trouve que c'est assez vrai.

Dans une certaine mesure, si il y a besoin de commentaires, c'est que le code n'est pas assez clair, les variables et les fonctions mal nommées. Avec un bon découpage, des noms bien choisis et un "algorithme" bien pensé, il ne devrait pas y avoir besoin de commentaires.

Personnellement quand je vois quelque chose du genre:

Code:

---

1 2 3 4 5 6 7

/*Fonction qui retourne le nom d'un client pour un identifiant @param customerId: identifiant du client @return Nom du client dont on a donné l'identifiant*/ function getNameForId($customerId) { ... }

---

1-Le commentaire ne m'apprend rien
2-Il m'embrouille, prend de la place pour rien
3-Imaginons qu'il ne soit pas maintenu après une modification et c'est le pompon....

Donc pour résumé je préfère un code bien pensé, bien découpé etc... Qu'un code un peu "à l'arrache" mais avec des supers commentaires de partout...

Un code est propre lorsqu'il n'y a pas de commentaire, et qu'il n'est pas utile d'en ajouter.

Taille moyenne d'une méthode : 6-7 lignes.
Grand max à 10 lignes

Un code propre c'est un code bien indenté, bien commenté, simple, efficace, sans faille et surtout dynamique ou dynamisable