Quelle est la règle de codage la plus étrange que vous avez été forcé de suivre ?

[rt15]

Envoyé par rt15

Éclater un long algo est parfois une très bonne chose. Cela permet souvent de diviser la complexité en petit bouts simples. Le code résultant est souvent bien plus lisible.

Mais bon tout dépend de l'algo...

Code :

1
2
3
4
5
6
7
8
9
10
11
12
si c'est l'heure de manger alors
  pour i de 1 à 20 faire
    prendre la fourchette
    attraper de la bouffe avec la fourchette
    porter la fourchette à la bouche
    macher
    avaler
  fait
sinon
  aller sur le canapé.
  fermer les yeux.
fsi;

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
si c'est l'heure de manger alors
  manger
sinon
  faire_la_sieste
fsi;

procedure manger
  pour i de 1 à 20 faire
    prendre la fourchette
    attraper de la bouffe avec la fourchette
    porter la fourchette à la bouche
    macher
    avaler
  fait
fin

procedure faire_la_sieste
  aller sur le canapé.
  fermer les yeux.
fin

[CinePhil]

Si les procédures manger et faire la sieste sont utilisées plusieurs fois dans le logiciel, OK, ça vaut le coup de découper. Sinon, un simple commentaire suffit pour rendre clair le programme sans avoir besoin d'aller chercher éventuellement dans quel fichier perdu est définie cette foutue fonction !

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
si c'est l'heure de manger alors
 // Manger  
  Tant que assiette non vide faire
    prendre la fourchette
    attraper de la bouffe avec la fourchette
    porter la fourchette à la bouche
    macher
    avaler
  fait
sinon
  // Faire la sieste
  aller sur le canapé.
  fermer les yeux.
fsi;

[Barsy]

Envoyé par CinePhil

Si les procédures manger et faire la sieste sont utilisées plusieurs fois dans le logiciel, OK, ça vaut le coup de découper. Sinon, un simple commentaire suffit pour rendre clair le programme sans avoir besoin d'aller chercher éventuellement dans quel fichier perdu est définie cette foutue fonction !

Sauf que quand ton code commence à ressembler à

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
si c'est l'heure de manger alors
	// Manger  
	Tant que assiette non vide faire
		// Prendre la fourchette
		Tendre le bras
		Ouvrir la main
		Placer la main au dessus de la fourchette
		Fermer la main
		
		Tant que Assiette pleine
			// Attraper de la bouffe avec la fourchette
			...
			// Porter la fourchette à la bouche
			...
			// Macher
			...
			// Avaler
			...
		Fin Tant que
	fait
sinon
	// Faire la sieste
	
	// Aller sur le canapé.
	...
	// Fermer les yeux.
	...
fsi;

Je pense qu'il est nécessaire de le découper en plusieurs méthode, même si celles-ci ne sont pas utilisées plusieurs fois.

[minnesota]

quand le chef de projet fan de maitre Yoda dit à barsy
de pseudo-coder «les yeux fermés sur le canapé la sieste tu feras»,

ça donne

Envoyé par Barsy

Code :

En plus là vous autres, vos codes sont faux, avant d'autoriser à manger, il faut tester si l'individu n'est pas un Mogwaï et s'il n'est pas minuit passé, mais encore, appeler l'horloge parlante pour être sur qu'il n'est pas minuit passé

[Barsy]

Envoyé par minnesota

quand le chef de projet fan de maitre Yoda dit à barsy
de pseudo-coder «les yeux fermés sur le canapé la sieste tu feras»,

ça donne



En plus là vous autres, vos codes sont faux, avant d'autoriser à manger, il faut tester si l'individu n'est pas un Mogwaï et s'il n'est pas minuit passé, mais encore, appeler l'horloge parlante pour être sur qu'il n'est pas minuit passé

Je ne comprends pas ta remarque. Faire la sieste nécessite bien d'aller sur le canapé et de fermer les yeux non ? Si tu rapproches un peu plus tes yeux de l'écran, tu remarqueras qu'il n'y a pas de "..." en dessous de "faire la sieste".

[ManusDei]

Envoyé par minnesota

En plus là vous autres, vos codes sont faux, avant d'autoriser à manger, il faut tester si l'individu n'est pas un Mogwaï et s'il n'est pas minuit passé, mais encore, appeler l'horloge parlante pour être sur qu'il n'est pas minuit passé

On bosse pour le même client, je crois

[el_slapper]

Envoyé par Klaim

(.../...)(Je dis ca, j'ai pas une seule fonction longue dans mon code actuel d'un tres gros projet...)

J'en ai une seule dans un projet de taille moyenne. Mais Barsy a raison : "ça dépend". Je dirais que tant qu'on peut découper sans nuire à la lisibilité, il faut découper. Quand ça devient de l'encapsulage de mouches, il faut arrêter. Mon exemple classique(dont je suis coupable) :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Sub TraitementDonness
    For i = 1 to maxLignes
        Call TraitementLigne(i)
    Next i
End Sub

Sub TraitementLigne(i as integer)
    For j = 1 to maxColonnes
        Call TraitementCase(i,j)
    next j
End Sub 

Sub TraitementCase(i as integer, j as integer)
    Cells(i,j) = Cells(i,j) + 1
End Sub

Oui j'ai des procédures courtes. Et oui c'est une erreur. C'est rarement une erreur(la plupart du temps ça simplifie la lecture), mais dans ce cas précis, c'est vraiment une erreur(même si j'ai un poil simplifié TraitementCase, et volontairement omis les déclaration de variables).

[LooserBoy]

Envoyé par el_slapper

Quand ça devient de l'encapsulage de mouches, il faut arrêter.

Ouf, j'ai mal lu...

[el_slapper]

Envoyé par LooserBoy

Ouf, j'ai mal lu...

la formule était volontairement glissante.....

[raimbow]

Si les procédures manger et faire la sieste sont utilisées plusieurs fois dans le logiciel, OK, ça vaut le coup de découper. Sinon, un simple commentaire suffit pour rendre clair le programme sans avoir besoin d'aller chercher éventuellement dans quel fichier perdu est définie cette foutue fonction !

Le problème quand tu bosse sur des vrai programmes, c'est qu'ils sont amené à évolué d'une façon que tu ne peux pas prévoir (en fonction des besoins future du client) donc c'est impossible (la plupart de temps) de dire avec certitude si une fonction sera ou non utilisé plusieurs fois.

Et même pour la partie non-métier qui ne dépend pas de ton client, ton code évoluera si il est utilisé, donc y'a des chances qu'une fonction soit réutilisé à un autre endroit de ton code même si au départ ça ne devait pas être le cas.


Pour l'argument du "Si on découpe trop c'est chiant de retrouvé où sont les fonctions qui sont appelé" je te conseil d'utiliser un vrai IDE. Sous eclipse par exemple CTRL + clic sur une méthode m'ouvre le bon fichier à l'endroit où est définis la fonction.

Découper en fonction courte son programme permet également d'optimiser plus facilement son code en limitant les risques de tout casser. Par exemple sur une grande fonction, une variable qu'on utilise au début peut aussi être utilisé à un autre endroit, parfois un peu obscure (genre l'index d'un tableau), et il faut parcourir tout le code pour vérifier que ce n'est pas le cas. Sur une fonction de 5/10 lignes on le voit tout de suite.

C'est aussi plus facile à débugger souvent. Tu check les entrés sorties des fonctions et tu vois où ça merde. Une fois que t'as trouvé la fonction qui pose problème t'as au max 15 lignes à analyser. Si c'est sur une fonction de 250 Lignes, tu va encore passer un bon moment à trouver les lignes qui posent problèmes avant de te pencher réellement sur le problème en lui même.

Pareil pour les audits de performances, tu fais des bench sur chaque fonction et tu vois directement lesquelles ils faut optimiser, c'est bien plus simple !

[minnesota]

Envoyé par Barsy

Je ne comprends pas ta remarque. Faire la sieste nécessite bien d'aller sur le canapé et de fermer les yeux non ? Si tu rapproches un peu plus tes yeux de l'écran, tu remarqueras qu'il n'y a pas de "..." en dessous de "faire la sieste".

Oui j'avais vu après coup, juste avant de poster mais j'avais pas envie d'éditer, et puis de toute façon c'est faut, parce que Gandalf y dort les yeux ouverts hein ManusDei

[leminipouce]

Envoyé par saccoche

Je confirme que les merges sont ingérables sans ce genre de cas.

Il suffit de configurer ton outil pour qu'il ne prenne pas en compte les différences d'espaces dans les merges !

Pour moi le vrai problème c'est d'avoir des règles hétérogènes. Quand je regarde du code, je déteste avoir à m'adapter au règles de formatage de chacun des développeurs. Ainsi, si je passe d'une classe à une autre, voir d'une méthode à une autre et que les règles diffèrent totalement, ça rend le code bien plus obscur à mon goût, bien moins facile à lire.

A titre de comparaison, avez-vous déjà vu un livre, ou la police serait différente d'une page à l'autre, ou la mise en page varierait d'un chapitre ou paragraphe au suivant. C'est fatiguant à lire. Pour moi, il en va de même pour le code : on doit pouvoir le lire comme si un seul développeur l'avait écrit.

[Bluedeep]

Envoyé par leminipouce

Pour moi le vrai problème c'est d'avoir des règles hétérogènes. Quand je regarde du code, je déteste avoir à m'adapter au règles de formatage de chacun des développeurs. Ainsi, si je passe d'une classe à une autre, voir d'une méthode à une autre et que les règles diffèrent totalement, ça rend le code bien plus obscur à mon goût, bien moins facile à lire.

Ca c'est surtout la marque d'un CP tech ou d'un "dev leader" qui fait pas son boulot.

[Barsy]

Envoyé par Bluedeep

Ca c'est surtout la marque d'un CP tech ou d'un "dev leader" qui fait pas son boulot.

Quand il y en a un...

[andry.aime]

Envoyé par leminipouce

Il suffit de configurer ton outil pour qu'il ne prenne pas en compte les différences d'espaces dans les merges !

Pour moi le vrai problème c'est d'avoir des règles hétérogènes. Quand je regarde du code, je déteste avoir à m'adapter au règles de formatage de chacun des développeurs. Ainsi, si je passe d'une classe à une autre, voir d'une méthode à une autre et que les règles diffèrent totalement, ça rend le code bien plus obscur à mon goût, bien moins facile à lire.

Nous on travaille sur Eclipse et on crée un Template pour le Code Style que l'on partage à tous les développeurs pour éviter ce genre de problème. Un simple "Clean up" permet de formater tous le projet .

[pmithrandir]

Envoyé par andry.aime

Nous on travaille sur Eclipse et on crée un Template pour le Code Style que l'on partage à tous les développeurs pour éviter ce genre de problème. Un simple "Clean up" permet de formater tous le projet .

En se débrouillant bien, on peut même le mettre en règle de pre commit sur SVN pour éviter de polluer le référentiel avec des contenus non formatés.

[leminipouce]

Envoyé par Bluedeep

La régle la plus étrange ?

Pour ma part, et sans hésiter, il y a de cela sept ou huit ans, un projet chez un client où le DBA ne voulait pas de procédure stockées ....

Un visionnaire ?

[leminipouce]

Envoyé par andry.aime

Nous on travaille sur Eclipse et on crée un Template pour le Code Style que l'on partage à tous les développeurs pour éviter ce genre de problème. Un simple "Clean up" permet de formater tous le projet .

Quand j'étais sous Eclipse, je maintenais également ce genre de template. Avec en prime le partage de la conf. de sauvegarde qui formattait automatiquement le code. Comme ça, impossible (à moins d'aller changer le template mais là, il faut vraiment avoir envie de faire ch***) de commiter sans avoir au préalable (automatiquement) formaté le code.

Et quand tu fais un merge, ou un simple diff avec ton VCS, c'est du bonheur. Tu te prends pas la tête et tu vois directement ce qui a été modifié et seulement ça !

Envoyé par pmithrandir

En se débrouillant bien, on peut même le mettre en règle de pre commit sur SVN pour éviter de polluer le référentiel avec des contenus non formatés.

Comment ? Je l'ai toujours fait au niveau des IDE, avec l'énorme inconvénient que dès que tu as différents IDE, ils n'ont pas les mêmes règles de formatage --j'entends par là qu'on peut pas forcément les configurer rigoureusement pareil (et de suite, ça devient chiant !) J'avoue que j'aimerais bien l'automatiser sur un commit (git ou SVN), mais je ne vois pas comment !

[pseudocode]

Envoyé par leminipouce

Comment ? Je l'ai toujours fait au niveau des IDE, avec l'énorme inconvénient que dès que tu as différents IDE, ils n'ont pas les mêmes règles de formatage --j'entends par là qu'on peut pas forcément les configurer rigoureusement pareil (et de suite, ça devient chiant !) J'avoue que j'aimerais bien l'automatiser sur un commit (git ou SVN), mais je ne vois pas comment !

Pour SVN, il suffit de créer un script "hooks\post-commit.bat" qui appelle le JavaCodeFormatter de Eclipse.

[SurferIX]

Envoyé par leminipouce

Comment ? Je l'ai toujours fait au niveau des IDE, avec l'énorme inconvénient que dès que tu as différents IDE, ils n'ont pas les mêmes règles de formatage --j'entends par là qu'on peut pas forcément les configurer rigoureusement pareil

Sous vim j'ai fait des copier coller de mon répertoire ".vim" et mon ".vimrc" ça a toujours fonctionné sur tous les ordinateurs sur lesquels je les ai mis (toutes les distros + PC différents). C'est un peu du troll mais pas trop, parce que c'est une info à savoir : la copie de la config de vim fonctionne de manière transparente partout (avec, justement, les codes snippets, l'auto complétion les auto formatage (je tape date+TAB et hop le mot "date" est remplacé par la date au format JJ/MM/AAAA) etc.).