Discussion :

[RT222]

Bonjour,

Je suis actuellement en train de développer un moteur 3D basique en C++. N'ayant jamais attaqué un projet de cette taille (et ayant apprit à coder pas très proprement car j'étudie à Epitech et suis obligé de me taper leur norme idiote :/), j'essaye de faire ça le plus proprement possible, mais mes maigres connaissances en la matière me font me poser plein de questions. Voici les principales :

1) Une classe par .h/.cpp, c'est ce que j'applique. Est ce que je mérite de me faire lapider pour ça, ou est ce propre et standard?

2) Que pensez vous des long long int? Peuvent-ils poser des problèmes de compatibilité à l'exécution du programme dans certains environnements, ou n'est ce juste que certains compilateurs qui ont du mal avec? Peuvent-ils être utilisés proprement ou sont-ils à bannir de nos programmes?

3)Pour stocker les différentes données de mon programme, j'utilise une arborescence à base de structure et de classes. Cette arborescence est accessible par un pointeur unique sur une structure et donne donc accès à la totalité des données du programme (non encapsulée dans les classes bien entendu).
Je la donne en exemple pour que ça soit plus clair :

Code :

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

1
2
3
4
5
6
7
8
9
 
struct     mainData
{
int         drawParamsMask;
VideoParams *videoParams;
Mesh        *Models;
Map         *Materials;
...ect
};

Bon, en réalité, elle est bien plus complexe, mais je la simplifie pour l'exemple. Donc à partir de ça, je me demandais si il était une bonne idée de rendre le pointeur sur la structure mainData global (non pas taper! ), car à mon sens cela permet de disposer de tous les avantages d'une globale tout en limitant les inconvénients qu'elles causent : seul un pointeur de 4octet sera global, ce qui n'est pas très lourd à faire passer aux fonctions et limite donc la perte de perfs, mais j'aurais pourtant accès à toutes les données de mon programme partout et à tout moment. Bon, j'imagine que je dois me tromper et qu'en fait c'est crade comme il faut, mais j'aimerais en être certain et en avoir l'explication le cas échéant. (Pour ma défense, je n'ai jamais utilisé de globales jusqu'à maintenant et les ais toujours fuies comme la peste, non je dis ça parce que je tiens à mon image quand même )

Voilà, c'est tout pour le moment, mais c'est déjà beaucoup je le sais, et c'est pour ça que je dis un grand merci (en avance) à ceux qui auront lu mon message ainsi qu'à ceux qui pourront éclairer ma lanterne en y répondant.

[Flob90]

1/ Pas nécessairement, l'important c'est que le fichier ne contienne pas tout et n'importe quoi, mais si, par exemple, tu as une classe qui est un complement d'un autre, il n'est pas nécessaire des les éclater, tu peux très bien les mettre ensemble.

Regardes les headers de bibliothèques connues (comme boost), tu verras qu'ils ne mettent pas toujours une seule classe par header (http://www.boost.org/doc/libs/1_45_0...c/headers.html par exemple)

2/ C'est standard, mais il est possible que certains compilo ne les prenne pas en compte ...

3/ En c++, struct == class, la différence tient dans l'accessibilité et l'héritage par défaut (privé pour class et publique pour struct).

Pour la suite de la question, plutôt que de plagier je te renvoy à cet article : http://blog.emmanueldeloget.com/inde...ables-globales je ne pense pas que ta variable global respecte ces 3 points

[Emmanuel Deloget]

Bonjour,

Je suis actuellement en train de développer un moteur 3D basique en C++. N'ayant jamais attaqué un projet de cette taille (et ayant apprit à coder pas très proprement car j'étudie à Epitech et suis obligé de me taper leur norme idiote :/), j'essaye de faire ça le plus proprement possible, mais mes maigres connaissances en la matière me font me poser plein de questions. Voici les principales :

La norme d'Epitech n'est pas idiote, crois moi. Et puis Nicolas ne serait pas content d'entendre ça Ca ne veut pas dire que c'est la norme de toutes les normes. C'est juste la norme Epit{a,tech}.

1) Une classe par .h/.cpp, c'est ce que j'applique. Est ce que je mérite de me faire lapider pour ça, ou est ce propre et standard?

C'est tout à fait propre.

2) Que pensez vous des long long int? Peuvent-ils poser des problèmes de compatibilité à l'exécution du programme dans certains environnements, ou n'est ce juste que certains compilateurs qui ont du mal avec? Peuvent-ils être utilisés proprement ou sont-ils à bannir de nos programmes?

Le long long int n'a pas d'existence en C++. Pas avant la normalisation finale de C++0x.

3)Pour stocker les différentes données de mon programme, j'utilise une arborescence à base de structure et de classes. Cette arborescence est accessible par un pointeur unique sur une structure et donne donc accès à la totalité des données du programme (non encapsulée dans les classes bien entendu).

Ah ? Et pourquoi ?

Je la donne en exemple pour que ça soit plus clair :

Code :

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

1
2
3
4
5
6
7
8
9
 
struct     mainData
{
int         drawParamsMask;
VideoParams *videoParams;
Mesh        *Models;
Map         *Materials;
...ect
};

Bon, en réalité, elle est bien plus complexe, mais je la simplifie pour l'exemple. Donc à partir de ça, je me demandais si il était une bonne idée de rendre le pointeur sur la structure mainData global (non pas taper! ), car à mon sens cela permet de disposer de tous les avantages d'une globale tout en limitant les inconvénients qu'elles causent : seul un pointeur de 4octet sera global, ce qui n'est pas très lourd à faire passer aux fonctions et limite donc la perte de perfs, mais j'aurais pourtant accès à toutes les données de mon programme partout et à tout moment. Bon, j'imagine que je dois me tromper et qu'en fait c'est crade comme il faut, mais j'aimerais en être certain et en avoir l'explication le cas échéant. (Pour ma défense, je n'ai jamais utilisé de globales jusqu'à maintenant et les ais toujours fuies comme la peste, non je dis ça parce que je tiens à mon image quand même )

C'est très sale, je confirme. Ce n'est pas une question de perf (damned, tu ne sais même pas si ton pointeur va être passé dans un registre ou sur la pile !). Il ne s'agit pas d'avoir 4 octets ou 8 ou 12 ou même 4 MB en global (ce qui n'a pas de sens), mais des symboles accessibles partout. C'est ça qui est sale, parce que ça veut dire que ton code ne sera pas réentrant, et qu'il ne sera pas protégé en cas d'utilisation concurentielle des informations (dans des threads). Et ça démontre un gros problème d'architecture. Les globales n'offrent pas d'avantage - elles ont principalement des inconvénients.

Vu que tu n'est pas clair sur le sujet, je te conseille amicalement mais fermement de ne jamais utiliser de globale dans ton code. Tu pourras en utiliser à partir du moment ou tu auras une compréhension complète des raisons pour lesquelles tu ne dois pas le faire. Je sais, c'est paradoxal.

[RT222]

La norme d'Epitech n'est pas idiote, crois moi. Et puis Nicolas ne serait pas content d'entendre ça Ca ne veut pas dire que c'est la norme de toutes les normes. C'est juste la norme Epit{a,tech}.

Je suis d'accord pour dire qu'elle est bien conçue pour les nouveaux élèves qui, arrivés en piscine, ont tendance à coder des put_nbr de 6 fonctions de plus de 20 lignes. Elle pousse à l'économie de code et donc indirectement d'opérations effectuées, ce qui n'est pas un mal. Mais autant ceci vaut pour les débutants, autant lorsque l'on commence à acquérir un minimum de compétences et que l'on attaque des projets plus consistants, cette norme est une plaie à suivre, particulièrement la limite absolue de 25 lignes par fonctions.

Pourquoi 25 lignes piles? Je sais que le découpage fonctionnel est très important dans un programme, seulement imposé comme ça, c'est juste une plaie et ça rend plus sale les codes, d'autant plus que pas mal de raccourcis sont interdits : déclaration de plusieurs variables de même type sur une seule ligne, initialisation de ces variables lors de leur déclaration... Combien de fois j'ai été obligé de tricher à mort sur une fonction, en utilisant des raccourcis d'écriture très peu clair à lire, mais plus courts à écrire, pour tenir à tout prix cette limite et éviter ainsi un découpage inutile? Pourquoi suis je obligé bien souvent de morceler des fonctions, alors que leur action était linéaire et ne nécessitait absolument pas de découpage?

Je ne suis pas convaincu non plus par l'interdiction totale (et non expliquée d'ailleurs des for et des switch (et pourquoi les ternaires sont-ils autorisés eux?). Ne pas les employer n'est pas en soi un problème, là où ça gêne à mon sens, c'est qu'ils sont utilisés dans de très nombreux programmes et que leur non connaissance peut gêner à la compréhension de codes en dehors d'Epitech (bien que cette lacune soit comblée en quelques minutes, mais bon...). L'école prend aussi le parti de nous décourager à utiliser les commentaires, alors que j'ai toujours lu que bien commenter son code est capital.

Et pour finir, les globales sont autorisées dans la norme (qui se contente de les déconseiller). J'ai bien sûr un très grand respect pour Nicolas Sadirac, et j'admire ce qu'il a fait et ce qu'il est capable de faire, mais cela ne m'empêche pas de pester contre la norme d'Epitech (qu'il n'a sans doute pas écrite lui même d'ailleurs) que je trouve, pour les raisons citées ci-dessus, fort mal conçue (bien qu'elle ait certaines qualités, je ne le nie pas non plus).

Ceci dit, il s'agit là d'un avis de débutant, et peut être ais-je tort de penser ainsi, mais cette norme m'a pour le moment tellement posée de problèmes que je ne peux m'empêcher de lui vouer une certaine haine.

3)Pour stocker les différentes données de mon programme, j'utilise une arborescence à base de structure et de classes. Cette arborescence est accessible par un pointeur unique sur une structure et donne donc accès à la totalité des données du programme (non encapsulée dans les classes bien entendu).

Ah ? Et pourquoi ?

Oh non, ne me dis pas qu'il ne faut pas faire comme ça, j'adore procéder ainsi. Je précise que je n'y met pas tout bien entendu, l'idée n'est en aucun cas de ne plus avoir de variables locales aux fonctions (ce qui serait très moche je le sais ). Par donnée, j'entends tout ce qui a un rapport avec la configuration du programme et les objets qui y ont été chargés.

Voici la véritable structure que j'utilise, ça sera plus clair. C'est encore en chantier donc il manque plein de trucs, je précise :

Main_Structure_Data.h

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
 
#pragma once
 
namespace		mdt
{
 
	struct		videoParams
	{
		short int		screenWidthMax;
		short int		screenWidth;
		short int		screenHeightMax;
		short int		screenHeight;
		short int		refreshRateMax;
		short int		refreshRate;
		short int		fpsMax;
	};
 
	// Déclarations anticipées
	class		Mesh;
	class		DiffuseMap;
	class		SpecularMap;
	class		NormalMap;
	class		OcclusionMap;
	class		EnvironMap;
	class		Skeleton;
	class		Animation;
	class		Camera;
 
 
	struct	MainData
	{
		videoParams		*videoParams;
		Mesh			*models;
		DiffuseMap		*diffusesMaps;
		SpecularMap		*specularsMaps;
		NormalMap		*normalsMaps;
		OcclusionMap		*OcclusionsMaps;
		EnvironMap		*EnvironnementalsMaps;
		Skeleton		*skeletons;
		Animation		*animations
		Camera			*cameras;
		int			drawParams; // masque de bit, voir définitions dans 3D_Draw.h
	};
 
}

Je trouvais cette manière de procéder très pratique et efficace car, ayant besoin de stocker et parfois de faire transiter un grand nombre de paramètres entre les fonctions (bon pas en l'état actuel, mais ça va venir), tout était rassemblé en un seul et unique pointeur qu'il me suffit de passer à une fonction pour avoir accès à toutes les données. En plus d'être pratique, il me semblait que c'était plus léger que de passer des tonnes de paramètres en entrée. En prime, cela me permet d'avoir facilement accès à l'intégralité des données de mon programme (paramètres et contenu), et de pouvoir plus facilement suivre sa configuration et tout ce qui a été chargé en mémoire. Enfin c'est ce que je croyais, si j'ai tort, je serais ravi de le savoir. Loin de moi l'idée de vouloir coder salement.

3/ En c++, struct == class, la différence tient dans l'accessibilité et l'héritage par défaut (privé pour class et publique pour struct).

Pour la suite de la question, plutôt que de plagier je te renvoy à cet article : http://blog.emmanueldeloget.com/inde...ables-globales je ne pense pas que ta variable global respecte ces 3 points

Merci pour le lien, très intéressant à lire. Ma structure respecte clairement le premier point, puisqu'elle est créée au démarrage du programme, et détruite uniquement à sa sortie. Je ne sais pas si elle respecte le deuxième point, sachant que même si son contenu change, la structure vers laquelle pointe le pointeur, ainsi que le pointeur lui même restent les mêmes du début à la fin. Quant au troisième point, effectivement il ne me semble pas du tout respecté. ^^

C'est très sale, je confirme. Ce n'est pas une question de perf (damned, tu ne sais même pas si ton pointeur va être passé dans un registre ou sur la pile !). Il ne s'agit pas d'avoir 4 octets ou 8 ou 12 ou même 4 MB en global (ce qui n'a pas de sens), mais des symboles accessibles partout. C'est ça qui est sale, parce que ça veut dire que ton code ne sera pas réentrant, et qu'il ne sera pas protégé en cas d'utilisation concurentielle des informations (dans des threads). Et ça démontre un gros problème d'architecture. Les globales n'offrent pas d'avantage - elles ont principalement des inconvénients.

Vu que tu n'est pas clair sur le sujet, je te conseille amicalement mais fermement de ne jamais utiliser de globale dans ton code. Tu pourras en utiliser à partir du moment ou tu auras une compréhension complète des raisons pour lesquelles tu ne dois pas le faire. Je sais, c'est paradoxal.

Ok ok, je me rends et suivrais donc ton conseil avisé. Point de globales dans mon programme.


Un grand merci à vous deux, vous m'avez grandement aidé.

[koala01]

Salut, et bienvenue sur le forum

Je suis d'accord pour dire qu'elle est bien conçue pour les nouveaux élèves qui, arrivés en piscine, ont tendance à coder des put_nbr de 6 fonctions de plus de 20 lignes. Elle pousse à l'économie de code et donc indirectement d'opérations effectuées, ce qui n'est pas un mal. Mais autant ceci vaut pour les débutants, autant lorsque l'on commence à acquérir un minimum de compétences et que l'on attaque des projets plus consistants, cette norme est une plaie à suivre, particulièrement la limite absolue de 25 lignes par fonctions.

Pourquoi 25 lignes piles?

A mon avis, c'est essentiellement historique:

A l'époque où windows et son système de fenêtrage n'était encore qu'un doux rêve, les moniteurs affichaient... 25 lignes de 80 colonnes.

La limite des 80 colonnes et des 25 lignes permettait donc de s'assurer:

• qu' il n'y aurait pas de passage à la ligne pour afficher une ligne unique de code
• que l'ensemble de la fonction serait affichable à l'écran, sans risquer de voir les premières lignes "mangées" par le manque de place.

D'ailleurs, on croise aussi souvent des conseils qui préconisent de se limiter à 50 lignes (2* la hauteur de l'écran)... Mais c'est tout autant arbitraire, et cela commence à faire des fonctions pour le moins importantes

Je sais que le découpage fonctionnel est très important

Oh que oui, c'est vachement important... peut être même plus que ce que tu ne pourrais le croire pour l'instant

dans un programme, seulement imposé comme ça, c'est juste une plaie et ça rend plus sale les codes, d'autant plus que pas mal de raccourcis sont interdits : déclaration de plusieurs variables de même type sur une seule ligne, initialisation de ces variables lors de leur déclaration... Combien de fois j'ai été obligé de tricher à mort sur une fonction, en utilisant des raccourcis d'écriture très peu clair à lire, mais plus courts à écrire, pour tenir à tout prix cette limite et éviter ainsi un découpage inutile? Pourquoi suis je obligé bien souvent de morceler des fonctions, alors que leur action était linéaire et ne nécessitait absolument pas de découpage?

Peut être en demandais tu simplement trop à tes fonctions

Il est vraiment rare que j'atteigne les 25 lignes dans une fonction, même en déclarant chaque variable dans une ligne...

Mais ce qui importe surtout, c'est d'essayer de suivre le principe de la responsabilité unique: chaque fonction ne devrait faire qu'une seule chose, mais devrait la faire correctement

Je ne suis pas convaincu non plus par l'interdiction totale (et non expliquée d'ailleurs des for et des switch (et pourquoi les ternaires sont-ils autorisés eux?).

Ca, par contre, cela me semble effectivement aberrant...

Ne pas les employer n'est pas en soi un problème, là où ça gêne à mon sens, c'est qu'ils sont utilisés dans de très nombreux programmes et que leur non connaissance peut gêner à la compréhension de codes en dehors d'Epitech (bien que cette lacune soit comblée en quelques minutes, mais bon...).

Tout à fait... la connaissance des boucles (de tous les types de boucles) et des tests (de tous les types de tests) reste quand même la base de la programmation structurée...

L'école prend aussi le parti de nous décourager à utiliser les commentaires, alors que j'ai toujours lu que bien commenter son code est capital.

Il y a à boire et à manger sur ce point:

Un code correctement écrit ne devrait, en effet, pas nécessiter de commentaires.

Par contre, il est vrai qu'un commentaire utile est souvent appréciable. Encore faut il qu'il soit effectivement utile, et qu'il ne vienne pas rajouter une couche sur ce que le code permet de comprendre.

Un commentaire proche de

Code :

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

i++; // on ajoute un à i

n'a en effet aucun intérêt, mais si un commentaire mets les invariants en évidence ou précise la logique qui est suivie (ou du moins qui doit etre suivie) par le code présente malgré tout un intérêt majeur

Et pour finir, les globales sont autorisées dans la norme (qui se contente de les déconseiller).

En fait, c'est le cas à peu près partout:

On peut te donner une quantité inimaginable d'arguments contre les variables globales, mais tu restes malgré tout seul maître de ton code, et il peut toujours arriver un moment où... une variable globale sera la "moins mauvaise solution".

Mais Emmanuel a bien raison de dire qu'il est préférable d'attendre de savoir pourquoi tu dois t'en priver avant de décider de les utiliser

J'ai bien sûr un très grand respect pour Nicolas Sadirac, et j'admire ce qu'il a fait et ce qu'il est capable de faire, mais cela ne m'empêche pas de pester contre la norme d'Epitech (qu'il n'a sans doute pas écrite lui même d'ailleurs) que je trouve, pour les raisons citées ci-dessus, fort mal conçue (bien qu'elle ait certaines qualités, je ne le nie pas non plus).

Le problème de ce genre de "norme" est qu'elles sont rarement mises à jour, et ne prennent donc que rarement l'évolution de l'état de l'art en compte.

Et, comme on oublie régulièrement de préciser l'année où elles ont été mises au point, on en arrive régulièrement à remarquer que certaines règles sont en désaccord total avec ce que l'état de l'art nous conseille

Ceci dit, il s'agit là d'un avis de débutant, et peut être ais-je tort de penser ainsi, mais cette norme m'a pour le moment tellement posée de problèmes que je ne peux m'empêcher de lui vouer une certaine haine.

On peut le comprendre, mais il faut te dire que les "règles de codage", pour bizarres ou perfectibles qu'elles puissent paraitre, sont malgré tout indispensables pour s'assurer la cohérence du code dans un projet d'importance.

Oh non, ne me dis pas qu'il ne faut pas faire comme ça, j'adore procéder ainsi. Je précise que je n'y met pas tout bien entendu, l'idée n'est en aucun cas de ne plus avoir de variables locales aux fonctions (ce qui serait très moche je le sais ). Par donnée, j'entends tout ce qui a un rapport avec la configuration du programme et les objets qui y ont été chargés.

Mais pourquoi ne pas utiliser une variable classique et veiller à ce qu'elle soit accessible par les objets qui en ont réellement besoin

La liste des objets qui en ont besoin de doit, malgré tout, pas être *si* importante que cela

Voici la véritable structure que j'utilise, ça sera plus clair. C'est encore en chantier donc il manque plein de trucs, je précise :

Main_Structure_Data.h

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
 
#pragma once
 
namespace		mdt
{
 
	struct		videoParams
	{
		short int		screenWidthMax;
		short int		screenWidth;
		short int		screenHeightMax;
		short int		screenHeight;
		short int		refreshRateMax;
		short int		refreshRate;
		short int		fpsMax;
	};
 
	// Déclarations anticipées
	class		Mesh;
	class		DiffuseMap;
	class		SpecularMap;
	class		NormalMap;
	class		OcclusionMap;
	class		EnvironMap;
	class		Skeleton;
	class		Animation;
	class		Camera;
 
 
	struct	MainData
	{
		videoParams		*videoParams;
		Mesh			*models;
		DiffuseMap		*diffusesMaps;
		SpecularMap		*specularsMaps;
		NormalMap		*normalsMaps;
		OcclusionMap		*OcclusionsMaps;
		EnvironMap		*EnvironnementalsMaps;
		Skeleton		*skeletons;
		Animation		*animations
		Camera			*cameras;
		int			drawParams; // masque de bit, voir définitions dans 3D_Draw.h
	};
 
}

Alors, réfléchissons un peu...:

VideoParams est un ensemble de données qui n'est réellement intéressant que pour la partie "affichage" de ton programme (on pourrait d'ailleurs en dire sans doute autant pour camera (dont j'imagine qu'elle permet de sélectionner le type de vue), et d'animations).

Les autres données de MainData semblent essentiellement nécessaires à la partie "métier", même s'il parait évident qu'il sera nécessaire de les passer à la partie affichage

Je trouvais cette manière de procéder très pratique et efficace car, ayant besoin de stocker et parfois de faire transiter un grand nombre de paramètres entre les fonctions (bon pas en l'état actuel, mais ça va venir), tout était rassemblé en un seul et unique pointeur qu'il me suffit de passer à une fonction pour avoir accès à toutes les données. En plus d'être pratique, il me semblait que c'était plus léger que de passer des tonnes de paramètres en entrée. En prime, cela me permet d'avoir facilement accès à l'intégralité des données de mon programme (paramètres et contenu), et de pouvoir plus facilement suivre sa configuration et tout ce qui a été chargé en mémoire. Enfin c'est ce que je croyais, si j'ai tort, je serais ravi de le savoir. Loin de moi l'idée de vouloir coder salement.

Tu dois, encore une fois, veiller à respecter au mieux la règle de la responsabilité unique.

Il est, surement, possible de regrouper certaines de ces données dans des structures / classes clairement déterminées, mais il faut, malgré tout veiller à ne pas transmettre trop de choses inutiles

De plus, si tu code en C++, tu devrais surtout t'intéresser aux services que tu attends de la part de tes objets. Ils te permettront fatalement de déterminer quelles données seront nécessaires pour leur permettre de rendre le service attendu

Merci pour le lien, très intéressant à lire. Ma structure respecte clairement le premier point, puisqu'elle est créée au démarrage du programme, et détruite uniquement à sa sortie.

Mais alors, pourquoi la déclarer en variable globale, et non comme une variable locale à la fonction main

Je ne sais pas si elle respecte le deuxième point, sachant que même si son contenu change, la structure vers laquelle pointe le pointeur, ainsi que le pointeur lui même restent les mêmes du début à la fin.

c'est le problème des variables globales: n'importe quoi peut y accéder depuis n'importe où et en faire n'importe quoi...

Si tu crées ta variable de type MainData ne serait-ce que dans la fonction main (et que tu en fais donc bel et bien une variable locale) (à défaut de revoir l'ensemble de l'analyse), les seules fonctions qui pourront accéder à tout ou partie de son contenu seront celles... auxquelles tu transmettra les informations sous la forme de paramètres

Ok ok, je me rends et suivrais donc ton conseil avisé. Point de globales dans mon programme.

voila une sage décision

[RT222]

Salut, et bienvenue sur le forum

Merci.

A l'époque où windows et son système de fenêtrage n'était encore qu'un doux rêve, les moniteurs affichaient... 25 lignes de 80 colonnes.

Aaaahhh, d'accord. Ce sont justement les limites exactes imposées par la norme d'Epitech. Je suis content car j'en connais la raison maintenant et me coucherais moins bête. ^^

Pour le reste de la norme, je suis content de voir que je n'ai pas dit que des bêtises et n'ai donc pas complètement tort en pestant contre. Mais je reste bien conscient que je n'ai pas complètement raison non plus, la faute à mon manque d'expérience dans le domaine. Il faut que je garde en tête que la norme ne me veut pas que du mal.

Peut être en demandais tu simplement trop à tes fonctions

Il est vraiment rare que j'atteigne les 25 lignes dans une fonction, même en déclarant chaque variable dans une ligne...

Mais ce qui importe surtout, c'est d'essayer de suivre le principe de la responsabilité unique: chaque fonction ne devrait faire qu'une seule chose, mais devrait la faire correctement

Tu dois, encore une fois, veiller à respecter au mieux la règle de la responsabilité unique.

Il est, surement, possible de regrouper certaines de ces données dans des structures / classes clairement déterminées, mais il faut, malgré tout veiller à ne pas transmettre trop de choses inutiles

De plus, si tu code en C++, tu devrais surtout t'intéresser aux services que tu attends de la part de tes objets. Ils te permettront fatalement de déterminer quelles données seront nécessaires pour leur permettre de rendre le service attendu

Je crois avoir compris quelque chose de très important grâce à toi. J'avais apparemment mal interprété le principe de la généricité, et toujours eu tendance à vouloir faire des fonctions polyvalentes, ce qui est bien différent. Je vais donc m'atteler à corriger ce problème et donc à revoir en bonne partie la structure de mon code actuelle (pas de soucis, je n'en suis qu'à la partie design pour le moment, ça ne sera donc pas trop dur). Pour commencer plus de MainData, je commence enfin à me rendre compte en quoi son utilisation est absurde, d'autant plus que j'ai plein d'autres moyens de passer mes données aux fonctions qui en ont besoin de manière claire, aisée, et sans rien surcharger. Responsabilité unique... je ne l'oublierais pas.


Un grand merci pour cette réponse de très grande qualité qui m'amène à revoir les choses sous un nouvel angle. J'étais perdu avant de venir ici, et même si je le reste quand même pas mal, je pense enfin avancer dans le bon sens. Et ça, c'est motivant.

[koala01]

Aaaahhh, d'accord. Ce sont justement les limites exactes imposées par la norme d'Epitech. Je suis content car j'en connais la raison maintenant et me coucherais moins bête. ^^

A l'époque, ce genre de limite avait une raison d'être... Certains langages imposaient d'ailleurs la limite des 80 colonnes de manière structurelle (le COBOL par exemple )

Mais, maintenant, ces limites sont souvent gardées "par habitude" plus qu'autre chose

Pour le reste de la norme, je suis content de voir que je n'ai pas dit que des bêtises et n'ai donc pas complètement tort en pestant contre. Mais je reste bien conscient que je n'ai pas complètement raison non plus, la faute à mon manque d'expérience dans le domaine. Il faut que je garde en tête que la norme ne me veut pas que du mal.

Au contraire, elle ne te veut que du bien et tend à te faciliter au mieux l'écriture et, surtout, la relecture de ton code.

N'oublie pas qu'un code est lu / analysé beaucoup plus souvent qu'il n'est écrit

Je crois avoir compris quelque chose de très important grâce à toi. J'avais apparemment mal interprété le principe de la généricité, et toujours eu tendance à vouloir faire des fonctions polyvalentes, ce qui est bien différent. Je vais donc m'atteler à corriger ce problème et donc à revoir en bonne partie la structure de mon code actuelle (pas de soucis, je n'en suis qu'à la partie design pour le moment, ça ne sera donc pas trop dur). Pour commencer plus de MainData, je commence enfin à me rendre compte en quoi son utilisation est absurde, d'autant plus que j'ai plein d'autres moyens de passer mes données aux fonctions qui en ont besoin de manière claire, aisée, et sans rien surcharger. Responsabilité unique... je ne l'oublierais pas.

Ce qui importe quand tu détermine ce que fait une fonction, c'est de te rappeler qu'elle agit comme une "entité indivisible" qui, bien qu'elle puisse s'arrêter si certaines conditions ne sont pas respectées, s'exécutera dans son intégralité lorsque l'on rentre dedans.

Tu dois donc veiller à ce que la logique qui la compose n'ait qu'un but unique

A titre d'exemple, on pourrait dire que la fonction main vaut souvent la peine d'être limitée à quelque chose comme

Code :

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

1
2
3
4
5
6
7
int main()
{
    type val = initialize();
    run(&val);
    finalize(&val);
    return 0;
}

ou, si tu travaille en Orienté objet, tu auras sans doute un ou plusieurs objets qui "chapeautent le tout", et elle prendrait alors une forme proche de

Code :

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

1
2
3
4
5
6
7
8
 
int main()
{
    Type_1 obj; // RAII inside: initialisation de l'objet à la création
    Type_2 obj2(&obj); //idem
     obj.run();
    return 0;
} // La destruction des objets libère les ressources

chaque fonction (ou constructeur dans le deuxième cas) appelant un certain nombre de fonctions (éventuellement de constructeurs d'autres types) effectuant une partie bien déterminée de la tâche en cours

Un grand merci pour cette réponse de très grande qualité

De rien

qui m'amène à revoir les choses sous un nouvel angle. J'étais perdu avant de venir ici, et même si je le reste quand même pas mal, je pense enfin avancer dans le bon sens. Et ça, c'est motivant.

c'était le but

[Emmanuel Deloget]

Merci.
Aaaahhh, d'accord. Ce sont justement les limites exactes imposées par la norme d'Epitech. Je suis content car j'en connais la raison maintenant et me coucherais moins bête. ^^

Étonnamment, ces limites continuent d'avoir du sens.

Pour la limite à 25 lignes, c'est relativement simple d'en saisir la portée : elle oblige à rendre son code modulaire et à penser correctement le découpage en fonction. Pour un maximum de lisibilité, il faut trouver un bon équilibre entre longueur maximale de fonction et nombre de fonctions. S'il ne sert à rien d'avoir 100,000 fonctions d'une ligne, avoir 10,000 fonctions de 10 lignes sera certainement plus gérable que d'avoir 100 fonctions de 1000 lignes. La complexité du code (calculée par une métrique genre McCabe) sera aussi nettement affectée par cette limite - pour le plus grand bonheur du relecteur.

La limite à 80 caractères par ligne peut sembler étrange vu nos écrans : un IDE classique va te permettre d'afficher entre 140 et 200 caractères par lignes, donc pourquoi se limiter à 80 ?

Et bien, d'une part, pour faciliter la lecture. Une ligne longue est souvent complexe à lire - il y a plein de paramètres, plein de choses à comprendre, etc.

D'autre part, et ceux qui programment dans le monde du libre vont comprendre tout de suite, il est quelque fois nécessaire de partager le code suivant des moyens moins classiques qu'un simple envoi de fichier vers un serveur SVN. On peut le coller dans des forums, ou envoyer une fonction par mail ou par news (est-ce que c'est encore un moyen de communication utilisé à Epit{a,ech} ?). Hors, ces moyens de partage du code sont souvent beaucoup plus limités que votre EDI : le mail va couper le code à 72 ou 80 caractères (idem pour les news), et la boite "code" du forum n'est guère avantageuse à ce niveau. Du coup, s'assurer que la longueur de chaque ligne ne va pas faire qu'elle sera découpée avec une violence extrême conserve un intérêt à ce niveau.

Si on prends les projets open source emblématique, on voit que la taille maximale des lignes est bien souvent aux alentours de 80 caractères - pour ces raisons (le code open source étant souvent partagé sur des mailing lists, sous forme de snippets ou de patchs).

Nicolas n'est pas bête du tout - même si bien souvent, il n'explique pas les raisons qui motivent ces décisions (le mieux que tu pourras entendre de lui, c'est "cherche". Ce qui n'est pas forcément plus mal).

[koala01]

Dans la même veine que les problème de mail / ML / forums, nous pourrions également citer celui de l'impression papier.

A titre d'exemple, j'imprime énormément de choses en quatre pages sur une feuille A4 (deux pages recto, deux page verso), ce qui, tu t'en doute, limite fortement la place que l'on peut donner à ce qui est imprimé, et diminue fatalement la taille de la police utilisée .

Selon la taille de la police (à chasse fixe, pour du code ) utilisée, on peut tabler sur 80 à 120 caractères, avec une marge de 2 cm...

Mais il faut quand même veiller à ce que cela reste lisible, et si on divise l'espace disponible par deux comme je le fais régulièrement

[JolyLoic]

Des ces exemples de règles de codage, seul un point me gêne vraiment : l'interdiction de l'"initialisation de ces variables lors de leur déclaration".

Et un point me surprend : L'interdiction de for et switch.

Le reste me semble très raisonnable, surtout dans un contexte d'apprentissage (et 25 lignes par fonction, c'est plutôt beaucoup).

Finalement, un autre point me gêne : Pour moi, une telle norme (en entreprise et en école) n'a d'intérêt que si ses utilisateurs y adhérent. Et une telle adhésion ne peut pas s'y faire par la voie hiérarchique uniquement, mais aussi par une dose de pédagogie. Et j'ai l'impression que les motivations des points de cette norme manquent (Lire par exemple http://www2.research.att.com/~bs/JSF-AV-rules.pdf, où les rationale sont aussi importants que les règles).

[RT222]

Ce qui importe quand tu détermine ce que fait une fonction, c'est de te rappeler qu'elle agit comme une "entité indivisible" qui, bien qu'elle puisse s'arrêter si certaines conditions ne sont pas respectées, s'exécutera dans son intégralité lorsque l'on rentre dedans.

Tu dois donc veiller à ce que la logique qui la compose n'ait qu'un but unique

C'est promis, je grave ça dans mon crâne et vais tâcher de le respecter au maximum à partir de maintenant. J'ai d'ailleurs commencé dès aujourd'hui et j'en ressens déjà les bienfaits.

On peut le coller dans des forums, ou envoyer une fonction par mail ou par news (est-ce que c'est encore un moyen de communication utilisé à Epit{a,ech} ?).

En fait je suis à Epitech Montpellier, et c'est un peu différent de Paris (on a nos propre PC portables et non des PC fixes publiques comme à Paris). Dans le cas d'Epitech Montpellier donc, on utilise deux solutions pour faire passer du code : soit via nos mails persos lorsque l'on est chez soi, soit via un petit logiciel nommé sendsoul sous FreeBSD. Dans les deux cas on envoie en général les fichiers de code directement, donc pas de problèmes pour la largeur des lignes. Mais après vos explications détaillées, je comprends l'importance d'imposer une limite de ce côté là, limite à laquelle je ferais attention même en dehors d'Epitech dorénavant.

Nicolas n'est pas bête du tout - même si bien souvent, il n'explique pas les raisons qui motivent ces décisions (le mieux que tu pourras entendre de lui, c'est "cherche". Ce qui n'est pas forcément plus mal).

Encore une fois, j'ai beaucoup de respect et même de l'admiration pour lui. Et je ne dis pas ça pour ne pas me faire virer hein? C'est parfaitement sincère. Loin de moi l'idée de le critiquer lorsque je parle de la norme.

Le "cherche" est effectivement au coeur de la philosophie de l'école, et bien que je sois d'accord pour dire qu'il s'agit d'une bonne chose, je soupçonne certains Azteks (étudiants d'années supérieures chargés d'aider les nouveaux) d'en abuser afin de pouvoir continuer tranquillement leur partie de carte dans le BDE.

Des ces exemples de règles de codage, seul un point me gêne vraiment : l'interdiction de l'"initialisation de ces variables lors de leur déclaration".

Et un point me surprend : L'interdiction de for et switch.

Et pourtant c'est bien ce que spécifie la norme noir sur blanc, d'ailleurs la voici telle qu'elle nous est livrée par l'école :
http://www.epitech.eu/intra/docs/norme.html

Finalement, un autre point me gêne : Pour moi, une telle norme (en entreprise et en école) n'a d'intérêt que si ses utilisateurs y adhérent. Et une telle adhésion ne peut pas s'y faire par la voie hiérarchique uniquement, mais aussi par une dose de pédagogie. Et j'ai l'impression que les motivations des points de cette norme manquent (Lire par exemple http://www2.research.att.com/~bs/JSF-AV-rules.pdf, où les rationale sont aussi importants que les règles).

Je suis d'accord, et malheureusement à Epitech, on se contente de nous dire "tu respecte la norme si tu ne veux pas avoir -42, un point c'est tout". J'ai déjà tenté de demander à des Azteks, et même à notre professeur si je me souviens bien, mais jamais je n'ai jamais pu obtenir d'explication réelle. Ceci dit, notre professeur ayant changé récemment, il faudra que je retente ma chance parce que je suis quand même très curieux de savoir pourquoi on nous prive de certaines fonctions élémentaire du C/C++.

[koala01]

Il est vrai que, lorsque des règles de codage (je préfère quand même ce terme à celui de "norme" ) sont trop arbitraires, il est difficile d'y adhérer entièrement.

Et l'on a beau essayer de chercher, il est parfois difficile d'en trouver une raison claire et "indiscutable" sans s'adresser directement à celui qui en a décidé, ce qui rend encore plus difficile le fait d'y adhérer.

Cependant, certaines règles sont justifiables, ne serait-ce que de manière historique (cf: les restrictions en terme de lignes et de colonnes), d'autres sont compréhensibles (le fait de séparer chaque "mot" d'un nom par un underscore: c'est la règle utilisée dans la STL , ou le fait d'imposer une indentation (de deux caractères, en plus) avant l'accolade ouvrante), même si on peut leur en opposer d'autres, tout aussi compréhensibles (et tout aussi discutables )

Enfin, il y a des règles qui trouvent difficilement de justification, à moins de s'adresser directement à celui qui les a édictées (exemple: ne pas utiliser de swich ou de for).

[gl]

Des ces exemples de règles de codage, seul un point me gêne vraiment : l'interdiction de l'"initialisation de ces variables lors de leur déclaration".

Et un point me surprend : L'interdiction de for et switch.

Finalement, un autre point me gêne : Pour moi, une telle norme (en entreprise et en école) n'a d'intérêt que si ses utilisateurs y adhérent. Et une telle adhésion ne peut pas s'y faire par la voie hiérarchique uniquement, mais aussi par une dose de pédagogie. Et j'ai l'impression que les motivations des points de cette norme manquent (Lire par exemple http://www2.research.att.com/~bs/JSF-AV-rules.pdf, où les rationale sont aussi importants que les règles).

Sur ces points, je te rejoins totalement (notamment sur l'importance des rationale qui sont malheureusement très rarement présents).

Le reste me semble très raisonnable, surtout dans un contexte d'apprentissage (et 25 lignes par fonction, c'est plutôt beaucoup).

Là par contre j'ai plus de mal. Pourquoi 25 ? Est-ce que à la 26ème ligne la fonction devient soudainement illisible ?
Ca ne me gène absolument pas de préconiser une taille maximale (surtout de 25 lignes qui est assez cohérente et confortable) mais je ne suis pas franchement d'accord pour l'imposer de manière stricte. Personnellement je préfère insister sur le SRP et autres principes conduisant naturellement à des fonctions courtes (et qui respecteront dans leur grande majorité cette limite de 25 lignes même non-imposée) mais surtout simple (je préfère, et de très loin, une fonction de 30 lignes qui ne fait qu'une seule chose de manière lisible à une fonction de 20 ayant deux rôles et des hacks immondes pour la faire passer sous la limite).

Après dans un contexte d'apprentissage, ça me choque beaucoup moins. Mais je reste assez dubitatif sur son intérêt éducatif (combien d'élèves vont comprendre le but recherché ? combien vont simplement essayer de trouver des écritures tordues pour passer sous la limite à tout prix ?).

[koala01]

Sur ces points, je te rejoins totalement (notamment sur l'importance des rationale qui sont malheureusement très rarement présents).



Là par contre j'ai plus de mal. Pourquoi 25 ? Est-ce que à la 26ème ligne la fonction devient soudainement illisible ?

C'est le problème des limites arbitraires: on peut toujours en discuter la cohérence.

Cependant, il faut avouer que la règle des 25 lignes est, historiquement, cohérente

Ca ne me gène absolument pas de préconiser une taille maximale (surtout de 25 lignes qui est assez cohérente et confortable) mais je ne suis pas franchement d'accord pour l'imposer de manière stricte.

Le problème, c'est que si tu préconise un nombre maximal ( et arbitraire!!!)de ligne à "éviter de dépasser", il devient d'autant plus difficile de justifier le fait que, de manière arbitraire, une fonction de 30 lignes est encore jugée "suffisamment courte", mais qu'une fonction de 40 ou de 50 est "exagérément longue"

Personnellement je préfère insister sur le SRP et autres principes conduisant naturellement à des fonctions courtes (et qui respecteront dans leur grande majorité cette limite de 25 lignes même non-imposée)

Effectivement, Mais l'explication de SRP (et autres principes occasionnant un résultat similaire) devrait se trouver dans les abstracts.

Cela justifierait "naturellement" la pose des limites arbitraires, même si on les laisses plus ou moins flottantes (ou du moins, nous pourrions écrire "En respecant SRP, vous ne devriez que rarement dépasser 25 lignes )

mais surtout simple (je préfère, et de très loin, une fonction de 30 lignes qui ne fait qu'une seule chose de manière lisible à une fonction de 20 ayant deux rôles et des hacks immondes pour la faire passer sous la limite).

Là dessus, on est bien d'accord

Et je reconnais volontiers que dire "maximum 25 lignes et, si vous vous demandez pourquoi, vous n'avez qu'à chercher" a peu de chances d'amener la personne qui lit cette règle à s'intéresser à SRP

Après dans un contexte d'apprentissage, ça me choque beaucoup moins.

Pour autant que ce soit correctement justifié, effectivement...

D'ailleurs, je dois reconnaitre que j'essaye malgré toutau niveau professionnel de rester en dessous de cette limite, même si je l'applique de manière flottante

Mais je reste assez dubitatif sur son intérêt éducatif (combien d'élèves vont comprendre le but recherché ? combien vont simplement essayer de trouver des écritures tordues pour passer sous la limite à tout prix ?).

Sans la justification qui va bien, c'est effectivement le risque.

Ce que je reproche le plus aux règles de codages imposées ici, c'est qu'elles ne justifient absolument aucune règle, ce qui les fait passer pour arbitraires, et donc susceptibles d'être discutées, ou d'inciter effectivement les étudiants à recourir à un tas de sucres syntaxiques afin de les respecter

[gl]

C'est le problème des limites arbitraires: on peut toujours en discuter la cohérence.

Non, ça va au delà du simple côté arbitraire. Typiquement une règle qui dit que l'on utilise 4 espaces pour indenter (alors que 3 ou 5 ne sont pas fondamentalement de plus mauvais choix, ni de meilleur non plus) ou que l'on utilise telle ou telle politique de nommage, ou d'une manière générale toute règle arbitraire cherchant à uniformiser la présentation au sein d'un projet ne me pose aucun problème.

Dans le cas du nombre de ligne (et je ferais le même reproche au nombre de méthode par classe, au nombre de paramètres par fonction, etc.), ce qui me gène est un cumul de points:

• Leur côté arbitraire certes, mais aussi,
• Leur justification discutable (la justification historique n'a plus vraiment de raison d'être. Concernant le respect du SRP, le respect ne me semble pas être le bon - pourquoi ne pas compter plutôt le nombre de responsabilité -).
• J'ai rencontré trop de code où le respect inconditionnel de cette règle posait plus de problèmes qu'il n'en résout (en particulier en terme de lisibilité) pour vraiment croire en l'utilité d'une telle règle.

Le problème, c'est que si tu préconise un nombre maximal ( et arbitraire!!!)de ligne à "éviter de dépasser", il devient d'autant plus difficile de justifier le fait que, de manière arbitraire, une fonction de 30 lignes est encore jugée "suffisamment courte", mais qu'une fonction de 40 ou de 50 est "exagérément longue"

A ce sujet, j'ai rencontré une norme de codage qui différenciait clairement les règles des recommandations, ce que je trouve être une bonne idée.

Cela justifierait "naturellement" la pose des limites arbitraires, même si on les laisses plus ou moins flottantes (ou du moins, nous pourrions écrire "En respecant SRP, vous ne devriez que rarement dépasser 25 lignes ) Là dessus, on est bien d'accord

Si tu poses une limite plus ou moins flottante, tu donnes bel et bien une recommandation et non un règle stricte. Ce qui n'est ni plus ni moins le point de vue que j'expose (dans mon esprit, peut être à tort, une recommandation n'est pas juste un truc dont on se contrefout, mais bien un point que l'on doit respecter dans la mesure du possible mais que l'on peut ignorer lorsqu'il y a une bonne raison de le faire).

[Jean-Marc.Bourguet]

Le long long int n'a pas d'existence en C++. Pas avant la normalisation finale de C++0x.

Tandis qu'export existe jusqu'a la normalisation finale de C++0X. Le respect des normes, c'est bien, mais c'est un moyen pas un objectif. Si l'objectif n'est pas atteignable en respectant la norme ou s'il l'est sans la respecter, il vaut peut-etre mieux en tenir compte.

Salut, et bienvenue sur le forumA mon avis, c'est essentiellement historique:

A l'époque où windows et son système de fenêtrage n'était encore qu'un doux rêve, les moniteurs affichaient... 25 lignes de 80 colonnes.

Pour completer la minute historique..

Et moi qui croyait que les 80 colonnes venaient des cartes perforees, les ecrans n'etant qu'un intermediaire. (Je sais il y a eu d'autres formats de cartes perforees que celles a 80 colonnes, meme en restant chez IBM.)

En passant, les 72 colonnes datent aussi de cette epoque et j'ai comme l'impression que les commentaires de FORTRAN commencant a la 72ieme colonnes ne sont a nouveau qu'un intermediaire (j'ai le vague souvenir d'une mention d'un equipement capable de lire uniquement les 72 premieres colonnes; 72 caracteres, ca se met sur 12 mots de 36 bits avec les jeux 6 bits en usage a l'epoque -- oui le FORTRAN a ete developpe sur une machine 36 bits).

Toujours en passant, le VT100 a introduit les terminaux pouvant afficher 132 colonnes (nombre traditionnel de caracteres imprimables sur une ligne sur du papier large, je n'ai aucune idee d'ou ca vient).

Quant au 25 lignes, les terminaux en affichaient generalement 24. 25 lignes, c'est plus recent, c'est le mode texte des PC.

(Qui est capable de remonter aux Romains? :-) )

La limite à 80 caractères par ligne peut sembler étrange vu nos écrans : un IDE classique va te permettre d'afficher entre 140 et 200 caractères par lignes, donc pourquoi se limiter à 80 ?

Afficher du code cote a cote me sert plus que les envois par email ou l'impression.

Et bien, d'une part, pour faciliter la lecture. Une ligne longue est souvent complexe à lire - il y a plein de paramètres, plein de choses à comprendre, etc.

+1

Nicolas n'est pas bête du tout - même si bien souvent, il n'explique pas les raisons qui motivent ces décisions (le mieux que tu pourras entendre de lui, c'est "cherche". Ce qui n'est pas forcément plus mal).

C'est pas plus mal tant qu'on verifie le resultat de la recherche...

Des ces exemples de règles de codage, seul un point me gêne vraiment : l'interdiction de l'"initialisation de ces variables lors de leur déclaration".

On ne peut meme pas avoir des constructeurs par defaut qui font des initialisations, sans parler de ne pas avoir de constructeur par defaut? :-)

Ca ressemble a l'importation d'une regle pour C concue pour eviter des C99ismes importee en C++ sans avoir ete remise en cause.

Et un point me surprend : L'interdiction de for et switch.

Et ceci ressemble a une regle pour un exercice de style (note que je suis pour ce genre d'exercices de style dans des contextes d'apprentissage -- bien que l'absence de for...).

Finalement, un autre point me gêne : Pour moi, une telle norme (en entreprise et en école) n'a d'intérêt que si ses utilisateurs y adhérent. Et une telle adhésion ne peut pas s'y faire par la voie hiérarchique uniquement, mais aussi par une dose de pédagogie. Et j'ai l'impression que les motivations des points de cette norme manquent (Lire par exemple http://www2.research.att.com/~bs/JSF-AV-rules.pdf, où les rationale sont aussi importants que les règles).

Il faut connaitre la motivation parce qu'il y a des moments ou le respect de la regle va a l'encontre des motivations. Un switch qui fait plus de 25 lignes ne me gene a priori pas du tout.

Mais je ne suis pas sur que je fais confiance a priori a quelqu'un qui sort de l'ecole (sans parler de quelqu'un qui y est encore) pour savoir quand il vaut mieux s'affranchir de la regle. (Certains en sont capables, mais la majorite n'est meme pas capable de se rendre compte qu'elle en est incapable)

Les conventions de codage doivent aussi etre relativement courtes et la notion de court depend du contexte. Un document de 140 pages est court dans le cadre d'un projet militaire avec beaucoup de formalisme, la pertinence d'une telle taille decroit pour les projets industriels/commerciaux (un document plus court laissant plus de place au jugement sera probablement plus efficace) et est nulle pour des projets scolaire (ici un document encore plus court et sans laisser de place au jugement est justifiable).

[JolyLoic]

On ne peut meme pas avoir des constructeurs par defaut qui font des initialisations, sans parler de ne pas avoir de constructeur par defaut? :-)

Ca ressemble a l'importation d'une regle pour C concue pour eviter des C99ismes importee en C++ sans avoir ete remise en cause.

Au début, je pensais plus à une règle mal comprise par l'étudiant qui voulait dire autre chose, mais finalement, en lisant la norme elle même, je suis d'accord qu'il s'agit plus de règles de codage en C...

Et ceci ressemble a une regle pour un exercice de style (note que je suis pour ce genre d'exercices de style dans des contextes d'apprentissage -- bien que l'absence de for...).

Moi de même, mais je vois mal l'intérêt de l'exercice de style dans ce cas, sauf pour un exercice spécifique.

Il faut connaitre la motivation parce qu'il y a des moments ou le respect de la regle va a l'encontre des motivations. Un switch qui fait plus de 25 lignes ne me gene a priori pas du tout.

Moi non plus, si chaque case est monoligne ou presque.

Là par contre j'ai plus de mal. Pourquoi 25 ?

Parce que c'est le plus petit nombre de Friedman en base 10, et que c'est un membre du premier triplet pytagoricien.

Est-ce que à la 26ème ligne la fonction devient soudainement illisible ?
Ca ne me gène absolument pas de préconiser une taille maximale (surtout de 25 lignes qui est assez cohérente et confortable) mais je ne suis pas franchement d'accord pour l'imposer de manière stricte.

Dans un contexte d'apprentissage, une règle stricte ne me gêne pas plus que ça.

Personnellement je préfère insister sur le SRP et autres principes conduisant naturellement à des fonctions courtes (et qui respecteront dans leur grande majorité cette limite de 25 lignes même non-imposée) mais surtout simple (je préfère, et de très loin, une fonction de 30 lignes qui ne fait qu'une seule chose de manière lisible à une fonction de 20 ayant deux rôles et des hacks immondes pour la faire passer sous la limite).

Si elle utilise des hacks pour faire moins de 25 lignes, ce n'est effectivement pas bon. C'est pire que de ne pas respecter la limite.
Par contre, un nombre de ligne a un avantage par rapport au SRP : C'est facilement vérifiable par un outil.

Après dans un contexte d'apprentissage, ça me choque beaucoup moins. Mais je reste assez dubitatif sur son intérêt éducatif (combien d'élèves vont comprendre le but recherché ? combien vont simplement essayer de trouver des écritures tordues pour passer sous la limite à tout prix ?).

Après, c'est le rôle des explications qui viennent en même temps que la règle.

[Luc Hermitte]

Finalement, un autre point me gêne : Pour moi, une telle norme (en entreprise et en école) n'a d'intérêt que si ses utilisateurs y adhérent. Et une telle adhésion ne peut pas s'y faire par la voie hiérarchique uniquement, mais aussi par une dose de pédagogie. Et j'ai l'impression que les motivations des points de cette norme manquent (Lire par exemple http://www2.research.att.com/~bs/JSF-AV-rules.pdf, où les rationale sont aussi importants que les règles).

Je suis d'accord avec toi.
Mais j'ai plutôt l'impression que quand elles sont connues (ce qui est déjà presque bien), les utilisateurs (et pire, les enforceurs) se contentent de lire les titres des règles. (ou comment on se retrouve avec du SESE partout alors que les dérogations sont pourtant claires dans les règles de codage)
Bon, il faut dire que le document de règles que j'ai corrigé est monté à plus de 100 pages grâce aux rationale. Ca n'aide pas à pousser à la lecture.

Là par contre j'ai plus de mal. Pourquoi 25 ? Est-ce que à la 26ème ligne la fonction devient soudainement illisible ?
Ca ne me gène absolument pas de préconiser une taille maximale (surtout de 25 lignes qui est assez cohérente et confortable) mais je ne suis pas franchement d'accord pour l'imposer de manière stricte. Personnellement je préfère insister sur le SRP et autres principes conduisant naturellement à des fonctions courtes

J'avais également insisté sur le SRP et autres "faible-couplage / haute-cohésion". J'avais même sorti la phrase de Linus, je crois, qui est de mémoire: "If you have more than three indentation levels, you're screwed anyway".
Seulement, comme le dit Loic, pour les métriciens il faut des nombres! Je m'entends encore dire "les règles il faut des outils pour les contrôler".

[Emmanuel Deloget]

Histoire d'être complet, pour ce qui est de la règle EPITA/EPITECH, il s'agit de faciliter le travail de relecture du code fait par les différents profs et assistants. Les projets ne sont pas notés que sur le résultat, mais aussi sur la qualité du code écrit - et sur sa lisibilité.

Je pense que c'est un point important pour comprendre les règles décrites dans cette norme de programmation.

Pour autant que je m'en souvienne, l'interdiction des boucles for a pour but de bien faire comprendre qu'il s'agit de sucre syntaxique - toutes les boucles peuvent être écrites avec while () { } ou do { } while (), qui sont les formes préférées. Pour ce qui est des switch, leur interdiction est due (si ma mémoire est bonne) au fait qu'ils sont régulièrement abusés (trop de case) et dangereux (oubli du break), tout en étant relativement peu utile car n'intervenant que sur des types intégraux. Dans de très nombreux cas, un switch peut être remplacé par une autre construction (table de pointeurs sur fonction ; enchainements if-else, etc). Sans compter qu'en appliquant la norme susdite, le moindre switch qui ne fait rien nécessite déjà 4 lignes. Dès qu'on rajoute un cas, on passe au moins à 6 (et on a toujours pas de traitement). Ca fait vite mal à la limite des 25 lignes

[JolyLoic]

Les projets ne sont pas notés que sur le résultat, mais aussi sur la qualité du code écrit - et sur sa lisibilité.

C'est comme ça partout, non ? Une évaluation d'informatique où ça ne serait pas le cas aurait de graves lacunes...

Pour autant que je m'en souvienne, l'interdiction des boucles for a pour but de bien faire comprendre qu'il s'agit de sucre syntaxique - toutes les boucles peuvent être écrites avec while () { } ou do { } while ()

Jusque là d'accord. Bien qu'on puisse aussi dire que le while n'est qu'un sucre syntaxique au dessus de la boucle for (j'ai déjà vu un professionnel me soutenir mordicus que for( ; ; ) était plus efficace que while(true))...

, qui sont les formes préférées.

Mais là, plus d'accord. S'il y a une variable qui sert naturellement de compteur à la boucle (elle s'incrémente une fois et une seule à chaque itération de la boucle), je trouve que la boucle for est plus claire à lire. Ne serait-ce que parce qu'il y a séparation plus claire entre le code de l'itération et le code décrivant ce qui a lieu pendant l'itération.

Et pour les initialisations, vu que tu as l'air de connaitre ces règles "de l'intérieur" tu confirmes que ce sont des règles faites avec le C en tête ?