Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 5 sur 10 PremièrePremière 123456789 ... DernièreDernière
Affichage des résultats 81 à 100 sur 185
  1. #81
    Expert Confirmé
    Homme Profil pro Benoît
    Inscrit en
    février 2003
    Messages
    1 722
    Détails du profil
    Informations personnelles :
    Nom : Homme Benoît
    Âge : 33
    Localisation : Belgique

    Informations forums :
    Inscription : février 2003
    Messages : 1 722
    Points : 2 553
    Points
    2 553

    Par défaut

    Citation Envoyé par Bluedeep Voir le message
    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.
    bien la preuve qu'il faut écrire
    et non ou
    Je ne suis qu'un pauvre débutant alors ne frappez pas si mes idées ne sont pas bonnes

  2. #82
    Membre émérite Avatar de SurferIX
    Homme Profil pro Olivier Pons
    Ingénieur développement logiciels
    Inscrit en
    mars 2008
    Messages
    436
    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 : 436
    Points : 906
    Points
    906

    Par défaut

    Citation Envoyé par Bluedeep Voir le message
    En C# aussi, mais dans un seul cas, les booléens... avec un warning il est vrai.
    Tu as raison : j'ai oublié de préciser qu'il est possible (si je ne me trompe pas) d'activer une option qui affiche un warning pour les assignations lors des "if".
    "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:

  3. #83
    Membre éclairé Avatar de gb_68
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2006
    Messages
    201
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Haut Rhin (Alsace)

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

    Informations forums :
    Inscription : août 2006
    Messages : 201
    Points : 316
    Points
    316

    Par défaut

    Citation Envoyé par Médinoc Voir le message
    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.
    Exactement, pour moi le problème c'est quand on tente d'appliquer bêtement une convention de codage potentiellement bénéfique et bien adaptée à un langage (voire couple langage/IDE) à un autre où elle n'est plus utile, voire contre-productive, sans se poser les bonnes questions (quelles raisons ont poussé à définir cette règle ? sont elles encore d’actualités ?).

  4. #84
    Membre éclairé Avatar de rt15
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2005
    Messages
    203
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : octobre 2005
    Messages : 203
    Points : 384
    Points
    384

    Par défaut

    Citation Envoyé par SurferIX Voir le message
    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");

    Heu... C'est de l'humour j'espère. Ou alors c'est pas du C.
    Citation Envoyé par man
    S'il réussissent intégralement fopen, fdopen et freopen renvoient un pointeur sur un fichier, de type FILE. Sinon, ils renvoient NULL et errno contient le code d'erreur.
    Donc si le retour de fopen (Pointeur convertit en entier) est 0, souci, si le retour de fopen est différent de 0 tout va bien. Et le pointeur ne sera d'ailleurs probablement jamais négatif. En 32 bits, un pointeur est généralement considéré comme un unsigned int dans les comparaison. Donc (pointer >= 0) renvoie toujours vrai sur de nombreux compilos.

    Pour moi le code de ton prof est valide, et le tien non. Merci de confirmer ou contester ça.

    [edit]

    Code de test :

    Code :
    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
    #include <stdio.h>
    
    FILE* openInvalidFile()
    {
      return NULL;
    }
    
    FILE* openValidFile()
    {
      return (FILE*)-12;
    }
    
    int main()
    {
      FILE* f;
    
      if (f = openValidFile())
        printf("Fichier valide ouvert %d\n", f);
      else
        puts("Echec de l'ouverture d'un fichier valide");
    
      if (f = openInvalidFile())
        printf("Fichier invalide ouvert %d\n", f);
      else
        puts("Echec de l'ouverture d'un fichier invalide");
    
      f = openValidFile();
      if (f >= 0)
        printf("Fichier valide ouvert %d\n", f);
      else
        puts("Echec de l'ouverture d'un fichier valide");
     
      f = openValidFile();
      if (f >= 0)
        printf("Fichier invalide ouvert %d\n", f);
      else
        puts("Echec de l'ouverture d'un fichier invalide");
    
      return 1;
    }
    Résultat :
    Fichier valide ouvert -12
    Echec de l'ouverture d'un fichier invalide
    Fichier valide ouvert -12
    Fichier invalide ouvert -12

  5. #85
    Responsable Développement Web

    Avatar de Bovino
    Homme Profil pro Didier Mouronval
    Développeur Web
    Inscrit en
    juin 2008
    Messages
    21 960
    Détails du profil
    Informations personnelles :
    Nom : Homme Didier Mouronval
    Âge : 43
    Localisation : France, Gironde (Aquitaine)

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

    Informations forums :
    Inscription : juin 2008
    Messages : 21 960
    Points : 81 103
    Points
    81 103

    Par défaut

    Quelle est la règle de codage la plus étrange que vous avez été forcé de suivre ?
    Ne pas avoir le droit de créer de nouvelle base de donnée pour des activités différentes !

    Imaginons par exemple que nous ayons créé une base correspondant à des recettes de cuisine, avec les champs "ingrédients", "durée" et "opérations".
    On décide ensuite de créer un planning d'entrainement sportif, du coup, dans ce cas, "ingrédients" correspond à "type d'exercice", "durée" à "lieu" et "opérations" à "équipement". Seulement, comme il manque un champ pour "durée de l'exercice", alors on va utiliser le champ "ingrédients" en séparant la valeur "type d'exercice" et "durée de l'exercice" par un délimiteur arbitraire...

    Tout cela est parfaitement résumé dans cet article...
    Pas de question technique par MP !
    Tout le monde peut participer à developpez.com, vous avez une idée, contactez-moi !
    Mes formations video2brain : La formation complète sur JavaScriptJavaScript et le DOM par la pratiquePHP 5 et MySQL : les fondamentaux
    Mon livre sur jQuery
    Module Firefox / Chrome d'intégration de JSFiddle et CodePen sur le forum

  6. #86
    Expert Confirmé Sénior Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 028
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 028
    Points : 5 832
    Points
    5 832

    Par défaut

    Citation Envoyé par SurferIX Voir le message
    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");

    Non seulement :
    - le code que tu accuses d'être faux est tout à fait correct : fopen ne retourne NULL(soit 0) qu'en cas d'erreur. Si tu ne me crois pas, il suffit de consulter le man
    - la solution que tu proposes est incorrecte. Ton code ne gèrera pas les erreurs.

  7. #87
    Membre expérimenté
    Avatar de Glob
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    avril 2002
    Messages
    406
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Suisse

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : avril 2002
    Messages : 406
    Points : 518
    Points
    518

    Par défaut

    > en Java, mettre des getters/setters sur des DTO, et interdire la moindre "intelligence" dans ces getters/setters.

    Où est l'intérêt de ce genre de chose, alors qu'il suffit de laisser les attributs public?
    Glob
    All Hell Can't Stop Us Now!

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

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

    Informations forums :
    Inscription : octobre 2007
    Messages : 1 350
    Points : 3 474
    Points
    3 474

    Par défaut

    Citation Envoyé par BenoitM Voir le message
    bien la preuve qu'il faut écrire
    et non ou
    Enfin, dans tout les cas il faut écrire
    Code :
    if (maConstante == maVariable)
    et non l'inverse. Peut importe qu'il s'agisse de booléen, d'entiers ou autre. Et très souvent les développeurs écrivent l'inverse.

    Après, pour ce qui est de préciser à chaque fois "true" ou "false" quand on compare un booléen, chacun est juge, tant qu'il respecte la règle fixée sur le projet bien évidemment.

    Sinon, pour rester sur les booléens, voici une règle qui m'a semblé intéressante sur un précédent projet : Les booléens doivent toujours être écrits pour que la valeur "true" reflète un résultat positif. Par exemple, un booléen peut s'appeler "isConnected" mais pas "isNotConnected".
    Et c'est vrai qu'on tombe souvent sur des booléen négatifs dans les projets. Après, je ne pense pas que ce soit vital comme règle, mais ça peut faciliter la lecture du code je pense.
    "tatatatatatatatataaa !! tata taaa !! tata taaa !! tatatata tataaa !! tata taaa !! tata taaa !!"

  9. #89
    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 108
    Points
    12 108

    Par défaut

    Citation Envoyé par Barsy Voir le message
    Les booléens doivent toujours être écrits pour que la valeur "true" reflète un résultat positif. Par exemple, un booléen peut s'appeler "isConnected" mais pas "isNotConnected".
    Donc utiliser IsNotDisconnected c'est pas bon ?

  10. #90
    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 537
    Points
    1 537

    Par défaut

    Citation Envoyé par Barsy Voir le message
    Enfin, dans tout les cas il faut écrire
    Code :
    if (maConstante == maVariable)
    et non l'inverse. Peut importe qu'il s'agisse de booléen, d'entiers ou autre. Et très souvent les développeurs écrivent l'inverse.
    Effectivement, à moins d'être Yoda, je trouve qu'il est plus facile de lire d'abord l'élément sur lequel porte la comparaison (sujet)...

  11. #91
    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 108
    Points
    12 108

    Par défaut

    Citation Envoyé par Troudhyl Voir le message
    Effectivement, à moins d'être Yoda, je trouve qu'il est plus facile de lire d'abord l'élément sur lequel porte la comparaison (sujet)...
    Vers la gauche depuis la droite il suffit de lire , m'enfin
    D'être Yoda, point besoin il n'est.

  12. #92
    Rédacteur/Modérateur
    Avatar de Laurent.B
    Homme Profil pro Laurent Barbareau
    Ingénieur développement logiciels
    Inscrit en
    novembre 2004
    Messages
    3 228
    Détails du profil
    Informations personnelles :
    Nom : Homme Laurent Barbareau
    Âge : 41
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : novembre 2004
    Messages : 3 228
    Points : 14 735
    Points
    14 735

    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
    Sur certains outils tels qu'Eclipse, cela ne pose aucun problème de formater tout un projet après coup mais oui, il vaut mieux prévoir cela au début.

    Citation Envoyé par NevilClavain Voir le message
    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...
    La première idée de cette règle me semblerait plutôt de bien montrer que tu as pensé à l'alternative (dans certains domaines ça peut être une question vitale ou extrêmement importante). NOTHING n'est effectivement pas très explicite donc personnellement, quand je l'applique, je m'efforce de mettre un commentaire utile.

    Citation Envoyé par pyros Voir le message
    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...
    Celle-là je la mettrai dans le top 10 moi

    Citation Envoyé par fregolo52 Voir le message
    Je suis habitué au K&R et que je vois du Whitesmiths, j'ai un peu de mal.
    Article wikipédia sur les indentations du code.
    Effectivement, les accolades me paraissent vraiment incongrues placées comme ça...
    Merci pour le lien wikipedia

    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...
    Est-elle ou a-t-elle été développeuse sur des projets dans sa vie, ou c'est juste purement arbitraire de sa part ?

    Citation Envoyé par Bluedeep Voir le message
    Pour ma part, et sans hésiter, il y a de cela sept ou huit ans, un projet chez un client où le DBA ne voulait pas de procédure stockées ....
    Bon si ce n'est pas ironique, alors il faudra peut-être un jour que tu te penches sérieusement sur le sujet et peut-être comprendras-tu les raisons de cette phobie des procédures stockées. Il y en a plusieurs...

    Citation Envoyé par Troudhyl Voir le message
    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.
    Certes, la raison doit probablement être qu'il ne faut pas déroger à la règle d'indiquer le booléen que l'on teste mais dans ce cas précis, ça me semble effectivement très moyen, je compatis .

    Sinon, en Java, qu'est-ce vous pensez de l'utilisation d'un label avec un break pour sortir d'une boucle ?
    Code java :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
        protected boolean isContainingMainFile(File[] files)
        {
            boolean isInList = false;
     
            String documentFileName = projectName + ".xml";
     
            found: for (File file : files)
            {
                if (documentFileName.equals(file.getName()))
                {
                    isInList = true;
                    break found;
                }
            }
     
            return isInList;
        }
    C'est loin d'être clair lorsque l'on rencontre cette notation la première fois mais en ce qui me concerne, je considère que c'est une bonne pratique. C'est encore plus évident lorsque l'on a deux boucles imbriquées et que l'on veut pourvoir en sortir d'un seul coup.
    Quand j'utilise celle-ci, certaines personnes parviennent à comprendre son intérêt quand je leur explique et d'autres s'en offusquent (bêtement)... CheckStyle, PMD, et les autres ne s'en offusquent pas eux ^^
    Responsable FAQ Eclipse | Maintiens et développe un des logiciels destinés aux rédacteurs sur developpez.com
    Pensez à cliquer sur le bouton une fois votre problème solutionné, merci.

  13. #93
    Rédacteur/Modérateur
    Avatar de Laurent.B
    Homme Profil pro Laurent Barbareau
    Ingénieur développement logiciels
    Inscrit en
    novembre 2004
    Messages
    3 228
    Détails du profil
    Informations personnelles :
    Nom : Homme Laurent Barbareau
    Âge : 41
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : novembre 2004
    Messages : 3 228
    Points : 14 735
    Points
    14 735

    Par défaut

    Citation Envoyé par Glob Voir le message
    > en Java, mettre des getters/setters sur des DTO, et interdire la moindre "intelligence" dans ces getters/setters.

    Où est l'intérêt de ce genre de chose, alors qu'il suffit de laisser les attributs public?
    Oui, ça paraît moyen au premier abord mais la raison est que cela permet de la généricité dans les traitements de ce genre d'objets, notamment par réflexion ou même AOP. Le tout est de ne pas saisir à la main les getters/setters... Ca reste lourd, on est d'accord, faudra faire quelque chose un jour pour rendre cela plus efficace.
    Responsable FAQ Eclipse | Maintiens et développe un des logiciels destinés aux rédacteurs sur developpez.com
    Pensez à cliquer sur le bouton une fois votre problème solutionné, merci.

  14. #94
    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 108
    Points
    12 108

    Par défaut

    Citation Envoyé par fregolo52 Voir le message
    Heureusement que des langages comme python évite ce genre de dérive.

    Je suis habitué au K&R et que je vois du Whitesmiths, j'ai un peu de mal.
    Article wikipédia sur les indentations du code.
    Pour ma part, je trouve le K&R totalement incongru.

    C'est une mode apparue au début des années 80, liée historiquement aux contraintes de l'éditeur des systèmes Unix de l'époque, qui a eu le bon gout de disparaitre au début des 90' et que j'ai vu avec stupeur réapparaitre principalement chez les codeurs Javascript à la fin des 90' alors que la majorité des dev. C++ et Java ( et C# après) utilisaient le Allman (que pour ma part j'impose sur tous les développement - le refactoring d'aspect de VS permettant de ramener le code des égarés à la raison ).

  15. #95
    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 Laurent.B Voir le message
    Sur certains outils tels qu'Eclipse, cela ne pose aucun problème de formater tout un projet après coup mais oui, il vaut mieux prévoir cela au début.
    Haa ? j'ignorais qu'Eclipse permettait cela, merci pour l'info

  16. #96
    Expert Confirmé Avatar de Loceka
    Profil pro Tlouye Ci
    Inscrit en
    mars 2004
    Messages
    2 046
    Détails du profil
    Informations personnelles :
    Nom : Tlouye Ci

    Informations forums :
    Inscription : mars 2004
    Messages : 2 046
    Points : 3 723
    Points
    3 723

    Par défaut

    Les choix du type de parenthésage sont aussi trollifère que les choix d'indentation (voire plus), mais personnellement je préfère le parenthésage à la "Java" (proche du K&R apparement).
    Le parenthésage type Allman je trouve que c'est de la perte de place et du coup de lisibilité (on n'embrace pas tout le code d'un seul coup d'oeil) :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    int main(int argc, char *argv[]) {
        ...
        while (x == y) {
            something();
            somethingelse();
     
            if (some_error) {
                /* the curly braces around this code block could be omitted */
                do_correct();
            } else {
                continue_as_usual();
            }
        }
     
        finalthing();
        ...
    }
    vs

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    int main(int argc, char *argv[])
    {
        ...
        while (x == y)
        {
            something();
            somethingelse();
     
            if (some_error)
            {
                /* the curly braces around this code block could be omitted */
                do_correct();
            }
            else
            {
                continue_as_usual();
            }
        }
     
        finalthing();
        ...
    }

  17. #97
    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 108
    Points
    12 108

    Par défaut

    Citation Envoyé par Loceka Voir le message
    Les choix du type de parenthésage sont aussi trollifère que les choix d'indentation (voire plus), mais personnellement je préfère le parenthésage à la "Java" (proche du K&R apparement).
    Le parenthésage type Allman je trouve que c'est de la perte de place et du coup de lisibilité (on n'embrace pas tout le code d'un seul coup d'oeil)
    C'est en effet trollifère car pour ma part j'ai l'opinion exactement inverse sur la lisibilité

    Si le fait de embracer (c'est de l'anglais, mais il semble que le verbe existait en vieux français) le code d'un seul coup d'oeil (ou si on était payé à l'économie de lignes) était un argument recevable, les déclarations de variables devraient avoir cette forme :

    Code :
    int aVariable; string anotherVariable; double etcVariable;

  18. #98
    Membre expérimenté
    Avatar de Glob
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    avril 2002
    Messages
    406
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Suisse

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : avril 2002
    Messages : 406
    Points : 518
    Points
    518

    Par défaut

    Citation Envoyé par Laurent.B Voir le message
    Oui, ça paraît moyen au premier abord mais la raison est que cela permet de la généricité dans les traitements de ce genre d'objets, notamment par réflexion ou même AOP. Le tout est de ne pas saisir à la main les getters/setters... Ca reste lourd, on est d'accord, faudra faire quelque chose un jour pour rendre cela plus efficace.
    La réflexion fonctionne tout aussi bien sur des champs public que sur des méthodes. De plus, même si la génération des accessors peut être facilitée dans des IDE modernes comme Eclipse, ça reste lourd à la maintenance pour une plus-value qui reste chimérique.

    A+
    Glob
    All Hell Can't Stop Us Now!

  19. #99
    Rédacteur/Modérateur
    Avatar de Laurent.B
    Homme Profil pro Laurent Barbareau
    Ingénieur développement logiciels
    Inscrit en
    novembre 2004
    Messages
    3 228
    Détails du profil
    Informations personnelles :
    Nom : Homme Laurent Barbareau
    Âge : 41
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : novembre 2004
    Messages : 3 228
    Points : 14 735
    Points
    14 735

    Par défaut

    Citation Envoyé par Loceka Voir le message
    Le parenthésage type Allman je trouve que c'est de la perte de place et du coup de lisibilité (on n'embrace pas tout le code d'un seul coup d'oeil)
    Moi qui ai beaucoup de mal à lire les blocs condensés, que j'appelle en général des "pâtés" , je préfère donc de loin le code aéré et peu importe si celui-ci provoque ce que certains voient comme de la perte de place.
    En fait, pour ce qui est de permettre d'avoir une vision globale et rapide de l'action d'une méthode ou fonction, tout dépend de ce qu'elle contient et de la manière dont c'est formalisé. Le code condensé avait bien plus de légitimité lorsque les écrans avaient encore des dimensions très restreintes. Quoi qu'il en soit et en ce qui me concerne, je pense qu'effectivement ce genre de débat est plutôt vain, tout simplement parce que tout le monde n'a pas la même façon de percevoir et analyser un code.

    Donc, toujours selon moi, mettre une accolade en fin de ligne à côté plutôt absurde mais avec le temps je m'en suis accommodé. Pour pallier cela, j'ajoute systématiquement une ligne vide après l'accolade ouvrante. C'est donc un format hybride que je pratique et le fait que l'accolade soit à la fin des lignes ne m'embête pas, signe que ce n'est pas tant l'accolade le problème mais bien les textes trop condensés.

    Ensuite, je suis tout à fait d'accord avec le fait que si une méthode est trop longue, cela pose des problèmes pour analyser rapidement l'algorithme de celle-ci. C'est pourquoi, au lieu d'incriminer les accolades ouvrantes en début de ligne ou les lignes vides, il faut attacher davantage d'importance à la formalisation de celle-ci. Cela veut dire, faire en sorte que tout ce qui est un tant soit peu compliqué à lire ou tout ce qui prend beaucoup de lignes (ex : remplissage d'un bean avec plein d'attributs par exemple), soit relégué dans des méthodes explicites de par leur nom.
    Voilà, donc normalement en définissant des règles qui imposent un nombre de lignes relativement restreint par méthode/fonction, on peut se permettre d'avoir un code aéré, qui selon moi demeure beaucoup plus lisible.

    Bref, on n'arrivera jamais à satisfaire tout le monde, donc on aura sans doute fait un progrès, lorsque les éditeurs de code permettront de présenter efficacement le code selon les goûts du développeur, sans impact sur les fichiers physiques et qu'il soit ensuite très facile de basculer d'un type de présentation à un autre.

    Un autre progrès me semblerait intéressant, ce serait de guider en permanence la saisie du code, de manière à ce que le développeur n'ait pas à s'en préoccuper (ça se fait dans certains éditeurs depuis un bail me semble-t-il). Egalement, ces éditeurs pourraient se rapprocher de ce qu'est un éditeur de texte tel que Word/OO, c'est-à-dire en permettant de la mise en forme plus poussée. Par exemple, en ayant des marges verticales à intervalle adaptatif selon le contexte, comme faire une séparation plus prononcée entre la signature d'une méthode et le contenu de celle-ci (personnellement, je ne mettrais plus de ligne vide).
    Tout ceci a un coût c'est sûr mais je verrais cela comme une bonne chose pour couper court à ce genre de débat, source de frustrations et pertes de temps
    Responsable FAQ Eclipse | Maintiens et développe un des logiciels destinés aux rédacteurs sur developpez.com
    Pensez à cliquer sur le bouton une fois votre problème solutionné, merci.

  20. #100
    Expert Confirmé Sénior Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 028
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 028
    Points : 5 832
    Points
    5 832

    Par défaut

    Pour ce qui est du troll éternel Allman vs K&R, je dirait qu'il n'a vraiment pas lieu d'être. Non seulement la différence n'est au final pas vraiment importante, mais en plus ils peuvent se mélanger sans que ça pose vraiment de problème de lisibilité tant que l'indentation reste propre.

    Personnellement j’utilise le K&R, qui a l'avantage d'être plus concis, sauf dans des cas particuliers ou le Allman apporte vraiment un plus de lisibilité comme
    Code :
    1
    2
    3
    4
    5
    6
    if( condition longue
        && complexe
        && sur plusieurs lignes)
    {
        code
    }
    où il est utile pour bien séparer la condition du corps du bloc.

    Citation Envoyé par Glob
    La réflexion fonctionne tout aussi bien sur des champs public que sur des méthodes. De plus, même si la génération des accessors peut être facilitée dans des IDE modernes comme Eclipse, ça reste lourd à la maintenance pour une plus-value qui reste chimérique.
    Le problème des getter/setter n'a rien a voir avec l'introspection, ou la lisibilité, c'est même plutôt une plaie à ce niveau.

    Ils sont là car ils servent d'interface aux javabean. Un bean se doit d'offrir une encapsulation forte. Grâce au getter/setter les beans ont un contrôle complet sur leur propriétés qu'il peuvent restreindre (read/write only), vérifier, générer à la voler, ... etc
    Certes c'est lourd de faire un getter/setter quand on ne fait qu'une opération d'écriture/lecture de variable (Sun/Oracle devrait vraiment se pencher sur une syntaxe spéciale pour les propriétés). Mais ça permet de pouvoir faire évoluer l'opération dans le futur pour par exemple ajouter un contrôle sur un setter, ce qui n'est pas possible avec un accès direct à un champ.

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
  •