Coder proprement en général

Bonjour à tous,

Comme une majorité de débutant :bebe:, 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é.:bug:

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!!!

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.

:ccool:

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:

---

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

---

ne fournit aucune information, contrairement à :

Code:

---

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.

Bonjour

Voici quelques règles que j'applique personnellement, ses règles:D 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

Citation:

---

Envoyé par Nakilu

- 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).

Citation:

---

Envoyé par Philou67430

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:

---

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:

---

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:

---

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:

---

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

---

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

Citation:

---

Envoyé par Mac LAK

Code:

---

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:

---

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é).

Citation:

---

Envoyé par Mac LAK

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

Code:

---

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

---

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

---

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

Citation:

---

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

---

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

Code:

---

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... :mrgreen:

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 ? :twisted:

Citation:

---

Envoyé par Philou67430

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... ;)

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

Code:

---

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.

Citation:

---

Envoyé par Philou67430

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".

Citation:

---

Envoyé par Philou67430

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.

Citation:

---

Envoyé par Mac LAK

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:

---

1 2 3 4 5 6 7 8 9

if (condition1) { action1; } else if (condition2) { action2; } else { action3; }

---

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:

---

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:

---

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 !!

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é, ...

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:

---

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.

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:

---

1 2 3 4

k = i ; // k sert de stockage temporaire i = j ; j = k ;

---

On peut écrire :

Code:

---

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.

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 ?

Citation:

---

Envoyé par Zartan

- 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".

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.

Citation:

---

Envoyé par Zartan

- 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é.

---

:mrgreen:

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...

Citation:

---

Envoyé par souviron34

:mrgreen:

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 ??

---

Je dirai qu'il vaudrait mieux 80 répertoires contenant chacun 50 fichiers de 500 lignes :)

C'est un objectif à atteindre, ne serait-ce que pour l'efficacité de la fonction recherche/remplace et d'autres outils.

Citation:

---

Envoyé par souviron34

:mrgreen:

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...

---

+1 au premier jet.

Mais en fait, ma réponse est : "ça dépend". Ca dépend de la pertinence fonctionelle et/ou technique des 4000 sous-bidules. Faut voir aussi qu'il est très compliqué de bosser à 2 sur un seul fichier(ça dépend des systèmes). Quand on bosse en équipe, ça peut être déterminant.

Pour moi, l'erreur et de dire "la longueur dépasse la norme, on coupe!". La bonne démarche, c'est de dire "oulàlà c'est un gros truc, est-ce qu'il n'y aurait pas un moyen de couper tout ça de manière logique et cohérente?". Il est arrivé que la réponse soit "non" pour un monstre de 35000 lignes(parceque tout y était rigoureusement interdépendant), mais la question a été posée, et c'est une bonne chose.

Citation:

---

Envoyé par el_slapper

Pour moi, l'erreur et de dire "la longueur dépasse la norme, on coupe!".

---

J'avais un projet en langage C qui avait des sources de plusieurs milliers de lignes. Ca devenait impossible à maintenir pour une seule personne. Je me suis fait exactement cette réflexion et je l'ai réécrit totalement en C++, divisant à l'occasion la taille du source par deux avec les mêmes fonctionnalités.

Citation:

---

Envoyé par Zartan

J'avais un projet en langage C qui avait des sources de plusieurs milliers de lignes. Ca devenait impossible à maintenir pour une seule personne. Je me suis fait exactement cette réflexion et je l'ai réécrit totalement en C++, divisant à l'occasion la taille du source par deux avec les mêmes fonctionnalités.

---

il est courant dans l'industrie d'avoir des codes de plusieurs centaines de milliers, voire plusieurs millions de lignes..

A 500 lignes par fichier, la complexité introduite est très largement supérieure à un découpage propre de modules de 20000 lignes...

Je te donne un exemple : un code (opérationnel, critique) que j'ai fabriqué, avec interface temps réel, BD répartie, production de films, messages d'alertes, etc etc.. (affichage TR de données météo pour une météo nationale)

Taille : 700 000 lignes
Nombre de répertoires : 7
Nombre de modules par répertoire : environ 25
Taille de chaque module : environ 25 000 lignes.
Nombre de fonctions : 14 000.
Outil interactif ou en mode "script"
Tout les menus et les structures de données sont dynamiques et fonction de ce que rend éventuellement un serveur ou des fichiers de config.

Le découpage est logique et basé sur la fonctionalité : un seul module DrawData, un seul module LoadData, un module par panneau de l'IHM, un module pour gérer les symboles utilisateurs, un pour lire les fichiers cartographiques, un pour le calcul des projections, un pour le maillage 2D, etc etc..

Très facile de savoir dans quel module aller.
Dans chaque entête de module, une liste des fonctions, classées par usage : externes pures, internes et externes, internes pures, sous-regroupées par sous-fonctionalités.


Autre exemple industriel : un logiciel d'apprentissage pour contrôleurs ariens
Taille : 7 millions de lignes
Nombre de répertoires : environ 60
Nombre de modules par répertoire : environ 10
Nombre de fonctions : environ 20 000
Taille de chaque module : environ 10 000 lignes


etc etc..


Déjà qu'il est très complexe de s'y retrouver alors que c'est bien découpé (souvent au minimum un mois ou 2), si tu multiplies le nombre de fichiers par 200, je te dis pas :aie:

Citation:

---

Envoyé par souviron34

A 500 lignes par fichier, la complexité introduite est très largement supérieure à un découpage propre de modules de 20000 lignes...

---

Je ne suis pas d'accord avec cette affirmation. Pour information voici quelques projets célèbres dont la métrique a été calculée, on retrouve approximativement une moyenne de 400 à 500 lignes (de code) par fichier, ce qui est tout à fait raisonnable, étant donné la difficulté intellectuelle que représente la compréhension d'un fichier de 20000 lignes, sans parler des cauchemars que cela représente en termes de gestion de projet.

http://msquaredtechnologies.com/m2rs...ct_metrics.htm

Citation:

---

Envoyé par souviron34

il est courant dans l'industrie d'avoir des codes de plusieurs centaines de milliers, voire plusieurs millions de lignes..

A 500 lignes par fichier, la complexité introduite est très largement supérieure à un découpage propre de modules de 20000 lignes...

Je te donne un exemple : un code (opérationnel, critique) que j'ai fabriqué, avec interface temps réel, BD répartie, production de films, messages d'alertes, etc etc.. (affichage TR de données météo pour une météo nationale)

Taille : 700 000 lignes
Nombre de répertoires : 7
Nombre de modules par répertoire : environ 25
Taille de chaque module : environ 25 000 lignes.
Nombre de fonctions : 14 000.
Outil interactif ou en mode "script"
Tout les menus et les structures de données sont dynamiques et fonction de ce que rend éventuellement un serveur ou des fichiers de config.

Le découpage est logique et basé sur la fonctionalité : un seul module DrawData, un seul module LoadData, un module par panneau de l'IHM, un module pour gérer les symboles utilisateurs, un pour lire les fichiers cartographiques, un pour le calcul des projections, un pour le maillage 2D, etc etc..

Très facile de savoir dans quel module aller.
Dans chaque entête de module, une liste des fonctions, classées par usage : externes pures, internes et externes, internes pures, sous-regroupées par sous-fonctionalités.


Autre exemple industriel : un logiciel d'apprentissage pour contrôleurs ariens
Taille : 7 millions de lignes
Nombre de répertoires : environ 60
Nombre de modules par répertoire : environ 10
Nombre de fonctions : environ 20 000
Taille de chaque module : environ 10 000 lignes


etc etc..


Déjà qu'il est très complexe de s'y retrouver alors que c'est bien découpé (souvent au minimum un mois ou 2), si tu multiplies le nombre de fichiers par 200, je te dis pas :aie:

---

Hmm à voir comme ça le nombre de lignes par fonction augmentent dangereusement avec le nombre de lignes du projet. Ca serait intéressant que tu regardes sur d'autres projets si il y a une vraie corrélation.

Ceci ne contredit pas le fait qu'un découpage correct (au sens de l'architecture logicielle) est plus efficace qu'un découpage forcé (guidé par la taille maximale du fichier). Il indique simplement, qu'en moyenne, les modules/classes sont de tailles raisonnables, ce qui reste bien sur, un objectif en général, mais qui doit rester souple pour le cas d'objets complexes (pour qui un découpage serait un élément supplémentaire de complexité).

Citation:

---

Envoyé par Philou67430

Ceci ne contredit pas le fait qu'un découpage correct (au sens de l'architecture logicielle) est plus efficace qu'un découpage forcé (guidé par la taille maximale du fichier). Il indique simplement, qu'en moyenne, les modules/classes sont de tailles raisonnables, ce qui reste bien sur, un objectif en général, mais qui doit rester souple pour le cas d'objets complexes (pour qui un découpage serait un élément supplémentaire de complexité).

---

Dans le cadre du 2ème projet la moyenne est à 350 lignes par fonction, selon les critères actuels ce n'est pas raisonnable.

Je parlais de taille de module/classe, pas de taille de fonction/méthode.

Citation:

---

Envoyé par Philou67430

Je parlais de taille de module/classe, pas de taille de fonction/méthode.

---

Je suis d'accord sur la flexibilité des tailles modules/classes qui sont forcément liées au fonctionnel et à la logique de l'ensemble.

Citation:

---

Envoyé par Philou67430

Ceci ne contredit pas le fait qu'un découpage correct (au sens de l'architecture logicielle) est plus efficace qu'un découpage forcé (guidé par la taille maximale du fichier). Il indique simplement, qu'en moyenne, les modules/classes sont de tailles raisonnables, ce qui reste bien sur, un objectif en général, mais qui doit rester souple pour le cas d'objets complexes (pour qui un découpage serait un élément supplémentaire de complexité).

---

C'est ce que je veux dire. 25000 lignes, c'est possible si c'est cohérent, mais ça doit rester l'exception. Le nanar de 35000 lignes dont je parle au dessus avait un rôle centralisateur au milieu du batch. 150 chaines en amont(qui toutes produisent le même format commun et standardisé d'enregistrement), 90 chaines en aval(chacune exigeant son propre format), 72 modules accesseurs appelés(avec chacun sa signature), et le tout indécoupable. Mais le reste de l'appli, c'était 2-3 modules à 5000 lignes, et une myriade inférieure à 2000 lignes. Parceque ç'était cohérent comme ça.

Les gens du "métrique" faisaient un caca nerveux tous les 6 mois au sujet de la bête(qui nécéssitait une ressource à plein temps pour sa maintenance, dont j'étais le back-up à plein temps quand il n'était pas là), alors on a chercher tous les moyens de la découper. En vain. Car il était nécéssaire de garantir un traitement standardisé de tous les flux entrants.

Mais oui, tout ce qu'on peut découper proprement, il faut le faire, au vu des couts engendrés par le seul monstre sur lequel on a pas pu le faire(250 jours de maintenance annuelle).....Juste, exiger une découpe, ça ne fonctionne pas, de même que toute règle trop rigide.

Citation:

---

Envoyé par Zartan

étant donné la difficulté intellectuelle que représente la compréhension d'un fichier de 20000 lignes, sans parler des cauchemars que cela représente en termes de gestion de projet.

---

Eh bien encore une fois :

• Primo le "cauchemar" l'est beaucoup moins pour gérer 400 fichiers que 4000 ou 12000.
  
  
• Secondo, la difficulté intellectuelle pour comprendre un fichier de 20 000 lignes bien construit est bien moindre que celle nécessitée par la compréhension de 6000 fichiers mal construits....

N'importe quelle personne ayant travaillé sur des gros softs te le dira...

Citation:

---

Envoyé par Furikawari

Hmm à voir comme ça le nombre de lignes par fonction augmentent dangereusement avec le nombre de lignes du projet. Ca serait intéressant que tu regardes sur d'autres projets si il y a une vraie corrélation.

---

Oui il y en a une : c'est même publié (je crois que j'avais inclus le schéma dans un des débats sur ce forum), je crois dans Scientific American : la courbe est exponentielle en volume, en points de fonctions, en durée, et en budget (et en taux d'annulation).

Cependant, tous les très gros projets sont très complexes .

Et les "normes" , comme par exemple à la NASA avec 50 lignes max par fonction, et une fonction par fichier, ne rendent pas la maintenance plus facile : 3000 ingénieurs à temps plein, un budget plus gros que celui de la France, environ 800 000 fichiers à gérer, c'est pas forcément mieux.... et à la portée de toutes les bourses...

Citation:

---

Envoyé par Furikawari

Dans le cadre du 2ème projet la moyenne est à 350 lignes par fonction, selon les critères actuels ce n'est pas raisonnable.

---

Encore une fois le "critère" (je me répète par raport à l'autre débat) est que cela soit compréhensible.

Ces critères "absolus" sont une absurdité en soi.

D'autant plus si les fonctions sont dans des fichiers différents. Jongler entre des dizaines de fichiers pour établir l'organigramme d'une fonctionalité est bien plus casse-tête (pour ne pas dire emm.rdant) que suivre un fil sur 300 lignes consécutives..

Je prend date, et vous donne rdv dans 20 ans, quand vous aurez eu (peut-être) à reprendre de vrais gros codes construits aujourdhui avec ces règles...


En conclusion : toute norme absolue est stupide dans notre domaine...

Comme pour tout, le bon sens est la règle qui devrait prédominer...

• Sur un petit projet, pas de problèmes.
• Sur un gros, tout dépend de l'architecture fonctionnelle, des objets manipulés, de la durée de vie, du langage utilisé (une des raisons pour lesquelles j'ai une très mauvaise expérience du C++ en très gros projet industriel (celui des contrôles aériens cité ci-dessus) : les "factories" sont une étape de complexité supplémentaire, qui n'ont aucun lien avec la fonctionalité, et rendent la compréhension d'un code source encore plus difficile), du futur qu'on attend de cette application..

Citation:

---

Envoyé par souviron34

Eh bien encore une fois :

• Primo le "cauchemar" l'est beaucoup moins pour gérer 400 fichiers que 4000 ou 12000.
  
  
• Secondo, la difficulté intellectuelle pour comprendre un fichier de 20 000 lignes bien construit est bien moindre que celle nécessitée par la compréhension de 6000 fichiers mal construits....

N'importe quelle personne ayant travaillé sur des gros softs te le dira...




Oui il y en a une : c'est même publié (je crois que j'avais inclus le schéma dans un des débats sur ce forum), je crois dans Scientific American : la courbe est exponentielle en volume, en points de fonctions, en durée, et en budget (et en taux d'annulation).

Cependant, tous les très gros projets sont très complexes .

Et les "normes" , comme par exemple à la NASA avec 50 lignes max par fonction, et une fonction par fichier, ne rendent pas la maintenance plus facile : 3000 ingénieurs à temps plein, un budget plus gros que celui de la France, environ 800 000 fichiers à gérer, c'est pas forcément mieux.... et à la portée de toutes les bourses...





Encore une fois le "critère" (je me répète par raport à l'autre débat) est que cela soit compréhensible.

Ces critères "absolus" sont une absurdité en soi.

D'autant plus si les fonctions sont dans des fichiers différents. Jongler entre des dizaines de fichiers pour établir l'organigramme d'une fonctionalité est bien plus casse-tête (pour ne pas dire emm.rdant) que suivre un fil sur 300 lignes consécutives..

Je prend date, et vous donne rdv dans 20 ans, quand vous aurez eu (peut-être) à reprendre de vrais gros codes construits aujourdhui avec ces règles...


En conclusion : toute norme absolue est stupide dans notre domaine...

Comme pour tout, le bon sens est la règle qui devrait prédominer...

• Sur un petit projet, pas de problèmes.
• Sur un gros, tout dépend de l'architecture fonctionnelle, des objets manipulés, de la durée de vie, du langage utilisé (une des raisons pour lesquelles j'ai une très mauvaise expérience du C++ en très gros projet industriel (celui des contrôles aériens cité ci-dessus) : les "factories" sont une étape de complexité supplémentaire, qui n'ont aucun lien avec la fonctionalité, et rendent la compréhension d'un code source encore plus difficile), du futur qu'on attend de cette application..

---

J'ai déjà eu à travailler sur un gros code (plus d'un million de ligne pour la partie C++ qui ne représentaient pas du tout la totalité de l'appli).

Autant sur la taille des modules je suis d'accord, autant sur la taille des fonctions/méthodes je ne le suis pas. 99,99% des traitements sont "atomisables" ce qui simplifie la maintenance. Mais bon, probablement que tous ceux qui tiennent le même type de raisonnement depuis maintenant plus de 10 ans ont torts ? Même s'il y a une fonction critique que tu ne peux pas diviser (je demande à voir) ce n'est pas ça qui fait exploser la moyenne LoC par méthodes. Les critères absolus sont peut être idiots mais une moyenne sur 7millions de LoC ça commence à donner des infos...

Dans les méthodologies de développement pour logiciels critiques (DO178 pour l'avionique par exemple), il existe des règles de codage, de conception, ...
Il est toujours possible de violer ces règles, dans la mesure où :
- on justifie cette violation
- on trace l'ensemble des conformités/non conformités

Citation:

---

Envoyé par souviron34

Eh bien encore une fois :

• Primo le "cauchemar" l'est beaucoup moins pour gérer 400 fichiers que 4000 ou 12000.
  
  
• Secondo, la difficulté intellectuelle pour comprendre un fichier de 20 000 lignes bien construit est bien moindre que celle nécessitée par la compréhension de 6000 fichiers mal construits....

N'importe quelle personne ayant travaillé sur des gros softs te le dira...

---

C'est là où on ne se comprend pas. Je parle des gros projets avec 200 ou plus intervenants dessus. Même avec des systèmes modernes de version 80 fichiers de 20 000 lignes n'est pas tenable.

Dès qu'un développeur s'approprie un fichier pour travailler dessus, il devra soit le verrouiller et donc avoir 199 développeurs travailler sur autre chose (mais il ne reste que 79 fichiers), soit prendre une copie du fichier et faire un merge des différences. Et un diff sur 20 000 lignes avec un nombre inconnu de développeurs ayant travaillé dessus c'est invivable car des télescopages sont inévitables.

Avec les outils modernes, une structure en répertoires n'offre que des avantages, les EDI de nos jours font des recherche/remplace sur l'ensemble du projet et non un seul fichier.

J'ai travaillé personnellement (et modestement) sur le GCC et c'était parfaitement bien organisé.
Et je n'ai absolument pas eu à ingérer l'ensemble du projet, je me suis uniquement occupé de repérer où se trouvait le fichier que je cherchais pour le modifier, lequel ne faisait qu'une dizaine de lignes.

L'utilisation de fichiers de 20 000 lignes se défend uniquement pour un petit groupe de programmeurs.

D'autre part la POO amène la logique : une classe pour un fichier, c'est un découpage naturel qui me convient parfaitement, 500 lignes étant pour moi un objectif à atteindre plus qu'une règle gravée dans le marbre.

Citation:

---

Envoyé par Zartan

C'est là où on ne se comprend pas. Je parle des gros projets avec 200 ou plus intervenants dessus. Même avec des systèmes modernes de version 80 fichiers de 20 000 lignes n'est pas tenable.

Dès qu'un développeur s'approprie un fichier pour travailler dessus, il devra soit le verrouiller et donc avoir 199 développeurs travailler sur autre chose (mais il ne reste que 79 fichiers), soit prendre une copie du fichier et faire un merge des différences. Et un diff sur 20 000 lignes avec un nombre inconnu de développeurs ayant travaillé dessus c'est invivable car des télescopages sont inévitables.

Avec les outils modernes, une structure en répertoires n'offre que des avantages, les EDI de nos jours font des recherche/remplace sur l'ensemble du projet et non un seul fichier.

---

Pour quelqu'un qui cite "les outils modernes", je crois que là tu ne sais pas de quoi tu parles....

que ce soit cvs, svn, ou Rational ou autres outils du même acabit, tous ces outils te permettent de travailler à 200 sur le même fichier si tu en as envie, avec des merges automatiques et détection de conflit (et résolution personelle ou après discussion) avant rentrée finale... :P

Citation:

---

Envoyé par Zartan

D'autre part la POO amène la logique : une classe pour un fichier, c'est un découpage naturel qui me convient parfaitement, 500 lignes étant pour moi un objectif à atteindre plus qu'une règle gravée dans le marbre.

---

:mouarf:
je ris.. Eternel argument des défendeurs inconditionnels de la POO... 8-)


Comme nous en avons maintes fois débattu, il n'y a rien de plus logique et naturel dans la POO que dans le procédural..

Pour citer Garulfo dans un autre débat : "la POO se concentre sur les objets, le procédural sur la fonctionalité" :

Je suis scientifique à la base, une architecture et un découpage fonctionnel me sont tout à fait naturels et logiques.

Tu es informaticien ayant eu des cours de POO : elle te semble naturelle et logique.

Les 2 sont équivalents, et il n'y a pas de "panacée", juste des préférences de pensée.. de formation, ou de mode..


Quant au nombre de classes, cela peut-être carrément insupportable si le découpage a été mal fait ou l'héritage mal conçu..

Citation:

---

Envoyé par souviron34

[*]Primo le "cauchemar" l'est beaucoup moins pour gérer 400 fichiers que 4000 ou 12000.

---

C'est autant populaire ou cela t'es une difficulté personnelle ? Parce qu'au final on pourrait avoir le même nombre de ligne de code donc chercher une punaise (ou une aiguille) dans 4000tonnes de foin c'est moins cauchemardesque que de la chercher dans 400 ?

Citation:

---

[*]Secondo, la difficulté intellectuelle pour comprendre un fichier de 20 000 lignes bien construit est bien moindre que celle nécessitée par la compréhension de 6000 fichiers mal construits....

---

Tu exagéres car dans ta comparaison chaque fichier n'aurait que 2-3 lignes de code, tu insultes l'intelligence des développeurs pas bien.

Citation:

---

N'importe quelle personne ayant travaillé sur des gros softs te le dira...

---

Ok. Attendons alors qu'ils répondent...Sinon des références de personne qui disent cela publiquement (dans un livre par exemple ou un blog)

Citation:

---

D'autant plus si les fonctions sont dans des fichiers différents. Jongler entre des dizaines de fichiers pour établir l'organigramme d'une fonctionalité est bien plus casse-tête (pour ne pas dire emm.rdant) que suivre un fil sur 300 lignes consécutives..

---

Bizar pour quelqu'un orienté extréme documentation d'imaginer qu'on ne puisse documenter l'organisation logique par groupe de fonctionnalité les fichiers source d'un projet.

Citation:

---

Comme pour tout, le bon sens est la règle qui devrait prédominer...

---

+10000

Citation:

---

Envoyé par souviron34

que ce soit cvs, svn, ou Rational ou autres outils du même acabit, tous ces outils te permettent de travailler à 200 sur le même fichier si tu en as envie, avec des merges automatiques et détection de conflit (et résolution personelle ou après discussion) avant rentrée finale... :P

---

Le nombre de collisions reste toutefois dépendant de l'architecture. Et si on peut travailler en solo sur un fichier c'est beaucoup mieux, comme ça pas de merge à effectuer.

Citation:

---

Envoyé par hegros

C'est autant populaire ou cela t'es une difficulté personnelle ? Parce qu'au final on pourrait avoir le même nombre de ligne de code donc chercher une punaise (ou une aiguille) dans 4000tonnes de foin c'est moins cauchemardesque que de la chercher dans 400 ?

---

;)

C'est vrai, mais de l'autre côté quand tu as énormément de fichiers, juste passer à travers les noms (sur une quantité > 1000 ou 2000) est "mind buggling" : ta mémoire ne retenant que 7 (chiffre officiel académique) choses court terme, ça va être dur..

Si c'est une organisation par fonctionalité, tu t'y retrouve plus vite (pourvu que les fichiers soient bien nommés).

Citation:

---

Envoyé par hegros

Tu exagéres car dans ta comparaison chaque fichier n'aurait que 2-3 lignes de code, tu insultes l'intelligence des développeurs pas bien.

---

Je n'ai pas fait de divisions mathématiques. C'était un ordre de grandeur...

Mais puisque tu l'as fait, cela veut dire 300 fichiers quand même.. Contre un..

Et donc si ton soft fait 80 fois 1 fichier de 20 000 lignes, tu te retrouves avec.... 24 000 fichiers !!!! :calim2:

Citation:

---

Envoyé par hegros

Ok. Attendons alors qu'ils répondent...Sinon des références de personne qui disent cela publiquement (dans un livre par exemple ou un blog)

---

Attendons effectivement...

Mais c'est de la pure pratique : sais-tu tous les fichiers pris en compte par l'OS Windows ? ou tous les fichiers de la JDK (60 000 au bas mot) ??

Citation:

---

Envoyé par hegros

Bizar pour quelqu'un orienté extréme documentation d'imaginer qu'on ne puisse documenter l'organisation logique par groupe de fonctionnalité les fichiers source d'un projet.

---

je ne parlais pas de moi mais d'exemples vécus de codes que j'ai vu ..

Comme je mentionnais à propos des classes.. Supposons un outil manipulant 85 classes différentes d'objets..

Suivant l'architecture des répertoires, si c'est orienté classes, tu peux avoir 85 répertoire, ou 85 modules, avec dans chacun une méthode Display par exemple.

Ce qui veut dire que si tu veux suivre ce qui se passe quand l'écran est raffraîchi, il te faut 85 fichiers ouverts, et passer de l'un à l'autre en fonction de l'objet affiché..

Citation:

---

Envoyé par Zartan

Le nombre de collisions reste toutefois dépendant de l'architecture. Et si on peut travailler en solo sur un fichier c'est beaucoup mieux, comme ça pas de merge à effectuer.

---

Sauf que dans justement les grosses équipes (que tu sembles citer par ailleurs), cela n'est quasiment jamais le cas... :P

Citation:

---

Envoyé par souviron34

;)

C'est vrai, mais de l'autre côté quand tu as énormément de fichiers, juste passer à travers les noms (sur une quantité > 1000 ou 2000) est "mind buggling" : ta mémoire ne retenant que 7 (chiffre officiel académique) choses court terme, ça va être dur..

---

:calim2: C'est quoi encore ce truc du chapeau qui sort de l'académie. On utilise des outils non qui intégre des interfaces et fonctions de recherche soit avec les mots qu'il faut on peut très bien avoir une gridtable avec 7 noms de fichiers.

Citation:

---

Si c'est une organisation par fonctionalité, tu t'y retrouve plus vite (pourvu que les fichiers soient bien nommés).

---

Référence ? Source ? Stat ?

Citation:

---

Je n'ai pas fait de divisions mathématiques. C'était un ordre de grandeur...

Mais puisque tu l'as fait, cela veut dire 300 fichiers quand même.. Contre un..

Et donc si ton soft fait 80 fois 1 fichier de 20 000 lignes, tu te retrouves avec.... 24 000 fichiers !!!! :calim2:

---

20000 lignes de code dans un fichier ou plus ne me choque pas tout dépend jusqu'à quel point nous pouvons le relire x fois avec facilité et rapidité.

Citation:

---

Mais c'est de la pure pratique : sais-tu tous les fichiers pris en compte par l'OS Windows ? ou tous les fichiers de la JDK (60 000 au bas mot) ??

---

Oui et alors ?

Citation:

---

je ne parlais pas de moi mais d'exemples vécus de codes que j'ai vu ..

Comme je mentionnais à propos des classes.. Supposons un outil manipulant 85 classes différentes d'objets..

Suivant l'architecture des répertoires, si c'est orienté classes, tu peux avoir 85 répertoire, ou 85 modules, avec dans chacun une méthode Display par exemple.

Ce qui veut dire que si tu veux suivre ce qui se passe quand l'écran est raffraîchi, il te faut 85 fichiers ouverts, et passer de l'un à l'autre en fonction de l'objet affiché..

---

Beh non tu lis la documentation technique qui raconte toutes ces histoires de classe et de méthode. Mince y'a jamais de doc tu vas me dire mais je ne pense pas que c'est la raison qui te pousse à cette pratique