Discussion :

[eldran64]

Bonjour à tous,

Comme une majorité de débutant , je viens de coder un programme de A à Z sans avoir préparé quoi que soit. Mon code fonctionne et tiens la route.

Mais mon code est surtout devenu un vrai foutoire!! Des fonctions dans tout les sens avec un algo alambiqué.

Bref, c'est pas la joie. Pour mettre un terme à tout cela, je souhaiterai mettre de l'ordre. Et c'est là que le bas blesse puisque j'ai aucune idée de par où commencé.

Si quelqu'un à une idée... cela me sauverai moi et mon code...

Merci pour vos commentaires!!!

[likoudA]

Bonjour,
Déjà, il faut commenter son code. Un bon programmeur doit bien commenter, c'est très important. Ensuite, je te conseille de créer plusieurs classes qui contiendront chacune un certain nombre de fonctions afin de séparer au maximum tes traitements et tes objets. Enfin, il y a un certain nombres de conventions à respecter, voir ici.
bonne chance.

[Philou67430]

Pour ce qui est du code, avant de le commenter, il convient de bien nommer les identifiants (variables, fonctions) : cela réduit d'autant la nécessité de longs commentaires.
Ensuite, les commentaires ne doivent pas simplement "traduire en français littéraire (ou en anglais, ce qui serait encore plus absurde)" le code qu'il explique, mais plutôt l'opération dans le monde réel qu'elle représente.
Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
# Boucler de 0 à $taille_base
for (i = 0 ; i < taille_base ; i++) ...

ne fournit aucune information, contrairement à :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
# Parcourir tous les utilisateurs de la base
for (i = 0 ; i < taille_base ; i++) ...

Mais le plus important avant de commenter et de bien nommer les variables, c'est de bien identifier les concepts sous-jacents à tes fonctions/structures de données et à les regrouper/recomposer de manière cohérente au sein de fonctions, modules, d'objets, de classes, ... Cela s'appelle parfois analyse, conception, ou encore modélisation. C'est généralement un préalable, mais cela peut être aussi la suite d'un prototypage (comme on pourrait qualifier ton programme actuel).

Exemple :
Dans ton application, tu disposes d'un tableau contenant des structures d'utilisateurs. Ton application doit mettre à jour le nombre et le temps de connexion d'un utilisateur en fonction de son login.
Tu auras écris une fonction : maj_nb_conn et une autre fonction maj_duree_derniere_conn qui chacune, prendra le login en paramètre (ainsi que des données annexes de traitement).
Dans chacune de ses fonctions, tu réalises la recherche dans la table des structures, de la structure pour le login donné, puis tu réalises l'opération de mise à jour (respectivement du nombre de connexion et de la durée de la dernière connexion).
On voit qu'il y a ici redondance : la recherche dans la table est écrite deux fois. Ce n'est pas très propre, car si la structure la table change, il y a fort à parier qu'il faudra modifier les deux fonctions. Par ailleurs, on peut se dire que la table des utilisateurs est une notion suffisamment importante dans le programme pour qu'elle dispose de son propre module (ou de sa propre classe en modélisation objet), et ainsi, de séparer le traitement de la table des utilisateurs de celui des connexions/déconnexions.
Ainsi, les nouvelles fonctions maj_nb_conn, et maj_duree_derniere_conn se concentreront sur le traitement de la connexion et relègueront la mise à jour de la table d'utilisateurs à un autre module/une autre classe.

[nbenbourahla]

Bonjour

Voici quelques règles que j'applique personnellement, ses règles je les ai apprise dans mon école d'informatique, et finalement je les appliques meme en dehors et je trouve que c'est une bonne chose

- Commenter tes fonctions
- Fixer une limite de taille par fonction (par exemple en C je fais en sorte qu'aucune fonction ne dépasse 25 lignes)
- Limiter le nombre de fonction par fichier (a par en objet bien sur lol)
- Espacer un peu tes fonctions
- Mettre toujours tes déclarations de variable au début des fonctions (a par nécessite) car je trouve sa moche plein de variable au milieu du code alors qu'on pourrait bien les mettre au début
- Espacer ton code
...

Après tu peux t'imposer toi même d'autre regle pour que ton code soit propre et compréhensible pour une autre personne

De rien
Bonne continuation

[Philou67430]

- Mettre toujours tes déclarations de variable au début des fonctions (a par nécessite) car je trouve sa moche plein de variable au milieu du code alors qu'on pourrait bien les mettre au début

Je ne suis pas d'accord avec cette règle : lorsque c'est possible (C++, car en C, ce n'est pas toujours possible), je préconiserais plutôt de déclarer les variables au plus près de leur utilisation, et ce pour plusieurs raisons :
- éviter les effets de bord en limitant au maximum la portée d'une variable
- pour rendre "lisible" cette déclaration lorsque l'on lit le code qui l'utilise (notamment pour voir son type et sa valeur initiale).

[Mac LAK]

Je ne suis pas d'accord avec cette règle : lorsque c'est possible (C++, car en C, ce n'est pas toujours possible), je préconiserais plutôt de déclarer les variables au plus près de leur utilisation, et ce pour plusieurs raisons :
- éviter les effets de bord en limitant au maximum la portée d'une variable
- pour rendre "lisible" cette déclaration lorsque l'on lit le code qui l'utilise (notamment pour voir son type et sa valeur initiale).

Si c'est dans une boucle simple, et exclusivement pour son indice, éventuellement. Sinon, c'est un beau nid à bugs introuvables, notamment et surtout par masquage d'une variable existante...



Sinon, pour un code propre :
- Commenter intelligemment : un commentaire qui décrit le code, ça ne sert à rien, on n'est pas idiots et on sait lire du code... L'exemple de Philou67430 est très significatif.
- Indenter de façon régulière : respecter une indentation constante dans le projet, et non pas un coup avec 2 espaces, un coup sans, un coup une tabulation, etc...
- Quelle que soit la norme de codage que tu appliques, suis-la SANS EXCEPTIONS.
- Modulariser son code, mais éviter les dépendances façon "poulpe plein de tentacules". Si chaque fonction que tu implémentes dépends de dizaines d'autres fonctions plus ou moins interdépendantes, tu vas créer un code tentaculaire difficile à maintenir et à comprendre.
- Éviter les lignes vides "pour rien", tout comme les fonctions trop longues ou les blocs inutilement éclatés.

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
if (condition)
{
	variable = valeur1 ;
}
else
{
	variable = valeur2 ;
}

Ceci est très laid, ça prends une place infernale à l'écran, et ça nuit plus à la lisibilité qu'autre chose...
Une version plus lisible est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
if (condition)
	variable = valeur1 ;
else
	variable = valeur2 ;

Déjà plus compact, tout aussi lisible... Et, dans le cas précis qui nous occupe, on a encore mieux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

variable = (condition) ? (valeur1) : (valeur2) ;

Il ne faut certes pas exagérer sur les opérateurs ternaires, mais il ne faut pas non plus les rejeter pour rien.
Ceci étant dit, il faut quand même éviter ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(condition1) ? (variable1) : (variable2) = (condition2) ? ( (condition3) ? (valeur1) : (valeur2)) : ( (condition4) ? (valeur3) : (valeur4)) ;

Certes, c'est du code "légal", mais c'est pas facile à suivre...

[Philou67430]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
if (condition)
	variable = valeur1 ;
else
	variable = valeur2 ;

De nombreux recueils de règles de codage interdisent cette construction sans bloc, source de bug potentiel lors d'une maintenance.

Je ne veux pas lancer une polémique sur l'usage des accolades, mais pour une bonne lisibilité, je préfère utiliser cette forme de bloc :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
if (condition) {
  variable = valeur1;
}
else {
  variable = valeur2;
}

qui permet de "gagner" en hauteur, sans perdre en lisibilité. L'autre avantage est que la condition est située juste au dessus du traitement (l'accolade ouvrante n'apportant guère d'information étant donné que l'indentation de la ligne suivante indique clairement qu'un bloc à démarré).

[Philou67430]

Ceci étant dit, il faut quand même éviter ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(condition1) ? (variable1) : (variable2) = (condition2) ? ( (condition3) ? (valeur1) : (valeur2)) : ( (condition4) ? (valeur3) : (valeur4)) ;

Certes, c'est du code "légal", mais c'est pas facile à suivre...

Attention, l'usage d'une expression conditionnelle est tant que lvalue est obsolète :

gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
a.c: In function `main':
a.c:3: warning: use of conditional expressions as lvalues is deprecated

[Mac LAK]

Tant qu'à ajouter des accolades "de force", je préfère cette syntaxe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
if (condition) {
  variable = valeur1;
} else {
  variable = valeur2;
}

Une ligne en moins... C'est du moins la syntaxe que j'utilise en blocs multilignes.
Toutefois, dans le cas de blocs constitués d'une seule ligne, je trouve au contraire que ça alourdit le code : l'absence d'accolades permet, justement, de voir que c'est un traitement "simple"...

Toutefois, j'ai tendance à considérer que si un programmeur indente correctement, et qu'il est assez idiot pour rajouter des instructions dans un "bloc" sans en vérifier les bornes, faudrait qu'il envisage de changer de métier... S'il n'indente pas, il est URGENT qu'il change de métier...

Faut pas pousser non plus : s'il faut toujours faire les programmes (et les normes de codage) de façon à ce que le débutant lambda et/ou les non-informaticiens arrivent à suivre, on ne s'en sort pas... Ce sont quand même des "professionnels" qui sont censés tripoter le code, donc des gens qui ont des notions fondamentales comme les blocs, la portée, etc. !

Si c'est un débutant pur jus, il est censé avoir de bonnes bases d'algorithmique, et connaitre au minimum la syntaxe du langage... Si c'est le cas, il ne tombera pas dans le "piège". Si ce n'est pas le cas... alors avant de "coder proprement", il faudrait penser à "apprendre proprement", tu ne crois pas ?

Attention, l'usage d'une expression conditionnelle est tant que lvalue est obsolète :

De nombreux compilateurs acceptent ce genre de construction, notamment des compilateurs spécifiques (pour microcontrolleurs notamment)... De plus, cela reste un "simple" warning, et juste un deprecated qui plus est. Je prends les paris qu'il sera résolu dans 90% des cas en décochant l'affichage du warning en question...
Toutefois, je le re-dis, les imbrications d'opérateurs ternaires (avec ou sans L-values) sont à éviter le plus possible.

Râler sur UN opérateur ternaire en R-Value, c'est ne pas savoir lire un code. Râler sur une imbrication de 3 ou 4 OT, c'est avoir envie d'un code maintenable...

[Philou67430]

Cette écriture a un inconvénient par rapport à l'autre (avec une ligne supplémentaire)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
if (condition) {
  variable = valeur1;
} else {
  variable = valeur2;
}

En effet, le "else", c'est à dire, LE MOT-CLE important du bloc, ne figure par en tête de ligne (comme le if).
Cette règle de construction des blocs telle que je l'ai énoncée est tirée de Perl Best Practices (je n'ai pas son numéro), et les arguments fournis avec me semblent très pertinents.

Concernant l'opérateur d'expression conditionnelle, il est spécifié dans la norme C99 (page 102, renvoi 93) qu'il ne peut fournir une lvalue.
gcc préviens donc qu'un jour où l'autre, cette fonctionnalité sera retirée du compilateur. Il me semble imprudent et non pérenne de continuer à l'utiliser.

[Mac LAK]

En effet, le "else", c'est à dire, LE MOT-CLE important du bloc, ne figure par en tête de ligne (comme le if).
Cette règle de construction des blocs telle que je l'ai énoncée est tirée de Perl Best Practices (je n'ai pas son numéro), et les arguments fournis avec me semblent très pertinents.

Le mot clé important, c'est le "if", pas le "else"...
On peut avoir un "if" sans clause "else", pas le contraire. La notation "} else {" indente justement légèrement le "else" par rapport à son "if", ce qui montre visuellement qu'il est "dans" le bloc du "if".

gcc préviens donc qu'un jour où l'autre, cette fonctionnalité sera retirée du compilateur. Il me semble imprudent et non pérenne de continuer à l'utiliser.

Il existe d'autres compilateurs que GCC, et surtout, d'autres normes que la C99... Pour une simple question de conservation/maintenance de l'existant, et/ou de non-rentabilité d'une évolution, tu ne pourras pas toujours utiliser ce que tu veux comme compilateur, ni comme norme.

Il me semble important de savoir que cette construction EXISTE, même si c'est tout sauf propre et/ou clair, que ce soit mis en deprecated ou pas : cela reste une construction vue relativement souvent dans les codes sources bas niveau, car elle offre l'avantage d'être en général efficace en terme de performances, et c'est encore plus fréquent avec des compilateurs C "bas de gamme" comme on en trouve beaucoup pour les micro-contrôleurs.

Par contre, je te rappelle encore une fois que je déconseillais ce genre de construction dans mon premier post... Même si, par contre, je conseille l'utilisation d'opérateurs ternaires simples en R-Value en lieu et place d'un gros "if ... else" bien plus lourd et pas spécialement plus maintenable.

[Philou67430]

Le mot clé important, c'est le "if", pas le "else"...
On peut avoir un "if" sans clause "else", pas le contraire. La notation "} else {" indente justement légèrement le "else" par rapport à son "if", ce qui montre visuellement qu'il est "dans" le bloc du "if".

"else" est un mot-clé du bloc else, if, le mot-clé du bloc if... chacun est d'égale importance...
D'ailleurs, else, est d'autant plus important qu'il est suivi d'un if, seul cas où il est acceptable de ne pas mettre d'accolade de bloc :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
if (condition1) {
  action1;
}
else if (condition2) {
  action2;
}
else {
  action3;
}

[Mac LAK]

Le mot-clé "else" est conditionné à l'existence d'un "if" quoi qu'il en soit, ce n'est pas une instruction autonome.

L'imbrication de "if ... else" est, par contre, laide au possible (surtout sans indentation !!!), et source d'innombrables erreurs. A proscrire absolument au profit d'un "switch" si possible (penser éventuellement à une fonction de calcul permettant de résumer plusieurs conditions à une seule valeur scalaire type énumération).

Dans le cas où il est impossible de faire autrement, préférer cette écriture :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
if (condition1)
  action1;
else {
  if (condition2)
    action2;
  else {
      if (condition3)
        action3;
      else
        action_default;
  }
}

J'ai supprimé volontairement les accolades que JE juge inutiles, en laissant celles que j'aurais laissé quoi qu'il arrive.
S'il y a trop de code dans les blocs, il y a sûrement un problème de conception et des sous-fonctions devraient être créées.

Éventuellement, avoir un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
int Discriminant ( condition1, condition2, condition3 ) {

  if (condition1)
    return 1 ;
  if (condition2)
    return 2 ;
  if (condition3)
    return 3 ;
  // "default"
  return 0 ;
}

...

  switch (Discriminant(condition1,condition2,condition3)) {
    case 1 : // condition1 réalisée.
      action1 ;
      break ;
    case 2 : // condition2 réalisée.
      action2 ;
      break ;
    case 3 : // condition3 réalisée.
      action3 ;
      break ;
    default : // Aucune condition réalisée.
      action_defaut ;
      break ;
  }

Le seul souci étant si l'évaluation d'une condition génère un appel de fonction pouvant modifier l'état des données... Dans tous les autres cas, c'est bien plus lisible et compréhensible que des "else if" chaînés sur N lignes... Parce que tu as quand même rarement un "action1();" comme seule et unique instruction de tes clauses if / else !!

[Philou67430]

Je ne souhaite faire preuve d'aucun jusque-boutisme, j'ai simplement exposé les arguments en faveur de la présentation des blocs que j'ai exposée... qui n'est d'ailleurs pas ma propre invention, puisque j'ai cité la source dans laquelle cette règle est recommandée.

Je l'ai d'ailleurs indiquée car c'est une règle qui me semble aujourd'hui très peu utilisée (je ne l'ai jamais rencontrée sur des projets sur lesquels j'ai été amené à travailler, sauf ceux que j'ai initiés bien sur), alors que c'est pourtant une alternative qui apporte une lisibilité et une compacité qui me paraissent optimales.

Cela dit, bien sur, il y a bien d'autres règles, d'importance égale ou supérieure, notamment sur le nommage des identifiants, le découpage fonctionnel, la portabilité, ...

[el_slapper]

mais la question ne se limite pas aux bonnes pratiques : le posteur originel se trouve face à 2 problématiques : se retrouver dans son code, puis le refaire propre. Vous avez debattu du second point. Je vais parler du premier. Pour lequel je propose les préconisations suivantes

1) prendre le gros tas illisible, determiner les gros blocs, et les séparer par des commentaires massifs(genre 2 lignes de blancs, 1 ligne d'asterisques, une ligne de titre, une ligne d'astérisques, ets.....) si ça vous défrise, dites-vous que c'est temporaire. Sauvegarder une version à part.

2) identifier les variables, les fonctions, les objets......commenter chaque puis les rennomer. Encore une fois, le commentaire peut être temporaire. Sauvegarder une version à part, tester. En cas de doute, executer le programme en mode trace, pour voir ce que fait réellement la fonction, ce que contient la variable, etc..... le papier et le crayon deviennent alors indispensables. Se fera sans doute en plusieurs itérations. Le code doit déjà être plus digeste, mais ça reste une masse.

3) Dessiner un diagramme du fonctionnement de la bête, si possible en identifiant des "blocs" logiques, et en se servant du point 1. papier crayon, même si on peut s'amuser après à utiliser un logiciel pour préparer la suite. Je trouve le crayon très efficace pour faire remonter les idées jusqu'au cerveau.....

4) Refactoriser, en s'astreignant à garder toujours la même syntaxe. Comme l'a dit Garulfo, mieux vaut un mauvais style identique partout qu'un florilège de bons styles.....Le tout en découpant l'ensemble en suivant le diagramme. En essayant d'éviter les extrêmes.

Les extrêmes, c'est : programme d'un bloc ou hyper-encapsulage.

exemple d'hyperencapsulage :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
sub traitement-echiquier()
   for i = 1 to 8
      call traitement-lignes(i)
   next i
end sub
sub traitement-lignes(i)
   for j = 1 to 8
      call traitement-cases(i,j)
   next j
end sub
sub traitement-cases(i,j)
   if (i + j) mod 2 = 0 then
      call dessin-case(i,j,0) /*case noire*/
   else
      call dessin-case(i,j,1) /*case blanche*/
   end if
end sub

évidemment, si il y avait plein de traitements soécifiques aux lignes, d'autres spécifiques aux cases, ce découpage aurait un sens. Mais là, c'est un tiroir de tiroirs atroce et inutile, et surtout difficille à lire. Difficille à trouver le juste milieu est.

[Zartan]

Je pense que quelles que soient les conventions adoptées, on peut se mettre d'accord sur des règles simples :

- fichiers sources de taille réduite, pour moi l'objectif est 500 lignes, ça va parfois jusqu'à 2000 mais un fichier source de 10000 lignes doit absolument être découpé.

- Au niveau des commentaires on peut distinguer ceux en dehors du code (entêtes de fichiers et de fonctions) qui sont obligatoires et ceux à l'intérieur du code qui à mon avis il faut réserver pour les cas importants.

Notamment les commentaires commençant par FIXME et TODO qui marquent des erreurs à corriger et des améliorations à apporter. En les marquant de la sorte on les retrouve facilement avec une simple recherche dans le code source. Certains outils permettent de les traiter également.

- Idéalement les identificateurs remplacent les commentaires :

Au lieu de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
k = i ; // k sert de stockage temporaire
i = j ;
j = k ;

On peut écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
garage = i ;
i = j ;
j = garage ;

Je recommande également la lecture des ouvrages de Bertrand Meyer qui donne des conseils intéressants.

[souviron34]

je ne peux que recommander la lecture de ces threads ici-même (rubrique "Débats") :

projets informatique : les bonnes pratiques

Qu'est ce qu'un code propre selon vous



Pour infos :

Un code sale est-il un danger pour l'entreprise

faut-il commenter son code source pour le rendre plus lisible et maintenable ?

[Mac LAK]

- fichiers sources de taille réduite, pour moi l'objectif est 500 lignes, ça va parfois jusqu'à 2000 mais un fichier source de 10000 lignes doit absolument être découpé.

Oui, à UNE exception près à ma connaissance : le code généré...

Par contre, 2000 lignes pour certaines classes / modules "velus", ça peut être insuffisant... Et provoquer une hyper-séparation du code est souvent pire que de laisser le code dans un seul fichier, car dans ce cas la maintenance serait plus difficile avec des répercussions sur N fichiers au lieu de "seulement" deux, même "gros".

[Philou67430]

Plutôt que la taille d'un module ou d'une classe, je dirais que c'est plutôt la taille d'une fonction ou d'une méthode qu'il faut limiter, car on travaille rarement sur la totalité du code (on n'est plutôt au niveau de la méthode), et les outils d'édition actuels permettent facilement d'obtenir et de naviguer dans la liste des fonctions/méthodes d'un module, autant pour les appels que pour les définitions.
En fait, il me semblerait néfaste de séparer en deux une classe d'objet "cohérente" pour la seule raison que la taille du source dépasserait une certaine limite, créant ainsi plusieurs classes devant inter-agir entre elles car trop fortement liées. C'est un peu moins vrai en programmation non objet.

[souviron34]

- fichiers sources de taille réduite, pour moi l'objectif est 500 lignes, ça va parfois jusqu'à 2000 mais un fichier source de 10000 lignes doit absolument être découpé.

Vaut-il mieux 80 fichiers de 25 000 lignes chacun portant des noms aisément compréhensibles et une structure claire ou 4000 fichiers de 500 lignes chacun ??


La clarté et facilité de maintenance n'est pas forcément là où on pense...