Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 4 sur 10 PremièrePremière 12345678 ... DernièreDernière
Affichage des résultats 61 à 80 sur 185
  1. #61
    Membre éprouvé Avatar de rt15
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2005
    Messages
    208
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : octobre 2005
    Messages : 208
    Points : 441
    Points
    441

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

  2. #62
    Expert Confirmé Avatar de Barsy
    Homme Profil pro Sylvain
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    1 377
    Détails du profil
    Informations personnelles :
    Nom : Homme Sylvain
    Âge : 31
    Localisation : France, Loire Atlantique (Pays de la Loire)

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

    Informations forums :
    Inscription : octobre 2007
    Messages : 1 377
    Points : 3 787
    Points
    3 787

    Par défaut

    Citation Envoyé par _skip Voir le message
    Pour ce qui est des retours multiples, je trouve ceci tout à fait acceptable :

    Code :
    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 :
    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
    Invité de passage
    Homme Profil pro
    Inscrit en
    septembre 2011
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : septembre 2011
    Messages : 10
    Points : 1
    Points
    1

    Par défaut

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

  4. #64
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 153
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 153
    Points : 10 343
    Points
    10 343

    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
    esclave du Grand Capital
    Inscrit en
    février 2010
    Messages
    1 276
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France

    Informations professionnelles :
    Activité : esclave du Grand Capital

    Informations forums :
    Inscription : février 2010
    Messages : 1 276
    Points : 2 904
    Points
    2 904

    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 Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 720
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    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 720
    Points : 6 875
    Points
    6 875

    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
    Expert Confirmé Sénior

    Inscrit en
    décembre 2003
    Messages
    2 819
    Détails du profil
    Informations forums :
    Inscription : décembre 2003
    Messages : 2 819
    Points : 6 812
    Points
    6 812

    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.
    Les brevets ? Le type qui a inventé l'eau chaude doit être grave blindé de thunes !

  8. #68
    Expert Confirmé Sénior

    Inscrit en
    décembre 2003
    Messages
    2 819
    Détails du profil
    Informations forums :
    Inscription : décembre 2003
    Messages : 2 819
    Points : 6 812
    Points
    6 812

    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...
    Les brevets ? Le type qui a inventé l'eau chaude doit être grave blindé de thunes !

  9. #69
    Expert Confirmé Avatar de Barsy
    Homme Profil pro Sylvain
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    1 377
    Détails du profil
    Informations personnelles :
    Nom : Homme Sylvain
    Âge : 31
    Localisation : France, Loire Atlantique (Pays de la Loire)

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

    Informations forums :
    Inscription : octobre 2007
    Messages : 1 377
    Points : 3 787
    Points
    3 787

    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
    Membre Expert Avatar de Squisqui
    Inscrit en
    décembre 2010
    Messages
    359
    Détails du profil
    Informations forums :
    Inscription : décembre 2010
    Messages : 359
    Points : 1 020
    Points
    1 020

    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 :
    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é Sénior
    Avatar de Katyucha
    Profil pro
    Ingénieur systèmes Linux/Unix/SAN
    Inscrit en
    mars 2004
    Messages
    3 275
    Détails du profil
    Informations personnelles :
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Ingénieur systèmes Linux/Unix/SAN

    Informations forums :
    Inscription : mars 2004
    Messages : 3 275
    Points : 5 300
    Points
    5 300

    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 Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 820
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    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 : 13 820
    Points : 24 813
    Points
    24 813

    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 de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « 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é Sénior
    Avatar de Katyucha
    Profil pro
    Ingénieur systèmes Linux/Unix/SAN
    Inscrit en
    mars 2004
    Messages
    3 275
    Détails du profil
    Informations personnelles :
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Ingénieur systèmes Linux/Unix/SAN

    Informations forums :
    Inscription : mars 2004
    Messages : 3 275
    Points : 5 300
    Points
    5 300

    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
    Modérateur

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

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

    Informations forums :
    Inscription : mai 2009
    Messages : 1 007
    Points : 1 701
    Points
    1 701

    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 Confirmé Sénior Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2005
    Messages
    24 164
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France

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

    Informations forums :
    Inscription : septembre 2005
    Messages : 24 164
    Points : 35 301
    Points
    35 301

    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 :
    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 Expert Avatar de SurferIX
    Homme Profil pro Olivier Pons
    Ingénieur développement logiciels
    Inscrit en
    mars 2008
    Messages
    455
    Détails du profil
    Informations personnelles :
    Nom : Homme Olivier Pons
    Âge : 40
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2008
    Messages : 455
    Points : 1 013
    Points
    1 013

    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 !

    "Ceci dit" est un non sens. Cf Wikipedia. C'est soit "cela dit", soit rien.
    Il ne faut pas oublier que la politesse et le respect sont mutuels.

    Dernières prestations de HQF Development:

  17. #77
    Membre Expert Avatar de LooserBoy
    Homme Profil pro Alexis Lechevalier
    Ingénieur développement logiciels
    Inscrit en
    février 2005
    Messages
    1 083
    Détails du profil
    Informations personnelles :
    Nom : Homme Alexis Lechevalier
    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 083
    Points : 1 868
    Points
    1 868

    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 Expert Avatar de SurferIX
    Homme Profil pro Olivier Pons
    Ingénieur développement logiciels
    Inscrit en
    mars 2008
    Messages
    455
    Détails du profil
    Informations personnelles :
    Nom : Homme Olivier Pons
    Âge : 40
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2008
    Messages : 455
    Points : 1 013
    Points
    1 013

    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 :
    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");

    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) {
       ...
    }
    "Ceci dit" est un non sens. Cf Wikipedia. C'est soit "cela dit", soit rien.
    Il ne faut pas oublier que la politesse et le respect sont mutuels.

    Dernières prestations de HQF Development:

  19. #79
    Inactif
    Homme Profil pro François
    Chef de projet NTIC
    Inscrit en
    janvier 2007
    Messages
    6 608
    Détails du profil
    Informations personnelles :
    Nom : Homme François
    Âge : 53
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : janvier 2007
    Messages : 6 608
    Points : 13 112
    Points
    13 112

    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 :
    1
    2
    3
    4
    5
    6
    bool b = false;
    if(b=true)
    {
    Console.WriteLine("Etonnant non ?");
    }
    avec un warning il est vrai.

  20. #80
    Modérateur

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

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

    Informations forums :
    Inscription : mai 2009
    Messages : 1 007
    Points : 1 701
    Points
    1 701

    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.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •