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

[rt15]

Presque toutes les normes de codage peuvent paraître très logique à quelqu'un et très étrange à quelqu'un d'autres. Il faut dire aussi que les raisons pour l'existence de certaines de ces normes peuvent être valables dans un certains contextes et beaucoup plus discutable dans d'autres (Cas de la notation hongroise ci-dessus).

On rencontre même des gens contre des règles très reconnues comme "goto c'est le mal". Genre moi.


(image de xkcd)

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 :

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
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
#include <stdlib.h>
#include <stdio.h>
 
int main()
{
  char* lpBuffer;
  FILE* lpInputFile;
  FILE* lpOutputFile;
  int nSize;
  int nRes;
 
  nRes = 1;
 
  /* Open input file */
  lpInputFile = fopen("input.txt", "rb");
  if (lpInputFile)
  {
    /* Open output file */
    lpOutputFile = fopen("output.txt", "wb");
    if (lpOutputFile)
    {
      /* 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 (lpBuffer)
      {
        /* Read from input file to buffer */
        if (fread(lpBuffer, 1, nSize, lpInputFile) == nSize)
        {
          /* Write from buffer to output file */
          if (fwrite(lpBuffer, 1, nSize, lpOutputFile) == nSize)
          {
             nRes = 0;
          }
          else
          {
            perror("Failed to write to output file");
          }
        }
        else
        {
          perror("Failed to read input file");
        }
        free(lpBuffer);
      }
      else
      {
        perror("Failed to allocate buffer");
      }
      fclose(lpOutputFile);
    }
    else
    {
      perror("Failed to open output file");
    }
    fclose(lpInputFile);
  }
  else
  {
    perror("Failed to open input file");
  }
  return nRes;
}

Sans goto, traitement d'erreur 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
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
#include <stdlib.h>
#include <stdio.h>
 
int main()
{
  char* lpBuffer;
  FILE* lpInputFile;
  FILE* lpOutputFile;
  int nSize;
  int nRes;
 
  nRes = 1;
 
  /* Open input file */
  lpInputFile = fopen("input.txt", "rb");
  if (!lpInputFile)
  {
    perror("Failed to open input file");
  }
  else
  {
    /* Open output file */
    lpOutputFile = fopen("output.txt", "wb");
    if (!lpOutputFile)
    {
      perror("Failed to open output file");
    }
    else
    {
      /* 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 (!lpBuffer)
      {
        perror("Failed to allocate buffer");
      }
      else
      {
        /* Read from input file to buffer */
        if (fread(lpBuffer, 1, nSize, lpInputFile) != nSize)
        {
          perror("Failed to read input file");
        }
        else
        {
          /* Write from buffer to output file */
          if (fwrite(lpBuffer, 1, nSize, lpOutputFile) != nSize)
          {
            perror("Failed to write to output file");
          }
          else
          {
            nRes = 0;
          }
        }
        free(lpBuffer);
      }
      fclose(lpOutputFile);
    }
    fclose(lpInputFile);
  }
 
  return nRes;
}

Avec goto :

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
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
#include <stdlib.h>
#include <stdio.h>
 
int main()
{
  char* lpBuffer;
  FILE* lpInputFile;
  FILE* lpOutputFile;
  int nSize;
  int nRes;
 
  nRes = 1;
 
  /* Open input file */
  lpInputFile = fopen("input.txt", "rb");
  if (!lpInputFile)
  {
    perror("Failed to open input file");
    goto the_end;
  }
 
  /* Open output file */
  lpOutputFile = fopen("output.txt", "wb");
  if (!lpOutputFile)
  {
    perror("Failed to open output file");
    goto close_input_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 (!lpBuffer)
  {
    perror("Failed to allocate buffer");
    goto close_output_file;
  }
 
  /* Read from input file to buffer */
  if (fread(lpBuffer, 1, nSize, lpInputFile) != nSize)
  {
    perror("Failed to read input file");
    goto free_buffer;
  }
 
  /* Write from buffer to output file */
  if (fwrite(lpBuffer, 1, nSize, lpOutputFile) != nSize)
  {
    perror("Failed to write to output file");
    goto free_buffer;
  }
 
  nRes = 0;
 
free_buffer:
  free(lpBuffer);
close_output_file:
  fclose(lpOutputFile);
close_input_file:
  fclose(lpInputFile);
the_end:
  return nRes;
}

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

[Barsy]

Envoyé par _skip

Pour ce qui est des retours multiples, je trouve ceci tout à fait acceptable :

Code :

ou ceci :

Code :

Mais les codes que tu présentes ci-dessus, c'est dans le meilleur des mondes. Dans la réalité, il n'est pas rare de tomber sur des codes avec des méthodes bourrées de return et même au mileu des boucles.

C'est comme pour le code à base de goto ci-dessus. C'est facile tous les label sont à la fin de la méthode. C'est rarement le résultat que l'on obtient lorsque l'on autorise l'utilisation de goto dans un code...

[sciencesmaths]

Code :

1
2
3
4
5
While(1)
do
{
if(myFunction()) BREAK;
}

[el_slapper]

Envoyé par Barsy

(.../...)C'est comme pour le code à base de goto ci-dessus. C'est facile tous les label sont à la fin de la méthode. C'est rarement le résultat que l'on obtient lorsque l'on autorise l'utilisation de goto dans un code...

+1

Linus peut se permettre le GOTO, il a le niveau pour. Les règles "standard" sont dédiées aux programmeurs "standard" qui commettent pas mal d'horreurs. Je ne suis pas forcément toujours au dessus du standard, d'ailleurs, donc j'essaie de respecter les règles - autant que je peux.

[ManusDei]

Il ne s'agit pas d'une règle, mais d'une convention. Et comme toutes les conventions, elle est parfois contre productive (même si ça peut être très rare).

[_skip]

Envoyé par Barsy

Mais les codes que tu présentes ci-dessus, c'est dans le meilleur des mondes. Dans la réalité, il n'est pas rare de tomber sur des codes avec des méthodes bourrées de return et même au mileu des boucles.

C'est comme pour le code à base de goto ci-dessus. C'est facile tous les label sont à la fin de la méthode. C'est rarement le résultat que l'on obtient lorsque l'on autorise l'utilisation de goto dans un code...

Oh non tu te trompes, j'écris du code comme ça très souvent et je vis certainement dans un monde très exigent s'il en est. Et il y a pire que ça : j'accepte aussi de sortir d'une boucle par un return (le salaud ).

Après que se passe-t-il si jamais je commence à avoir besoin de return partout? Ben je refactore, genre je délègue les cas particuliers à de nouvelles méthodes. En fait il est rare que je dépasse le 2 niveaux d'indentation dans une méthode et si je dois scroller ou analyer les parenthèses pour comprendre le flux de mon traitement il y a une petite voix qui me dit "t'es peut être en train de faire de la merde", "ta méthode elle fait peut être trop de choses".

Donc j'utilise volontiers un return en cours de fonction afin de bien documenter la réflexion, pré-condition non remplie? -> hop tu dégages d'ici. L'objet en cours est une pomme? -> hop délègue à la méthode des pommes. Si tu te mets bien dans la peau d'une personne qui lit ton code naturellement de haut en bas, t'arrives bien à représenter la logique de ton traitement en utilisant des return *par exemple* de sous-méthodes.

[Traroth2]

Envoyé par Kaamo

En quoi cette règle serait farfelue ? Si un tel utilise 3 espaces, un autre 2, etc ... on ne s'y retrouve plus. Je trouve ça plutôt important de spécifier le nombre d'espaces pour l'indentation.
Surtout que selon le vécu du développeur, l'indentation diffère fortement (je pense au style GNU, différent de celui du C, ou Java etc).

Dans certaines équipes, on distingue même les espaces des tabulations.

[Traroth2]

Envoyé par Lynix

Actuellement en fac d'info et ma prof de C interdit l'utilisation du else if car elle ne trouve pas ça clair...

Ah ouais, quand même...

[Barsy]

Envoyé par _skip

Oh non tu te trompes, j'écris du code comme ça très souvent et je vis certainement dans un monde très exigent s'il en est. Et il y a pire que ça : j'accepte aussi de sortir d'une boucle par un return (le salaud ).

Après que se passe-t-il si jamais je commence à avoir besoin de return partout? Ben je refactore, genre je délègue les cas particuliers à de nouvelles méthodes. En fait il est rare que je dépasse le 2 niveaux d'indentation dans une méthode et si je dois scroller ou analyer les parenthèses pour comprendre le flux de mon traitement il y a une petite voix qui me dit "t'es peut être en train de faire de la merde", "ta méthode elle fait peut être trop de choses".

Donc j'utilise volontiers un return en cours de fonction afin de bien documenter la réflexion, pré-condition non remplie? -> hop tu dégages d'ici. L'objet en cours est une pomme? -> hop délègue à la méthode des pommes. Si tu te mets bien dans la peau d'une personne qui lit ton code naturellement de haut en bas, t'arrives bien à représenter la logique de ton traitement en utilisant des return *par exemple* de sous-méthodes.

Je ne parlais pas de toi. Je parlais de tous ceux qui vont pondre un code pourri parce qu'on leur aura accordé le droit de développer de cette façon.

Heureusement qu'il y a des gens qui réfléchissent quand ils codent, mais plus je fais ce métier, plus j'ai l'impression qu'ils sont rares. Parfois, je me dis aussi que c'est un problème lié à la prestation, les développeurs savent qu'ils ne vont pas rester longtemps sur le projet alors ils ne s'investissent pas trop pour faire un travail correct, ce sera le prochain presta qui pâtira des défauts... Et qui à sont tour fera de la merde, pourquoi se casser le cul à faire du code propre alors que celui dont on hérite est calamiteux, c'est souvent même impossible...

[Squisqui]

À part pour la gestion d'erreurs, je n'ai personnellement jamais eu recours à goto.

Concernant l'indentation, si la boite contraint ses développeurs à utiliser des polices monospaces en utilisant l'indentation présenté par Uther en début de topic (indentation par des tabulations et alignement pas des espaces). Chacun pourrait y aller à sa sauce avec son éditeur sans que l'autre ait besoin d'utiliser un outil pour remettre en forme le code.

Chez pas mal de débutants, je remarque souvent une non-indentation du premier niveau soit :

Code :

1
2
3
4
5
6
int main()
{
instructions
if (expression)
    instruction
}

Malgré qu'on écrive au final que très très peu sur la première colonne, elle permet tout de même de repérer rapidement le début et la fin d'une fonction.

Je fais parti des sauvages qui indentent avec 8 espaces et qui essaient de faire des lignes de 80 colonnes maximum...
Ainsi je compte pas mes indentations, je vois tout de suite quand il y en a plus de 3 ou 4 et me demande si j'écris de la merde. Les 80 colonnes se retrouvent de toute façon bouffées parce qu'il n'y a qu'en Math qu'on déclare systématiquement des noms de variable et de fonction à une lettre qui ne veulent rien dire... Au final, c'est surtout pour qu'une ligne tienne sur une ligne de l'écran je laisse de la place à coté de l'éditeur pour voir d'autres choses sur mon écran 5/4

[Katyucha]

Envoyé par GLDavid

Bonjour,

Voici la règle stupide de notre département: programmer obligatoirement en C#.

@++

J'ai l'impression qu'on bosse dans la même boite... même si je sais que c'est faux
Les boites où le langage est imposé, cela me fait rire... Qu'on essaye de priorisé le plus maitrisé => OK. Mais chaque langage a un domaine de prédilection


PS personnel : coucou GLDavid !! ca fait un bail !

[CinePhil]

Envoyé par Katyucha

Je ne réponds ni aux messages privées, ni aux messages plein de fautes...

Et à ceux qui font des fautes dans leur signature ?

[Katyucha]

Envoyé par CinePhil

Et à ceux qui font des fautes dans leur signature ?

Cette faute est historique, je crois qu'elle date depuis le passage de ce forum en vBulletin

FIN du HS

[Troudhyl]

Envoyé par Barsy

De même, dans un autre topic (il y a fort longtemps), quelqu'un se plaignait qu'on lui impose d'écrire "if (monBooléen == true)" au lieu de juste "if (monBooléen)" (et normalement il faut écrire "if (true == monBooléen)").

Pourquoi ? Je ne connais pas cette "règle" mais je l'observe souvent...
Comme règle casse-pied j'allais justement citer le fait de préciser tout le temps == true ou == false au lieu de ne rien mettre ou juste '!'. Pareil pour les tests de pointeurs, rajouter != 0 ou != NULL, c'est lourd...
En Qt, les nom de fonction contiennent le verbe. Par exemple : string.isEmpty(). Donc if (string.isEmpty()) est déjà une phrase. Mais on m'impose d'écrire if (string.isEmpty() == true), ce qui demande plus de concentration pour le lire.

[Médinoc]

Pour le "Single Entry, Single Exit" (alias "pas de return multiples") je dirais que ça dépend des circonstances: Contexte d'utilisation, outils disponibles dans le langage (notamment, présence ou non de destructeurs ou ramasse-miettes) et présence de ressources allouées.

Je ne vois aucun problème pour mettre des return sur la validation des paramètres en début de fonction: À ce stade la fonction n'est pas censé avoir alloué ou ouvert quoi que ce soit. Ensuite, des fonctions qui ne font aucune allocation, comme une fonction de recherche dans une liste, peuvent tirer parti d'un return dès que l'objet recherché est trouvé.

En gros, je dirais que le return au beau milieu d'une fonction est à bannir dès qu'il doit être accompagné d'un nettoyage:

Code C mauvais :

1
2
3
4
if(condition) {
	free(data);
	return;
}

À noter que dans certains cas dans des langages comme le C, il peut être avantageusement remplacé par un goto: Si toutes les variables sont correctement initialisées lors de leur déclaration, un "goto cleanup" peut rendre une fonction plus lisible qu'un code "boomerang".
Bien sûr, en C++ on utilisera des destructeurs à la place.

Envoyé par Troudhyl

Comme règle casse-pied j'allais justement citer le fait de préciser tout le temps == true ou == false au lieu de ne rien mettre ou juste '!'. Pareil pour les tests de pointeurs, rajouter "!= 0" ou "!= NULL", c'est lourd...

Autant pour les booléens je suis d'accord, autant pour les pointeurs j'ai fini par changer d'avis après quelques années. À présent j'apprécie les langages où les if n'acceptent que le type booléen (sauf quand il s'agit de faire des tests de flags sur des enums, mais .Net 4.0 3.5 4.0 a résolu ce problème-là).

[SurferIX]

Envoyé par abriotde

Pour l'indentation, il y a bien plus inteligent et souple : la tabulation. Ainsi en changeant le nombre d'espace d'une tabulation, chacun adapte le formatage. Deplus, à taper c'est plus rapide (ne serais-ce que pour éffacer 3*3=9 espaces= 3 tabulation ). Dans les codes indenté par des espaces vous remarquerez qu'ils sont toujours mal indenté car à un moment on à rajouté des espaces au pif.

C'est exactement l'inverse en pratique : un dev a appuyé trois fois sur tab et la parenthèse se situe pile poil aligné avec le code du dessus et l'autre dev qui affichera le même code avec une tabulation de 2 au lieu de 4 verra une le code décalé et par conséquent beaucoup moins lisible. Alors qu'avec des espaces, dans tous les cas, on l'a mis à un endroit, et sur tous les ordis, ça apparaît au même endroit.

Envoyé par abriotde

Je travaille beaucoup en directement en prod sous VIM qui ne rajoute pas automatiquement les espaces mais qui permet d'indenter rapidement le code en tabulation.

Pareil. Dan mon .vimrc :

set expandtab
set tabstop=4
set shiftwidth=4

Comme ça en appuyant sur tab ça fait ce que tu décris (= une fois sur tab), ça décale de 4 et en plus au lieu d'un caractère tabulation ce sont des espaces !

[LooserBoy]

Envoyé par Troudhyl

Pourquoi ? Je ne connais pas cette "règle" mais je l'observe souvent...
Comme règle casse-pied j'allais justement citer le fait de préciser tout le temps == true ou == false au lieu de ne rien mettre ou juste '!'. Pareil pour les tests de pointeurs, rajouter "!= 0" ou "!= NULL", c'est lourd...

Selon le langage et/ou le compilateur initialement utilisé lors de la mise en place des règles de codage en entreprise, la syntaxe "If(monBooleen)" n’existait pas forcément.

Mon premier poste de dév avait des règles de codage (langages C++ puis .Net 1.1) qui dataient de mathusalem, utilisaient la notation hongroise et exigeaient qu'on explicite les tests de booléens avec un ordre dans le test ( "If(true == monBooleen)" ), entre autres,...

Comme ça a déjà été dit, les règles de codage sont discutables car établies dans un contexte particulier. Elles peuvent même devenir obsolètes mais être conservées pour des raisons évidentes d'homogénéité du code...

[SurferIX]

Envoyé par Troudhyl

Pourquoi ? Je ne connais pas cette "règle" mais je l'observe souvent...

C'est bien simple : sans vouloir remettre en cause ton expérience, cela vient des développeurs C (et je crois que le problème persiste même en Php) lorsqu'on fait les comparaisons :

Code :

1
2
3
if (mavariable=12) {
  code
}

est un code qui ne génère pas d'erreur, alors que le développeur voulait comparer. Et ce genre de problème a souvent généré des heures - inutiles - de débogague pour arriver à ce code :

Code :

1
2
3
if (mavariable==12) {
  code
}

La conclusion pratique : on met les constantes en premier :

Code :

1
2
3
if (12==mavariable) {
  code
}

Ainsi, en faisant ça, on ne peut pas écrire ce code, qui génère une erreur de compilation :

Code :

1
2
3
if (12=mavariable) {
  code
}

Conclusion : tous les développeurs qui veulent imposer cette pratique montrent principalement une chose : ils ont de longues heures de vol et de déboguage derrière eux !

Ensuite un autre problème surgit souvent : code classique (même vu en école d'ingénieur par un prof ) :

Code :

1
2
3
if (f=fopen("monfichier", "r")) {
   ...
}

Code qu'il faut absolument proscrire tout simplement parce que la valeur de retour peut être un succès = lecture ok, mais peut renvoyer "0" (= un entier) et donc ce code considère que ça n'a pas fonctionné, alors que si.

Le code "propre" et "fiable" est :

f=fopen("monfichier", "r");

Code :

1
2
3
if (f>=0) {
   ...
}

Même chose en Php : comparaison ternaire pour être sûr du type :

Code :

1
2
3
4
$f=fopen("monfichier", "r")
if ($f!==false) {
   ...
}

[Bluedeep]

Envoyé par SurferIX

C'est bien simple : sans vouloir remettre en cause ton expérience, cela vient des développeurs C (et je crois que le problème persiste même en Php) lorsqu'on fait les comparaisons :

En C# aussi, mais dans un seul cas, les booléens :

Code :

1
2
3
4
5
6
bool b = false;
if(b=true)
{
Console.WriteLine("Etonnant non ?");
}

avec un warning il est vrai.

[Troudhyl]

@SurferIX : Merci de l'explication, effectivement ça se tient Mais bon du coup on perd en lisibilité, je préfère mettre des espaces autour du == comme ça le signe important saute aux yeux.