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. #21
    Membre actif Avatar de NevilClavain
    Homme Profil pro
    Ingé logiciel
    Inscrit en
    Septembre 2009
    Messages
    68
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingé logiciel
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2009
    Messages : 68
    Points : 214
    Points
    214
    Par défaut
    ha oui par contre la règle qui consiste à nommer les variables en fonction de leurs type (float, bool, int, gnagnagna); j'ai toujours trouvé ça complètement con. Ça n'apporte strictement rien, à part faire des noms de variables à coucher dehors.

  2. #22
    Membre habitué
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Février 2009
    Messages
    141
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2009
    Messages : 141
    Points : 195
    Points
    195
    Par défaut
    J'ai également oublié l'interdiction du mot-clé "break" car "ce n'est pas une façon propre de sortir de la boucle"

  3. #23
    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 SylvainPV Voir le message
    Les retours multiples, c'est comme son nom l'indique lorsqu'une fonction a plusieurs instructions return à l'intérieur de structures conditionnelles.
    Je ne trouve pas ça stupide de l'interdire. Personnellement, je le fait aussi. Lorsque j'ai une méthode qui retourne une valeur, par exemple un int, je commence ma méthode par "int result" et je la termine par "return result". Et je ne mets pas d'autres "return" au milieu.

    Ça permet d'éviter d'avoir des fonctions avec des "return" planqués, des fonctions avec du code mort situé après un "return". Personnellement, c'est le genre de règle que j'applique constamment.

    Citation Envoyé par SylvainPV Voir le message
    Sinon la règle de codage la plus étrange que j'ai eu fût de ne pas dépasser 80 caractères à chaque ligne (espaces d'indentation compris !). Parfois on été obligés de passer un argument de fonction par ligne, même s'il n'y en avait qu'un seul
    Ça non plus ce n'est pas forcément idiot. Combien de fois on voit du code avec des lignes de 500 caractères qui imposent un scroll horizontal. Après, il faut adapter la taille des lignes en fonction des écrans des développeurs. 80 caractères c'est court, sur mon dernier projet on avait imposer 200 caractères maximum.

    C'est ainsi qu'on se rend compte que des règles qui semblent étranges à certains peuvent aller de soit pour d'autres. Par exemple le préfixage des variables, je ne l'ai jamais fait, mais je peux comprendre la raison qui poussent certains à l'appliquer.
    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)"). Pour ça aussi je peux comprendre qu'il y en ait qui l'impose.

    Bref, les règles de codage, je pense que peut importe qu'elles semblent stupide ou non, le principal c'est que tout le monde utilise les mêmes.
    "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"

  4. #24
    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 NevilClavain Voir le message
    ha oui par contre la règle qui consiste à nommer les variables en fonction de leurs type (float, bool, int, gnagnagna); j'ai toujours trouvé ça complètement con. Ça n'apporte strictement rien, à part faire des noms de variables à coucher dehors.
    Notation hongroise dans sa variante "System"; on a déjà débattu de cela; ça n'a en effet aucun sens avec les langages OO. La notation hongroise en variante "Apps" peut néanmoins se justifier dans certains cas.

    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

  5. #25
    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 NevilClavain Voir le message
    l’imposition d’un nombre d’espaces pour l’indentation c'est pas si débile que ça, parce que mettre un caractère TAB ça peut potentiellement foutre un bordel monstre quand on trimbale les sources d'un éditeur à l'autre (cas des applis multi-plateforme)
    A priori tous les IDE permettent le paramétrage du nombre d'espace "écran" associés à un caractère "tab", non ?

    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

  6. #26
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    Décembre 2011
    Messages
    1 320
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : Décembre 2011
    Messages : 1 320
    Points : 3 740
    Points
    3 740
    Billets dans le blog
    12
    Par défaut
    Deuxième page et aucune référence à Jenkins pour l'intégration continue et les conventions d'écriture
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  7. #27
    Membre expert Avatar de air-dex
    Homme Profil pro
    Inscrit en
    Août 2010
    Messages
    1 653
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations forums :
    Inscription : Août 2010
    Messages : 1 653
    Points : 3 773
    Points
    3 773
    Par défaut
    Citation Envoyé par Melem Voir le message
    En général, je suis plutôt pour cette interdiction. Notamment en langage C. Comapez les codes suivants :
    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
    int do_stuff(void) {
        int ret = 0;
        type1_t *p1 = type1_new();
     
        if (!p1) {
            ret = -1;
        } else {
            type2_t *p2 = type2_new();
     
            if (!p2) {
                ret = -2;
            } else {
                now_do_useful_stuff();
     
                type2_delete(&p2);
            }
     
            type1_delete(&p1);        
        }
     
        return ret;
    }
    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
    int do_stuff(void) {
        type1_t *p1 = type1_new();
     
        if (!p1) {
            return -1;
        }
     
        type2_t *p2 = type2_new();
     
        if (!p2) {
            type1_delete(&p1);
            return -2;
        }
     
        now_do_useful_stuff();
     
        type2_delete(&p2);
        type1_delete(&p1);        
    }

    Dans la deuxième version, avec retours multiples, type1_delete est appelée à deux endroits différents. Il y a donc une mauvaise factorisation du code. Et plus on a des allocations, plus les répétitions seront nombreuses. Et ce nombre augmente aussi avec le nombre de points de retour dans la fonction. Car il faut faire le nettoyage avant chaque return. En général. En clair, il vaut mieux bannir les retours multiples. L'exception est peut-être lorsqu'on implémente un algo déjà bien connu. Dans les autres cas, je recommande l'utilisation d'un seul retour.
    Il y a aussi la lisibilité du code à prendre en compte. Et dans ce cas la deuxième version est bien plus indiquée. Et puis l'exemple ne prend pas en exemple les niveaux d'indentation de now_do_useful_stuff(); à prendre en compte. Si t'as envie de te retrouver avec du code de now_do_useful_stuff(); en quasi alignement à droite sur ton IDE, c'est ton problème . En attendant je préfère personnellement garder mon code lisible, à gauche dans l'IDE et lutter contre cette "programmation boomerang" * en ayant des retours multiples.


    Citation Envoyé par Melem Voir le message
    Sinon, pour les règles de codage bizarres que l'on a m'a déjà imposées, l'else if de la sorte :
    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    if (condition1) {
        action1();
    } else
    if (condition2) {
        action2();
    } else {
        action_par_defaut();
    }
    Tout le monde met else et if sur la même ligne quand même .
    À la limite, dans du code pas nettoyé ou pas optimisé, ceci peut-être acceptable :
    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    if (condition1) {
        action1();
    } else {
        if (condition2) {
            action2();
        } else {
            action_par_defaut();
        }
    }
    Mais pas en dehors.


    * : "programmation boomerang" est une référence au niveau d'indentation croissant puis décroissant du code dû aux boucles, formant ainsi une ligne (brisée) dont la forme évoque celle d'un boomerang. Le premier code de Melem permet de voir cela.
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

  8. #28
    Membre actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2008
    Messages
    132
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Septembre 2008
    Messages : 132
    Points : 290
    Points
    290
    Par défaut
    Citation Envoyé par NevilClavain Voir le message
    ha oui par contre la règle qui consiste à nommer les variables en fonction de leurs type (float, bool, int, gnagnagna); j'ai toujours trouvé ça complètement con. Ça n'apporte strictement rien, à part faire des noms de variables à coucher dehors.
    Oui d'accord de manière générale,sauf si t'as la malheureuse expérience de développer avec un langage non typé style PHP orienté objet (par exemple), il y a des cas, si tu n'explicite le type dans le nom de la variable, si tu relis ton code quelques semaines plus tard, tu peux perdre pas mal de temps avant d'être à l'aise avec ton module ou même une simple classe

  9. #29
    Rédacteur/Modérateur
    Avatar de andry.aime
    Homme Profil pro
    Inscrit en
    Septembre 2007
    Messages
    8 391
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Ile Maurice

    Informations forums :
    Inscription : Septembre 2007
    Messages : 8 391
    Points : 15 059
    Points
    15 059
    Par défaut
    En java, l'utilisation de retour multiple est déconseillée par le "Code Convention". D'ailleurs, ça me rappelle un bug, au lieu d'utiliser un "break" pour quitter une boucle, le développeur à utiliser un return qui lui a éjecté de la fonction qui retourne un void .

    Pour le Code Style, on a l'habitude de créer un Template dans eclipse et on le partage pour tous les développeurs.

    Quelles règles de codage étranges avez-vous dû suivre ?
    On ne nous a pas laissé un tag auto-fermante pour déclarer des beans ou des propriétés des beans dans un fichier de configuration de spring.
    Utiliser
    Code xml : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    <bean id="id1" class="com.package.class1">
    </bean>
    <bean id="id2" class="com.package.class2">
    	<property name="id1" ref="id1"></property>
    </bean>
    à la place de
    Code xml : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    <bean id="id1" class="com.package.class1" />
    <bean id="id2" class="com.package.class2">
    	<property name="id1" ref="id1" />
    </bean>


  10. #30
    Expert confirmé
    Homme Profil pro
    Inscrit en
    Février 2003
    Messages
    2 177
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Belgique

    Informations forums :
    Inscription : Février 2003
    Messages : 2 177
    Points : 4 489
    Points
    4 489
    Par défaut
    Perso je trouve plus lisible des return au début et au milieu que de s'amuser a vérifier si ma fonction fait encore quelque chose.
    Je ne suis qu'un pauvre débutant alors ne frappez pas si mes idées ne sont pas bonnes

  11. #31
    Membre chevronné
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2007
    Messages
    884
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Juillet 2007
    Messages : 884
    Points : 2 018
    Points
    2 018
    Par défaut Indentation
    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. 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.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  12. #32
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    Août 2003
    Messages
    6 690
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : Août 2003
    Messages : 6 690
    Points : 20 211
    Points
    20 211
    Par défaut
    Citation Envoyé par SylvainPV Voir le message

    Sinon la règle de codage la plus étrange que j'ai eu fût de ne pas dépasser 80 caractères à chaque ligne (espaces d'indentation compris !). Parfois on été obligés de passer un argument de fonction par ligne, même s'il n'y en avait qu'un seul
    C'est un héritage historique des cartes perforées d'IBM qui avaient 80 colonnes.

    Ensuite y se trouve que les vrais barbus sont bien connus pour encore coder sous vi sur un écran de 14 pouces , du coup les 80 caractères on encore du sens.

    Plus qu'un nombre de caractères je pense qu'il faut absolument éviter le scroll horizontal et si possible éviter de devoir déplacer son regard de gauche à droite sans cesse pour lire un code.
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  13. #33
    Membre chevronné
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2007
    Messages
    884
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Juillet 2007
    Messages : 884
    Points : 2 018
    Points
    2 018
    Par défaut
    Citation Envoyé par air-dex Voir le message

    À la limite, dans du code pas nettoyé ou pas optimisé, ceci peut-être acceptable :
    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    if (condition1) {
        action1();
    } else {
        if (condition2) {
            action2();
        } else {
            action_par_defaut();
        }
    }
    Mais pas en dehors.
    Code : 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
    int do_stuff(void) {
        int ret=0;
        type1_t *p1 = type1_new();
     
        if (!p1) {
            ret=-1;
        }
     
        type2_t *p2 = type2_new();
     
        if (!p2) {
            type1_delete(&p1);
            ret=-2;
        }
        if(ret=0){
          now_do_useful_stuff();
          type2_delete(&p2);
          type1_delete(&p1);        
        }
        return ret;
    }
    Avoir un seul return en fin clarifie parfois le code. Dans notre cas ou se sont juste de petits tests de conditions initial ce n'est pas justifier. Mais il faut éviter de multiplier ces return partout. Une solution : une variable que l'on ajoute comme ici. On évite le code boomerang.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  14. #34
    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
    Je ne trouve pas ça stupide de l'interdire. Personnellement, je le fait aussi. Lorsque j'ai une méthode qui retourne une valeur, par exemple un int, je commence ma méthode par "int result" et je la termine par "return result". Et je ne mets pas d'autres "return" au milieu.

    Ça permet d'éviter d'avoir des fonctions avec des "return" planqués, des fonctions avec du code mort situé après un "return". Personnellement, c'est le genre de règle que j'applique constamment.
    Comme quoi les points de vue peuvent changer d'une personne à l'autre.

    Perso je déclare les variables au moment où cela devient nécessaire en règle général. Par conséquent, en aucun cas je ne déclare une return value en début de la fonction en comptant sur le code qui suit pour la "garnir" convenablement. Sauf si la construction l'impose.

    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 ;
     
         //(...)   
    }
    Pourquoi?
    Parce que cela décrit suffisamment bien le comportement de la fonction. Je ne parle pas de planter 36 return au milieu d'une ribambelle de if( else if() ).
    L'important c'est que le travail de la méthode soit le plus lisible possible à la relecture, et pour ça il est parfois plus simple de l'imaginer comme une autoroute sur laquelle tu prends la première sortie si tu vois le bon panneau (où si tu réalises que t'es pas sur le bon chemin)..

  15. #35
    Membre expérimenté
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2011
    Messages
    576
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : Mars 2011
    Messages : 576
    Points : 1 527
    Points
    1 527
    Par défaut
    Fraichement embauché sur un produit codé par des générations de stagiaires, j'ai voulu mettre en place des conventions de codage et un semblant d'architecture pour harmoniser tout ça. Le chef de projet m'a répondu que la seul règle à suivre était de ne pas utiliser de convention de codage car "ça frustre le développeur et lui fait perdre son temps. Tu débute et moi j'ai 20 ans d'expérience alors crois moi quand je te dis que ça sert à rien !".
    Résultat, un code illisible mélangeant a peu près tout ce qu'on peu trouver...

    Je suis partir au bout de 3 mois et la boite à coulé 6 mois après...

    Sinon dans le genre règle pas vraiment stupide mais un peu lourdingue, obligation de toujours mettre un else après un if. On se retrouve alors avec ça un peu partout:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    if ( toto )
    {
      [...]
    }
    else
    {
      // NOTHING
    }
    La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer. - Antoine de Saint-Exupéry

  16. #36
    Membre actif Avatar de NevilClavain
    Homme Profil pro
    Ingé logiciel
    Inscrit en
    Septembre 2009
    Messages
    68
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingé logiciel
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2009
    Messages : 68
    Points : 214
    Points
    214
    Par défaut
    Citation Envoyé par Bluedeep Voir le message
    A priori tous les IDE permettent le paramétrage du nombre d'espace "écran" associés à un caractère "tab", non ?
    Moui, encore faut il avoir le réflexe de le faire AU DEBUT du projet, pas quand on en est à 100000 lignes/150 fichiers sources

  17. #37
    Membre actif Avatar de NevilClavain
    Homme Profil pro
    Ingé logiciel
    Inscrit en
    Septembre 2009
    Messages
    68
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingé logiciel
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2009
    Messages : 68
    Points : 214
    Points
    214
    Par défaut
    Citation Envoyé par pyros Voir le message
    Sinon dans le genre règle pas vraiment stupide mais un peu lourdingue, obligation de toujours mettre un else après un if. On se retrouve alors avec ça un peu partout:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    if ( toto )
    {
      [...]
    }
    else
    {
      // NOTHING
    }
    L'idée derrière cette règle c'est de mettre au moins une trace dans le else (ne serait-ce qu'un std::cout) pour voir quand tu tombes dans ce cas précis, ça peut te faire gagner un temps précieux de recherche. Juste mettre un commentaire NOTHING effectivement c'est lourdingue et surtout ça sert à rien...

  18. #38
    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
    une règle parmi les plus étranges que j'ai eu est la suivante : en cobol, pas de GO TO, sauf GO TO FIN-DE-PARAGRAPHE en cas d'erreur. Une espèce de break, quoi.

    L'idée sous-jacente est de retirer un niveau d'indentation :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    PARAGRAPHE.
        IF MONTANT NOT NUMERIC
           GO TO FIN-DE-PARAGRAPHE
        END IF
        blablabla...
        .
    FIN-DE-PARAGRAPHE.
    au lieu de

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    PARAGRAPHE.
        IF MONTANT NOT NUMERIC
           CONTINUE
        ELSE
           blablabla...
        END IF
    .
    FIN-DE-PARAGRAPHE.
    ça a son utilité, surtout si blablabla... est fort verbeuse. Mais on peut toujours faire autrement, par exemple en gérant un sous-paragraphe qui ne fait que blablabla. A l'époque, j'avais appréçié, mais j'en suis revenu. Même si je le tolère désormais chez les autres.


    Dans les langages modernes, le return multiple peut avoir son utilité, mais quand il passe entre de mauvaises mains, provoque assez vite des horreurs. Mon expérience, c'est qu'un code de production pérènne finit toujours par passer entre de mauvaises mains.

    Enfin, je dirais que mieux vaut un mauvais standard appliqué par tous, qu'un mélange de bons standards incompatibles entre eux.
    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.

  19. #39
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 549
    Points : 15 450
    Points
    15 450
    Par défaut
    Citation Envoyé par NevilClavain Voir le message
    Moui, encore faut il avoir le réflexe de le faire AU DEBUT du projet, pas quand on en est à 100000 lignes/150 fichiers sources
    Au contraire, tout l’intérêt d'indenter proprement avec des tabulation, c'est qu'on peut changer ça à n'importe quel moment sans que ça ait le moindre impact.
    Tout le monde peut régler la taille des tabulation à la valeur qu'il souhaite personnellement sans impacter les autres.

  20. #40
    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
    L'obligation de commencer mes requêtes SQL... Même pour 2 lignes, je crois que ce fut un moment de solitude...
    Grave urgent !!!

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