Bonjour,
Qu'est ce que cela veux dire un "code propre "selon-vous ?
![]()
Bonjour,
Qu'est ce que cela veux dire un "code propre "selon-vous ?
![]()
Un code propre, ça veut dire deux choses :
1°) un code propre à voir, c'est vrai, bien indenté, avec une cohérence dans les noms de variables et de fonctions, etc...
2°) mais ça veut aussi un dire un code sans erreurs conceptuelles, sans erreurs grossières, sans désoptimisations (exemple : "$mavar"), sans lourdeurs... etc... en bref, un code dont la sémantique est cohérente... si on utilise des guillemets simples et la concaténation pour les variables, le faire tout le temps, et n'utiliser les guillemets double que quand c'est nécessaire ("\r\n" par exemple)
si on utilise sprintf, l'utiliser tout temps...
etc...
Rédacteur "éclectique" (XML, Cours PHP, Cours JavaScript, IRC, Web...)
Les Règles du Forum - Mon Site Web sur DVP.com (Développement Web, PHP, (X)HTML/CSS, SQL, XML, IRC)
je ne répondrai à aucune question technique via MP, MSN ou Skype : les Forums sont là pour ça !!! Merci de me demander avant de m'ajouter à vos contacts sinon je bloque !
pensez à la balise [ code ] (bouton #) et au tag :resolu: (en bas)
ca dépend, si c'est de l'HTML ca peut dire valide W3C.
si c'est du PHP, voir le post de Swoög, auquel j'ajoute :
ca peut aussi dire utiliser les balise code ou bbcode pour que les membres du forum se casse pas les yeux dessus, et pas forcement poster tout le code, mais les parties judicieuses pour analyser le probleme rapidement (avec les numéro de lignes si possible etc.)
le plus souvent moi je dis : balise code et code pas valide ...![]()
Je vais rejoindre les dires de Swoög concernant la cohérence et être fidèle à ça manière de codé du début à la fin.
Quand on prend un projet entier d'une autre personne il y a la phase ou il faut comprendre ça manière de voir les choses. Si au bout 1/2 heure nous nous aperçevont qu'il a son propre protocole d'écriture de code ça devient plus facile pour la suite même si ce qu'il a fait n'est pas forcément bien ficelé mais dans l'essentiel c'est d'arriver à comprendre vite. Pour mon projet perso j'ai établie un protocole unique sur le nommage de mes variable. Ex
$arrObjUtilisateur; => Tableau d'Objet Utilisateur
$objUTilisateur; Obj Utilisateur
$arrXxxx; => Tableau de ....
$i , $j, $k, $l , ... Variable d'incrémentation ou décrémentation.
...
Dans mon projet c'est ainsi tous le temps. Apres ça reste discutable sur les nom ou la maniere mais tant que je reste fidèle. Le but est de rester compréhensible et se dire tous le temps: "Et si autre dev voit mon code est-ce qu'il va comprendre? et si je reviens 6 mois plus tard est-ce que je vais comprendre".
Code propre c'est aussi un code organisé, structuré. Pas des même requêtes qui se trouve dans différent fichiers ou il faut courir après parce que la structure de la base de données a changé. Certe c'est pas tous le jours qu'ont change la structure d'une table mais quand ça arrive t'es degue.
Je permet d'ajouter èa ce post très bien quelque petit détails qui peuvent etre bien, les commentaires (on en mets pas suffisament ou encore pas aux bons endroits)
Je crois qu'un entete dans chaque page sur l'utilité et la finalité du script est intéressant a avoir, comme ca dans la réutilisation de code on peut savoir rapidement de quoi il en est
La description des fonction que l'on créé ainsi que la description des paramètres se vaut un outils important dans la structure et la propreté
Et finalement si une journée on programme et sommes très "dans notre bulle" on peut créere des algorithme qui peuvent etre difficile a comprendre plutard s'il comporte beaucoup de ligne de code...un petit commentaire sur les parties moins évidante est grandement apprécié
Pour ma part, je me garde un fichier de variable session pour identifié à quelle page on les initialisent, les détruient, leur attribuent de nouvelle valeur...C'est plus facile de les retrouver dans une application comportant plusieurs plusieurs page
![]()
genre ca : http://www.developpez.net/forums/sho...28#post1112428
ca donne pas envie de le lire, apres tu notera qu'il y a quand meme de l'indentation etc.
Je pense qu'il ne faut surtout pas confondre du code propre et de la validation W3C !Envoyé par Maxoo
Si l'on parle de (X)HTML (par exemple) et W3C; on fait plutôt référence à de la sémantique web (rigueur dans la structuration grammaticale des pages, séparations du contenu et du contenant)...
...Et si on parle du W3C en général, il s'agit plutôt de normes (recommandations ou standards) de conceptions uniformisées.
A mon avis, même si on peut jouer sur les mots, je pense que ce n'est pas une bonne idée d'assimiler W3C et le fait de "coder proprement".
Ce que j'appelerais du code propre (et je suis assez stricte avec moi-même dans le domaine ) :
- Une convention permanante pour tous les noms de classes, attributs, méthodes, fonctions, variables ou constantes...
- Tous ces noms dans une seule langue (pas de pseudo-langage français<->anglais)
- Eviter au maximum les abréviations.
- Commentaires "PHPdoc" aux endroits opportuns.
- Indentation contrôlée...
- Initialisation de toutes les variables
- Pas de code grossièrement superflux (typiquement un bloc "else" juste après un bloc "if" contenant un "return" explicite ! )
- En orienté objet, essayer de respecter les principes de conception objet.
- En procédural, répartir le code en fonctions (bonne chose de faite !)
- Toujours généraliser (factoriser) son code source lorsque c'est possible ! (Sans que ça tourne à l'obsession
).
- Et dans les programmes en général, définir dès le départ une arborescence logique pour placer ses scripts, fonctions, classes, etc.
Evidemment, il est difficile de respecter toutes ces directives, et pour ainsi dire, j'ai rarement vu des scripts ou applications PHP respectant parfaitement ces (mes) conventions, mais enfin, les perfectionnistes comprendront.
Dernière modification par Invité ; 28/06/2006 à 22h17.
Autre chose. Si vous connaissez un peut l'objet et que vous travaillez en équipe ne faite pas d'objet parce qu'il y a pas pire qu'une personne qui utilise l'objet sans aucune logique c'est pire que tous.![]()
Un code propre c'est :
1) un code sans superflu
Exemple pour le html : j'ai l'habitude de travailler avec des graphiste intégrateur qui conçoivent les pages web avec des tableaux imbriqué dans des tableaux eux même dans des tableaux.. Qui répètent dans chaque page les mêmes morceaux de code.
Le code est horrible à dynamiser, imaintenable, totalement inévolutif
=> vive xhtml et css2 !!
2) Bien commenté
Pour ma part (dans mes bon jour je met presque 25% de code dans mes script)
3) Respecter ses convention
Convention de nomage, de répartition du code dans les fichiers etc...
L'utilisation de fichier de configuration est fortement conseillé..
+) Rédiger une note sur la programmation pour ses successeurs
Bref faire tou ce que je ne fait pas ^^
Bon code @ tous
D'un autre coté... Moi j'ai eu droit à des individus qui imbriquaient plusieurs blocs <div> sous prétexte de ne pas pouvoir utiliser les tableaux pour stigmatiser leur interface...Envoyé par SoF_AzraeL
En plus d'utiliser une classe par bloc !
D'un extrème à l'autre![]()
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é.
Là, je vais mettre un bémol (outre le point de détail que pour faire i = i + 1, on fait i++ ou ++iJe 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), 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 php : Sélectionner tout - Visualiser dans une fenêtre à part
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 php : Sélectionner tout - Visualiser dans une fenêtre à part
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.
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 php : Sélectionner tout - Visualiser dans une fenêtre à part $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 php : Sélectionner tout - Visualiser dans une fenêtre à part
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
Partager