IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Humour Informatique Discussion :

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

  1. #61
    Membre éclairé Avatar de rt15
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2005
    Messages
    262
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Octobre 2005
    Messages : 262
    Points : 665
    Points
    665
    Par défaut
    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 : 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
    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 : 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
    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 : 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
    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...

  2. #62
    Expert confirmé Avatar de Barsy
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    1 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 484
    Points : 5 277
    Points
    5 277
    Par défaut
    Citation Envoyé par _skip Voir le message
    Pour ce qui est des retours multiples, je trouve ceci tout à fait acceptable :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    public Service findService( String serviceName )
    {
       
        if(  isKnown( serviceName ) )
              return cache.lookup( serviceName);
        
       //create and register
       //(..) 
    
       return newService;
    }
    ou ceci :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    public void log( String message )
    {
         if(  message== null || message.length < 1) )
              return ;
     
         //(...)   
    }
    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...
    "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"

  3. #63
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    Septembre 2011
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Septembre 2011
    Messages : 13
    Points : 22
    Points
    22
    Par défaut
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    While(1)
    do
    {
    if(myFunction()) BREAK;
    }

  4. #64
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 044
    Points
    32 044
    Par défaut
    Citation Envoyé par Barsy Voir le message
    (.../...)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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  5. #65
    Expert confirmé Avatar de ManusDei
    Homme Profil pro
    vilain troll de l'UE
    Inscrit en
    Février 2010
    Messages
    1 619
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : vilain troll de l'UE

    Informations forums :
    Inscription : Février 2010
    Messages : 1 619
    Points : 4 350
    Points
    4 350
    Par défaut
    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).
    http://www.traducteur-sms.com/ On ne sait jamais quand il va servir, donc il faut toujours le garder sous la main

  6. #66
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    Novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2005
    Messages : 2 898
    Points : 7 752
    Points
    7 752
    Par défaut
    Citation Envoyé par Barsy Voir le message
    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.

  7. #67
    Membre émérite

    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 995
    Points : 2 528
    Points
    2 528
    Par défaut
    Citation Envoyé par Kaamo Voir le message
    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.

  8. #68
    Membre émérite

    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 995
    Points : 2 528
    Points
    2 528
    Par défaut
    Citation Envoyé par Lynix Voir le message
    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...

  9. #69
    Expert confirmé Avatar de Barsy
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    1 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 1 484
    Points : 5 277
    Points
    5 277
    Par défaut
    Citation Envoyé par _skip Voir le message
    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...
    "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"

  10. #70
    En attente de confirmation mail
    Profil pro
    Inscrit en
    Décembre 2010
    Messages
    555
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2010
    Messages : 555
    Points : 1 597
    Points
    1 597
    Par défaut
    À 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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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

  11. #71
    Expert confirmé
    Avatar de Katyucha
    Femme Profil pro
    DevUxSecScrumOps Full Stack Bullshit
    Inscrit en
    Mars 2004
    Messages
    3 287
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Irlande

    Informations professionnelles :
    Activité : DevUxSecScrumOps Full Stack Bullshit

    Informations forums :
    Inscription : Mars 2004
    Messages : 3 287
    Points : 5 075
    Points
    5 075
    Par défaut
    Citation Envoyé par GLDavid Voir le message
    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 !
    Grave urgent !!!

  12. #72
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 792
    Points : 34 013
    Points
    34 013
    Billets dans le blog
    14
    Par défaut
    Citation 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 ?
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  13. #73
    Expert confirmé
    Avatar de Katyucha
    Femme Profil pro
    DevUxSecScrumOps Full Stack Bullshit
    Inscrit en
    Mars 2004
    Messages
    3 287
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Irlande

    Informations professionnelles :
    Activité : DevUxSecScrumOps Full Stack Bullshit

    Informations forums :
    Inscription : Mars 2004
    Messages : 3 287
    Points : 5 075
    Points
    5 075
    Par défaut
    Citation Envoyé par CinePhil Voir le message
    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
    Grave urgent !!!

  14. #74
    Membre expérimenté

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2009
    Messages
    1 009
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2009
    Messages : 1 009
    Points : 1 738
    Points
    1 738
    Par défaut
    Citation Envoyé par Barsy Voir le message
    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.

  15. #75
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 518
    Points
    41 518
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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.

    Citation 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à).
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  16. #76
    Membre chevronné

    Homme Profil pro
    Mentaliste
    Inscrit en
    Mars 2008
    Messages
    872
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Mentaliste
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2008
    Messages : 872
    Points : 1 813
    Points
    1 813
    Par défaut
    Citation Envoyé par abriotde Voir le message
    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.

    Citation Envoyé par abriotde Voir le message
    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 !

    .I..

  17. #77
    Membre chevronné Avatar de LooserBoy
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2005
    Messages
    1 085
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2005
    Messages : 1 085
    Points : 1 976
    Points
    1 976
    Par défaut
    Citation Envoyé par Troudhyl Voir le message
    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...
    Vu sur un paquet de cigarettes: "Fumer peut entrainer une mort lente et douloureuse"
    - Vivre aussi... Ce n'est pas forcément moins douloureux et c'est même beaucoup plus lent...

  18. #78
    Membre chevronné

    Homme Profil pro
    Mentaliste
    Inscrit en
    Mars 2008
    Messages
    872
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Mentaliste
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2008
    Messages : 872
    Points : 1 813
    Points
    1 813
    Par défaut
    Citation Envoyé par Troudhyl Voir le message
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    if (mavariable==12) {
      code
    }
    La conclusion pratique : on met les constantes en premier :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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");

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

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    $f=fopen("monfichier", "r")
    if ($f!==false) {
       ...
    }
    .I..

  19. #79
    Inactif  
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Janvier 2007
    Messages
    6 604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : Janvier 2007
    Messages : 6 604
    Points : 13 314
    Points
    13 314
    Par défaut
    Citation Envoyé par SurferIX Voir le message
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    bool b = false;
    if(b=true)
    {
    Console.WriteLine("Etonnant non ?");
    }
    avec un warning il est vrai.

    Je ne réponds pas aux questions techniques par MP ! Le forum est là pour ça...


    Une réponse vous a aidé ? utiliser le bouton

    "L’ennui dans ce monde, c’est que les idiots sont sûrs d’eux et les gens sensés pleins de doutes". B. Russel

  20. #80
    Membre expérimenté

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2009
    Messages
    1 009
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2009
    Messages : 1 009
    Points : 1 738
    Points
    1 738
    Par défaut
    @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.

Discussions similaires

  1. Réponses: 48
    Dernier message: 07/12/2010, 17h44
  2. Réponses: 48
    Dernier message: 07/12/2010, 17h44
  3. Réponses: 14
    Dernier message: 13/08/2010, 11h14
  4. [VBA-E]DatePart ? Quelle est la règle ?
    Par ouskel'n'or dans le forum Macros et VBA Excel
    Réponses: 4
    Dernier message: 12/05/2010, 13h17

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo