Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 2 sur 10 PremièrePremière 123456 ... DernièreDernière
Affichage des résultats 21 à 40 sur 185
  1. #21
    Membre habitué Avatar de NevilClavain
    Homme Profil pro
    Ingé logiciel
    Inscrit en
    septembre 2009
    Messages
    52
    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 : 52
    Points : 117
    Points
    117

    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 Jérôme Leclercq
    Développeur de jeux vidéo
    Inscrit en
    février 2009
    Messages
    132
    Détails du profil
    Informations personnelles :
    Nom : Homme Jérôme Leclercq
    Localisation : Belgique

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

    Informations forums :
    Inscription : février 2009
    Messages : 132
    Points : 106
    Points
    106

    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 Sylvain
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    1 362
    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 362
    Points : 3 537
    Points
    3 537

    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 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 : 12 114
    Points
    12 114

    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.

  5. #25
    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 : 12 114
    Points
    12 114

    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 ?

  6. #26
    Membre émérite Avatar de Gugelhupf
    Homme Profil pro
    Développeur informatique
    Inscrit en
    décembre 2011
    Messages
    579
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2011
    Messages : 579
    Points : 890
    Points
    890

    Par défaut

    Deuxième page et aucune référence à Jenkins pour l'intégration continue et les conventions d'écriture

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

    Informations forums :
    Inscription : août 2010
    Messages : 1 051
    Points : 2 053
    Points
    2 053

    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 :
    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 :
    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 :
    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 :
    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 confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2008
    Messages
    125
    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 : 125
    Points : 225
    Points
    225

    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 Andry Aimé
    Inscrit en
    septembre 2007
    Messages
    7 092
    Détails du profil
    Informations personnelles :
    Nom : Homme Andry Aimé
    Localisation : Ile Maurice

    Informations forums :
    Inscription : septembre 2007
    Messages : 7 092
    Points : 11 102
    Points
    11 102

    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 :
    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 :
    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 Benoît
    Inscrit en
    février 2003
    Messages
    1 729
    Détails du profil
    Informations personnelles :
    Nom : Homme Benoît
    Âge : 33
    Localisation : Belgique

    Informations forums :
    Inscription : février 2003
    Messages : 1 729
    Points : 2 585
    Points
    2 585

    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 confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    252
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    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 : 252
    Points : 242
    Points
    242

    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.

  12. #32
    Modérateur
    Avatar de grunk
    Homme Profil pro Olivier
    Dév. Web / Android
    Inscrit en
    août 2003
    Messages
    3 076
    Détails du profil
    Informations personnelles :
    Nom : Homme Olivier
    Âge : 30
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Dév. Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 3 076
    Points : 6 879
    Points
    6 879

    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

  13. #33
    Membre confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    252
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    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 : 252
    Points : 242
    Points
    242

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

  14. #34
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 712
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    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 712
    Points : 6 304
    Points
    6 304

    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 :
    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 ;
     
         //(...)   
    }
    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 Expert
    Homme Profil pro
    Inscrit en
    mars 2011
    Messages
    542
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : mars 2011
    Messages : 542
    Points : 1 040
    Points
    1 040

    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 :
    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 habitué Avatar de NevilClavain
    Homme Profil pro
    Ingé logiciel
    Inscrit en
    septembre 2009
    Messages
    52
    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 : 52
    Points : 117
    Points
    117

    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 habitué Avatar de NevilClavain
    Homme Profil pro
    Ingé logiciel
    Inscrit en
    septembre 2009
    Messages
    52
    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 : 52
    Points : 117
    Points
    117

    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 :
    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 Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 139
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 139
    Points : 9 161
    Points
    9 161

    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 :
    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 :
    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 Confirmé Sénior Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 043
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 043
    Points : 5 930
    Points
    5 930

    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é Sénior
    Avatar de Katyucha
    Profil pro
    Ingénieur systèmes Linux/Unix/SAN
    Inscrit en
    mars 2004
    Messages
    3 264
    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 264
    Points : 4 748
    Points
    4 748

    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...
    Ancien Rédacteur Linux && Unix / Nouveau retraité de DVP
    "En face, c'est des c**s, alors au premier regroupement, il faut qu'ils discutent avec les taupes."

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

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
  •