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

[ManusDei]

Je me dis que vous aurez peut-être une solution pour un cas rencontré dans un stage où j'ai rien trouvé d'autre qu'un GOTO.

Code :

1
2
3
4
5
6
7
8
9
While(un_test){
  //section a de code
  if(machin) GOTO label;
  //section b de code
} end while
//section c de code
label :
//section d de code

Le if est au milieu du while, si vrai on part sur le code après le label.
Si on sort du while normalement, on exécute la section c avant d'exécuter la section d.

[LooserBoy]

Envoyé par ManusDei

Je me dis que vous aurez peut-être une solution pour un cas rencontré dans un stage où j'ai rien trouvé d'autre qu'un GOTO.

Code :

Comme ça?

Code :

1
2
3
4
5
6
7
8
9
10
While(un_test){
  //section a de code
  if(machin)
  {
     //section d de code
  }
  //section b de code
} end while
//section c de code

[Bluedeep]

Ouais .... un flag de plus dans le corps de méthode n'aurait pas changé la face du monde, je ne vois pas trop la nécessité du goto en l'espèce.
(surtout avec un branchement depuis un point unique).

[shadowmoon]

Envoyé par LooserBoy

Comme ça?

Code :

Non ce n'est pas équivalent, car, avec cette version du code

1) on ne sort pas de la boucle while au moment du if
2) les sections b et c sont quand même exécutées au lieu d’être ignorées, "sautées"

Je peux me tromper, mais si j'ai bien compris, je pense qu'il faudrait plutôt faire comme ça

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
While(un_test)
{
  //section a de code

  if(machin)
  {
     //section d de code
  }

   else
   {
      //section b de code
   }
} end while

if not (machin)
{
    //section c de code
    //section d de code
}

[ManusDei]

Envoyé par shadowmoon

1) on ne sort pas de la boucle while au moment du if
2) les sections b et c sont quand même exécutées au lieu d’être ignorées, "sautées"

Et la section d du code n'est pas exécutée après la section c si on sort du while normalement (sans passer par le GOTO).
Il y avait des variables communes dans les 4 sections, donc impossible de changer l'ordre dans lequel elles sont exécutées.

@shadowmoon : Oui, en rajoutant une section d du code après la section c dans le if(not machin)

[BenoitM]

euh faut remplacer le goto par un break sinon vous n'aurez pas le même comportement non?

[Troudhyl]

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
bool continuer = true;
While(un_test && continuer){
  //section a de code
  if(machin) {
    continuer = false;
  } else {
     //section b de code
  }
} end while
if (continuer) {
  //section c de code
}
//section d de code

Version avec le break :

Code :

1
2
3
4
5
6
7
8
9
10
While(un_test){
  //section a de code
  if(machin)
    break;
  //section b de code
} end while
if (!un_test) {
  //section c de code
}
//section d de code

(si la section a ne peut pas changer un_test)

[rt15]

Envoyé par shadowmoon

Je peux me tromper, mais si j'ai bien compris, je pense qu'il faudrait plutôt faire comme ça

Code :

Il manque aussi le break, et le code "section d" est dupliqué, ce qui est aussi souvent considéré comme une très mauvaise pratique car ça gène le refactoring et la maintenance du code.

Il faut qu'on retourne tous à l'école !

Enième proposition :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
execute_c = true;
While(un_test){
  //section a de code
  if(machin)
  {
    execute_c = false;
    break;
  }
  //section b de code
} end while
if (execute_c)
{
  //section c de code
}

//section d de code

[BenoitM]

La solution de Troudhyl me semble correct
(j'avais la flamme d'écrire le pseudo code )

[Lung]

Envoyé par BenoitM

(j'avais la flamme d'écrire le pseudo code )

Te brûle pas !

[Glob]

Envoyé par Uther

Le problème des getter/setter n'a rien a voir avec l'introspection, ou la lisibilité, c'est même plutôt une plaie à ce niveau.

Ils sont là car ils servent d'interface aux javabean. Un bean se doit d'offrir une encapsulation forte. Grâce au getter/setter les beans ont un contrôle complet sur leur propriétés qu'il peuvent restreindre (read/write only), vérifier, générer à la voler, ... etc
Certes c'est lourd de faire un getter/setter quand on ne fait qu'une opération d'écriture/lecture de variable (Sun/Oracle devrait vraiment se pencher sur une syntaxe spéciale pour les propriétés). Mais ça permet de pouvoir faire évoluer l'opération dans le futur pour par exemple ajouter un contrôle sur un setter, ce qui n'est pas possible avec un accès direct à un champ.

Je parle de DTO, pas de javabeans. De simples containers dont l'équivalent en C serait le struct. Je ne vois toujours pas le moindre petit début de pertinence à y mettre des accessors.
cf Java Coding Conventions 10.1

[Uther]

Pour les DTO en effet ça ne sert à rien.

C'est un exemple typique de bonne pratique dans un cas particulier (objet offrant une forte encapsulation) qui a été enseignée par certains comme un dogme absolu, généralement par fainéantise d'expliquer le pourquoi du comment.
Du coup des gens veulent les étendre à des domaines ou elles sont contreproductives.

[Deaf]

Envoyé par Glob

Je parle de DTO, pas de javabeans. De simples containers dont l'équivalent en C serait le struct. Je ne vois toujours pas le moindre petit début de pertinence à y mettre des accessors.
cf Java Coding Conventions 10.1

On peut imaginer une classe qui étend le DTO pour y ajouter une logique métier, tout en restant utilisable comme un DTO par la plupart des autres classes.
Dans ce cas, si tu utilise directement les champs, tu peux zapper la logique métier. Pour moi, les getters/setters permettent de laisser ce genre de portes ouvertes, même si on en a pas besoin, a priori.

[bilbonec]

La pire règle de codage est encore de n'en imposer aucune.

C'est ce qui m'arrive dans ma mission actuelle où, après avoir développé seul pendant quelques mois, un autre développeur se met au freestyle : différentes indentations par fichiers, différentes façons de présenter les {}, nommage complètement différent des méthodes / variables, etc.

Et là, on se dit que dans les normes de codage ... il y a du bon !

[Bluedeep]

Envoyé par bilbonec

La pire règle de codage est encore de n'en imposer aucune.

C'est ce qui m'arrive dans ma mission actuelle où, après avoir développé seul pendant quelques mois, un autre développeur se met au freestyle : différentes indentations par fichiers, différentes façons de présenter les {}, nommage complètement différent des méthodes / variables, etc. !

Dans la mesure où tu es là depuis quelques mois, ce n'est quand même pas difficile de lui imposer tes normes de codage. En bonne logique ta hiérarchie devrait te soutenir (sauf su tu n'insistes pas, bien sur).

[Rayek]

Envoyé par bilbonec

Et là, on se dit que dans les normes de codage ... il y a du bon !

Enfin bon, il y a des limites, dans la boite où je suis on a passé un fois 2 heures à discuter pour savoir où l'on met le begin dans un case (pour ma part j'étais plutôt en mode on s'en fou tant que ça reste lisible)

et ça pinaillait entre

Code delphi :

1
2
3
4
5
6
7
8
 
Case XXX of
1 : begin
  // cas 1
end;
2 : begin
  // cas 2
end;

et

Code delphi :

1
2
3
4
5
6
7
8
9
10
11
 
Case XXX of
1 :
  begin
    // cas 1
  end;
2 :
  begin
    // cas 2
  end;
end;

[Freem]

Envoyé par rt15

3 fois le même programme, qui copie le contenu d'un fichier vers un autre fichier :

Sans goto, traitement normal en premier :

Code C :

Sans goto, traitement d'erreur en premier :

Code C :

Avec goto :

Code C :

Franchement, avec la première solution, il est très difficile de vérifier que les ressources sont fermées correctement. Et la deuxième me semble moins lisible que la troisième, mais c'est un peu subjectif peut être.

Et pour rappel, Linux est bourré de goto...

Refaisons les mêmes codes proprement:

Sans goto, traitement normal en premier :

Code C :

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
46
47
48
 
#include <stdlib.h>
#include <stdio.h>
 
BOOLEAN printError(BOOLEAN condition, char *errorText)
{
	if(FALSE==condition)
		perror(errorText);
	return condition;
}
 
int main()
{
  char* lpBuffer;
  FILE* lpInputFile;
  FILE* lpOutputFile;
  int nSize;
  int nRes;
 
  nRes = 1;
 
  /* Open input file */
  lpInputFile = fopen("input.txt", "rb");
  if (printError(lpInputFile,"Failed to open input file"))
  {
    /* Open output file */
    lpOutputFile = fopen("output.txt", "wb");
    if (printError(lpOutputFile,"Failed to open output file"))
    {
      /* Retrieve size of the file*/
	  fseek(lpInputFile, 0, SEEK_END);
	  nSize = ftell(lpInputFile);
	  fseek(lpInputFile, 0, SEEK_SET);
 
      /* Allocate a buffer to store input file content */
      lpBuffer = (char*)malloc(nSize);
      if (printError(lpBuffer,"Failed to allocate buffer"))
        /* Read from input file to buffer */
        if (printError(fread(lpBuffer, 1, nSize, lpInputFile) == nSize,"Failed to read input file"))
          /* Write from buffer to output file */
          nRes= printError(fwrite(lpBuffer, 1, nSize, lpOutputFile) == nSize,"Failed to write to output file");
        free(lpBuffer);
      fclose(lpOutputFile);
    }
    fclose(lpInputFile);
  }
  return nRes;
}

A noter qu'en fait, on peut améliorer le truc encore...
Par exemple, enlever des if:

Code :

1
2
3
4
5
6
7
8
9
10
11
      /* Allocate a buffer to store input file content */
      lpBuffer = (char*)malloc(nSize);
      nRes=
		printError(lpBuffer,"Failed to allocate buffer") &&
        /* Read from input file to buffer */
		printError(fread(lpBuffer, 1, nSize, lpInputFile) == nSize,"Failed to read input file") &&
        /* Write from buffer to output file */
        printError(fwrite(lpBuffer, 1, nSize, lpOutputFile) == nSize,"Failed to write to output file");
      free(lpBuffer); /* no use to check: no problem if free is null */
      fclose(lpOutputFile);

L'astuce: les && permettent d'agir comme un if en fait. Astuce apprise grâce au shell: si la première condition est fausse, alors l'ensemble de la condition sera fausse, donc le compilateur intelligent ne prendra pas la peine de vérifier les autres conditions

Sans goto, traitement d'erreur en premier :

Ouai mais en fait, flemme de refaire la même astuce que précédemment.

Résultat final: 19 lignes de gagnées (28.4% de taille de code en moins tout de même, presque 1/3!), moins d'indentations, pas de goto et un code globalement plus clair.
Problème: coût d'appel à la fonction printError(int, char*) à chaque fois, qui peut être résolu via des macros, d'ailleurs. Ou le mot-clé inline en C++, mais j'ai tenu à respecter le langage C au maximum de mes souvenirs.

On peut améliorer encore plus le truc, en utilisant:
_ des constantes pour les messages d'erreur
_ une macro pour remplacer le if, qui prenne en paramètre le message d'erreur.

Code :

1
2
3
4
5
6
7
8
9
While(un_test){
  //section a de code
  if(machin) GOTO label;
  //section b de code
} end while
//section c de code
label :
//section d de

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
void monBloc(void)
{
  static int flag=0;
  if(0 == flag)
  {
    ;//section d de code
    flag=1;
  }
}

While(un_test)
{
  //section a de code
  if(machin)
  {
    monBloc();
    break;
  }
  //section b de code
} end while
//section c de code

monBloc();

Sinon:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
void machin(bool condition)
{
  //section d
}

bool boucle()
{
  While(un_test){
    //section a de code
    if(machin) return;
    //section b de code
  } 
  //section c de code
}

main()
{
  boucle();
  machin();
}

Les solutions, s'pas ce qui manque.

Ah oui, je viens de me rappeler une horreur, vue par un prof:

Code java :

1
2
3
4
5
6
7
8
9
10
 
fonction()
{// debut fonction
  if()
  { // début if
    for(;;) 
    { //debut for
    } // fin for
  } // fin if
}// fin fonction

Arrgg!g!!!

[Loceka]

Envoyé par Freem

L'astuce: les && permettent d'agir comme un if en fait. Astuce apprise grâce au shell: si la première condition est fausse, alors l'ensemble de la condition sera fausse, donc le compilateur intelligent ne prendra pas la peine de vérifier les autres conditions

C'est effectivement le principe de l'évaluation paresseuse. Par contre, étant donné que c'est une optimisation du langage, tous les langages ne la pratiquent pas.

Par exemple en shell (/bin/sh), il me semble bien que la commande test (ou son équivalent [ ... ]) ne pratique pas l'évaluation paresseuse (c'est d'ailleurs ce que confirme ce site).

[Aurélien LEQUOY]

Envoyé par Bovino

Ne pas avoir le droit de créer de nouvelle base de donnée pour des activités différentes !

Imaginons par exemple que nous ayons créé une base correspondant à des recettes de cuisine, avec les champs "ingrédients", "durée" et "opérations".
On décide ensuite de créer un planning d'entrainement sportif, du coup, dans ce cas, "ingrédients" correspond à "type d'exercice", "durée" à "lieu" et "opérations" à "équipement". Seulement, comme il manque un champ pour "durée de l'exercice", alors on va utiliser le champ "ingrédients" en séparant la valeur "type d'exercice" et "durée de l'exercice" par un délimiteur arbitraire...

Tout cela est parfaitement résumé dans cet article...

tu travaillais chez doctissimo ? :p

[Aurélien LEQUOY]

Envoyé par Uther

Non seulement :
- le code que tu accuses d'être faux est tout à fait correct : fopen ne retourne NULL(soit 0) qu'en cas d'erreur. Si tu ne me crois pas, il suffit de consulter le man
- la solution que tu proposes est incorrecte. Ton code ne gèrera pas les erreurs.

Tout a fait d'accords que ce soit en C ou en PHP