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

[Joker-eph]

Envoyé par Barsy

Parce qu'il est certains cas où il faut que l'indentation se fasse au niveau d'un caractère de la ligne du dessus. Par exemple ça :

Code :

Ici la deuxième ligne doit être alignés sur la parenthèse ouvrante de la première ligne. C'est impossible à faire si on utilise des tabulations.

Mouais... ici il suffit de mettre autant de tabulations que pour le "if" et de ne mettre des espaces que pour indenter relativement au if.

Beaucoup d'IDE remplacent par défaut les tabulations par des espaces.

Mauvais IDE, changer d'IDE

[Klaim]

Sacree thread. Ya des trucs qui m'ont bien fait rire (le coup du ; a la ligne 80 en particulier).

Concernant les retours multiples, voici ma philosophie concernant les breaks et continue, qui est liee (avec laquelle beaucoup de devs semblent etre d'accord: http://programmers.stackexchange.com...es/58253#58253)

When used at the start of a block, as first checks made, they act like preconditions, so it's good.

When used in the middle of the block, with some code around, they act like hidden traps, so it's bad.

Pour moi c'est pareil pour les retours en milieu de fonction. En soit je trouve que c'est une tres mauvaise idee de les interdire parceque ca empeche tout ce qui est tests de preconditions.

Les fonctions, lorsquelles sont lues, le sont de haut en bas. Il est facile de reperer une return si il est proche du debut de la fonction et associe a un if et que le bloc du if est court.
C'est encore plus facile a lire si ca se repete parcequ'il y a plusieurs preconditions pour arriver au traitement final (je ne parle pas d'erreur ou d'assertions ici, c'est plus comme le pattern pipeline).

En revanche des que le return est planque au milieu d'un bout de code, ca peut etre tellement surprenant qu'en le survolant on ne le voit pas.

Donc en gros, c'est un peu se tirer une balle dans le pied (no pun intened) de s'interdire les retours multiples parceque ca encourage un style en arbre de condition qui est tres difficile a lire passe le 2nd niveau de profondeur. C'est un peu comme s'assurer qu'on ne pourra jamais avoir de code structure de maniere lisible.

Mettre les retours de maniere evidente, lisible et correcte est beacoup plus facile quand on a pas des barriere inutiles.

[Bluedeep]

Envoyé par Joker-eph

Mauvais IDE, changer d'IDE

Le paramétrer correctement est une solution moins radicale et plus facile à maître en oeuvre.

[el_slapper]

Envoyé par Bluedeep

Le paramétrer correctement est une solution moins radicale et plus facile à maître en oeuvre.

J'avais interprété ça comme une caricature de Berthold Brecht : Puisque le peuple vote contre le Gouvernement, il faut dissoudre le peuple!

[CinePhil]

Envoyé par el_slapper

J'avais interprété ça comme une caricature de Berthold Brecht : Puisque le peuple vote contre le Gouvernement, il faut dissoudre le peuple!

C'est ce que le gouvernement fait actuellement : Il incite les plus aisés à se barrer du pays pour ne garder que la population plus encline à approuver ses décisions.

[Bluedeep]

Envoyé par CinePhil

C'est ce que le gouvernement fait actuellement : Il incite les plus aisés à se barrer du pays pour ne garder que la population plus encline à approuver ses décisions.

En réalité, il voudrait même aller plus loin et perfectionner le système en bricolant le corps électroral.

[pseudocode]

Envoyé par Hinault Romaric

[B][SIZE="4"]voici quelques règles drôles qui y sont recensées : l'interdiction d’utiliser des retours multiples

Et donc l'obligation de tout encapsuler dans des if/then/else... et donc d'indenter tout le code qui suit.

l’obligation de faire précéder les noms des tables de la base de données des caractères « tbl »

Ce qu'il y a de bien avec le typage statique, c'est que c'est statique. Généralement le type est précisé avant le nom de la variable...
Ca ne sert a rien de le repéter dans le nom.

Code C :

1
2
int intCompteur; 
float floatProbability;

l’imposition d’un nombre d’espaces pour l’indentation ou encore l’utilisation de l’inversion de l’indentation.

astyle est votre ami.

Quelles règles de codage étranges avez-vous dû suivre ?

En cas de modif/correction, garder une copie de l'ancienne fonction entre commentaire. Une sorte de versionning intégré au code.

Code C :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
/* 01/03/2007 : remplacé suite à correction du BUG-123
int getStructValue(MyStruct *ptr) {
  return ptr->value;
}
*/
 
/* 12/09/2007 : remplacé suite à changement de structure
int getStructValue(MyStruct *ptr) {
  if (ptr!=NULL) return 0;
  return ptr->value;
}
*/
 
int getStructValue(MyStruct *ptr) {
  if (ptr!=NULL) return 0;
  return ptr->estimated_value;
}

[Klaim]

Envoyé par pseudocode

En cas de modif/correction, garder une copie de l'ancienne fonction entre commentaire. Une sorte de versionning intégré au code.

Code C :

Le code etait it finalement mis dans un control de source, histoire d'ajouter un peu d'ironie?

[tio]

En PHP, dans une page, je dois récupérer la liste des voitures pour les afficher en tableau.
J'ai une classe Voiture.
Je fais donc une méthode statique Voiture::getVoitures() qui fait une requête et me renvoie un tableau de Voiture.

Le responsable regarde mon code et me demande ce que veut dire ::
Je lui explique que c'est une méthode statique, il me répond que ça n'existe pas en PHP (on est en PHP5.3 ...), mais uniquement en Java voyons.
Il m'explique la méthode normale :
$maVoiture = new Voiture();
$tabVoitures = $mavoiture->RecupListVoiture();
qui renvoie un tableau de tableaux associatifs champ=>valeur
Appréciez aussi le franglais...

[clampin]

Moi j'ai eu un programme ou l'on devait nommer toutes les fonction comme suit, le premier mot en minuscule et deuxième mot, la première lettre du second mot en majuscule et le reste en minuscule....

par exemple une fonction qui ouvre un fichier...

Code :

1
2
3
4
5
void ouvrirFichier()
{
 ....
}

[Barsy]

Envoyé par clampin

Moi j'ai eu un programme ou l'on devait nommer toutes les fonction comme suit, le premier mot en minuscule et deuxième mot, la première lettre du second mot en majuscule et le reste en minuscule....

par exemple une fonction qui ouvre un fichier...

Code :

Tout ce qu'il y a de plus normal quoi...

[CinePhil]

Envoyé par clampin

Moi j'ai eu un programme ou l'on devait nommer toutes les fonction comme suit, le premier mot en minuscule et deuxième mot, la première lettre du second mot en majuscule et le reste en minuscule....

par exemple une fonction qui ouvre un fichier...

Code :

Euh... c'est très fréquent ça !
Je crois même me souvenir que c'est un standard dans certains frameworks tels que Zend Framework ou Symfony ou JBoss Seam.
Ou bien une règle du même genre qui permet au framework de décomposer le nom et de savoir comment le traiter si j'ai bien compris.

[Bluedeep]

Envoyé par clampin

Moi j'ai eu un programme ou l'on devait nommer toutes les fonction comme suit, le premier mot en minuscule et deuxième mot, la première lettre du second mot en majuscule et le reste en minuscule....

Cette convention très habituelle s'appelle la lowerCamelCase; elle est très fréquente et ne saurait certainement pas rentrer dans la liste des règles "bizarres".

[Klaim]

C'est aussi la version du camelCase standard de Java. Ce genre de regle n'influe pas des masses sur la sanite de celui qui lis, donc c'est pas vraiment un probleme.

Moi j'utilise beaucoup un mix de CamelCase pour les types, sous_lignes pour les fonctions et les noms de variables, et CamelCase_AvecUnderscore dans certains cas particuliers.

Ca peut aliener certains, mais l'experience montre que mieu vaut savoir s'adapter a ce genre de regle qui peuvent etre differentes selon les projets.

[LooserBoy]

On vient de me mettre sur une évolution de notre solution logicielle.
En mettant le nez dans le code, je me retrouve à lire du franglais particulièrement approximatif posant des problèmes de compréhension de l'utilité/fonction du mécanisme mis en oeuvre et même parfois avec de la logique inversée.

Exemple:

Code :

1
2
3
4
5
6
7
8
9
10
11
// A l'ouverture de la fenêtre d'édition de l'élément
bool modificationEnCours = true;

...

// A la fermeture de la fenêtre d'édition
if (!modificationEnCours)
{
    //Sauvegarde des modifications
}

Tout ça pour dire que des données ont bien été modifiées entre l'ouverture et la demande de fermeture de l'écran...

[andry.aime]

En parlant de camelCase, je me rappelle un développeur qui nomme les variables et fonctions en respectant le camelCase mais qui est presque une phrase complète.

[pseudocode]

Envoyé par andry.aime

En parlant de camelCase, je me rappelle un développeur qui nomme les variables et fonctions en respectant le camelCase mais qui est presque une phrase complète.

Ah, j'ai connu ça aussi...

JeCroisQueCeNomDeFonctionEstTrop(long aLire)

[Caravane]

Je trouve la limitation du nombre de lignes de code dans une méthode mal pensé
parce qu'elle oblige le développeur à éclater tout un algorithme pour respecter la règle !!!

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

[Klaim]

Envoyé par Caravane

Je trouve la limitation du nombre de lignes de code dans une méthode mal pensé
parce qu'elle oblige le développeur à éclater tout un algorithme pour respecter la règle !!!

C'est typique de confondre un effet de bord avec une source d'information.
Du code bien organise est souvent court dans les fonctions, parcequ'elles ne font qu'une chose a la fois, et c'est une generalite (il y a des fonctions qui doivent etre longues par design), donc on obtiens souvent des fonctions avec peu de lignes, qui tiennent dans un ecran.

Partir du principe que toutes les fonctions DOIVENT avoir un maximum d'un nombre de ligne est du coup pas tres logique puisque c'est pas parcequ'on a peu de ligne qu'on a une bonne organisation de code, c'est l'inverse.


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