+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 2 12 DernièreDernière
  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Consultant
    Inscrit en
    juillet 2013
    Messages
    1 227
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : Côte d'Ivoire

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

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 227
    Points : 31 774
    Points
    31 774
    Billets dans le blog
    2

    Par défaut Peut-on définir des normes d’écriture d’un beau code ?

    Peut-on définir des normes d’écriture d’un beau code ?
    « Il n'y a pas de style de code correct », il faut être cohérent selon un bloggeur

    L’écriture d’un code qui permet de satisfaire les exigences fonctionnelles et de performance a toujours été la première priorité des développeurs. Au-delà de cet aspect, bon nombre de programmeurs s’attardent un peu sur le style d’écriture de leur code pour faciliter la lecture et la compréhension. Cela permet au développeur de repérer plus facilement les erreurs et également de comprendre ce qu’il essayait de faire lorsqu’il revient sur le projet quelques mois plus tard. Si en plus, d’autres ingénieurs doivent hériter du code, il est généralement conseillé d’adopter un style cohérent qui facilitera la continuité ou la réutilisation du code.

    L’idée d’adopter un style d’écriture cohérent semble faire l’unanimité, mais une question se pose toutefois sur le style à adopter et à ce niveau, beaucoup de mythes demeurent. Ce qui est accepté par un développeur peut être interdit chez un autre, et ce qui est obligatoire chez l’un peut être inutile chez l’autre. Chacun avance des arguments plus ou moins pertinents pour défendre sa position, et sur Developpez.com, bien qu’on ait plusieurs fois débattu sur ce sujet, on n’a jamais pu arriver à un consensus.

    Pour un bloggeur, il y a trop de mythes autour de l’écriture d’un beau code, alors que la règle semble simple : « il n'y a pas de style de code correct, tout comme il n'y a pas de bonne solution à une tâche d'ingénierie », a écrit Marc Newlin. Il pense que les nombreux guides de styles existants écrits dans l’absolu peuvent être utiles, mais manquent souvent de prendre en compte que le contexte d'un projet est aussi important que le code lui-même.

    Marc Newlin s’est donc proposé, à travers son billet, de briser ces mythes au sujet de la manière d’écrire un beau code.

    Pour lui, c’est une erreur de penser que l’utilisation de commentaires verbeux et d’espaces blancs font de vous un mauvais programmeur. Certains développeurs font valoir que les commentaires sont redondants, mais selon Newlin, c’est peut-être parce qu’ils oublient qu’il est plus facile de comprendre quelques phrases dans notre langue maternelle que le code directement dans un langage. Si ces derniers arrivent facilement à comprendre un code sans commentaire, ils pourraient toutefois gagner du temps à analyser la version commentée. Pour être efficace, le bloggeur pense qu’il est logique de commenter tôt et bien souvent, et les espaces viennent en compléments des commentaires pour faciliter la lecture du code.

    Un autre problème auquel il s’attaque est la guerre autour des conventions de nommage. Pour Newlin, « il n’y aura jamais de gagnant, c’est une guerre inutile. Tout le monde a une préférence sur les conventions de nommage, et certains langages préfèrent massivement un style plutôt que l'autre. La seule chose qui importe est la cohérence. »

    Ce qu’il propose donc lorsque vous travaillez sur un projet existant, c’est de suivre les conventions déjà en place. Et si vous débutez un nouveau projet, la logique serait de définir les conventions de nommage que vous souhaitez utiliser, et de vous tenir strictement à cela. Dans le cas où vous travaillez sur un projet dans un langage avec un guide de style, « il est bon de suivre les conventions de nommage définies dans le guide », a-t-il écrit.

    Vous avez peut-être entendu certains développeurs dire que l’utilisation de bibliothèques tierces est une mauvaise chose. Là encore Marc Newlin pense qu’il s’agit d’une erreur de la part d’un développeur qui aime ressentir la fierté d’avoir écrit un code complexe en seulement 2 jours. Newlin pense que si ce dernier avait avant tout effectué une recherche sur Google, il aurait surement trouvé une bibliothèque sous licence MIT/BSD qui fait exactement ce qu’il veut, sinon mieux. Il aurait alors gagné 2 jours pour améliorer son programme, au lieu d’essayer d’avoir la propriété complète sur son code.

    Pour Marc Newlin, le plus important, c’est d’écrire votre code de sorte qu’un étudiant en informatique de première année puisse le lire, un beau code se doit d’être simple. Il ajoute également qu’un programmeur éclairé va chercher à être plus productif en étant assez humble pour utiliser des bibliothèques tierces si possible. Cela lui éviterait d’écrire beaucoup. Il devrait également utiliser le plus de commentaires possibles.

    Source : Blog de Marc Newlin

    Et vous ?

    Partagez-vous les points de vue de Marc Newlin ?

    Qu'est ce qui caractérise un beau code selon vous ?
    Cdlt!
    M.K

  2. #2
    Membre éclairé
    Homme Profil pro
    Inscrit en
    juin 2010
    Messages
    317
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France

    Informations forums :
    Inscription : juin 2010
    Messages : 317
    Points : 856
    Points
    856

    Par défaut

    Ma foi, tout ceci n'est que du bon sens, toujours utile de rappeler puisqu'il parait que nous, les ingénieurs dév, sommes particulièrement susceptibles
    "Donnez un poisson à un Homme, et il mangera un jour. Apprenez-lui à pêcher, et il mangera tous les jours."

  3. #3
    Membre du Club

    Profil pro
    Java/Jee
    Inscrit en
    juillet 2008
    Messages
    24
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Java/Jee

    Informations forums :
    Inscription : juillet 2008
    Messages : 24
    Points : 58
    Points
    58
    Billets dans le blog
    1

    Par défaut

    Plein de bon sens tout ça.

    Il n'y a rien de pire pour un développeur de pester contre un code mal écrit et de se rendre conpte qu'on est celui qui l'a écrit.
    Ne pas oublier lors du développement d'une application qu'en général le temps de maintenance sera plus important que le temps de réalisation initial.

  4. #4
    Membre régulier
    Inscrit en
    juin 2004
    Messages
    68
    Détails du profil
    Informations forums :
    Inscription : juin 2004
    Messages : 68
    Points : 81
    Points
    81

    Par défaut

    Je dirais qu'un beau code est un code avec de belles couleurs et des polices de caractères bien choisies.




    Désolé...

  5. #5
    Membre éprouvé Avatar de dfiad77pro
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    décembre 2008
    Messages
    422
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Rhône (Rhône Alpes)

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

    Informations forums :
    Inscription : décembre 2008
    Messages : 422
    Points : 1 250
    Points
    1 250

    Par défaut

    Citation Envoyé par Sicyons Voir le message
    Je dirais qu'un beau code est un code avec de belles couleurs et des polices de caractères bien choisies.


    Désolé...

    C'est pas si hors- sujet que ça

    Perso j'utilise la même coloration syntaxique/Police en JAVA/C# et quelque soit L'IDE, je m'y retrouve mieux.

  6. #6
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 094
    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 094
    Points : 2 586
    Points
    2 586
    Billets dans le blog
    10

    Par défaut

    La couleur et la police dépendent de l'éditeur de texte utilisé.

    Pour moi il y a des caractéristiques d'un "beau code" :
    • Le respect des conventions d'écriture du langage (ex: pour Java, pour C#, pour PHP)
    • L'indentation à 4 espaces, ne jamais utiliser la tabulation \t car l'affichage varie en fonction de l'éditeur de texte utilisé.
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

  7. #7
    Membre actif Avatar de NotNow
    Homme Profil pro
    Etudiant ingénieur en développement logiciel
    Inscrit en
    avril 2015
    Messages
    83
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Etudiant ingénieur en développement logiciel
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2015
    Messages : 83
    Points : 266
    Points
    266

    Par défaut

    D'ailleurs, en parlant de beau code, c'est quand qu'on brule la "K&R style" ?

    Pas taper

  8. #8
    Membre régulier
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2004
    Messages
    41
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

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

    Informations forums :
    Inscription : juin 2004
    Messages : 41
    Points : 100
    Points
    100

    Par défaut

    Effectivement du bon sens et il faut toujours se rappeler certains principe comme KISS

    Et pour ce qui est de l'utilisation de bibliothèques tierces, je ne peurx qu'appuyer si celles-ci ne sont pas un obscur projet connu par deux personnes dans le monde. On a toujours avantage à utiliser des standards connus et partagés, la maintenabilité en est grandement améliorée.

  9. #9
    Membre averti

    Homme Profil pro
    Développeur Java
    Inscrit en
    février 2007
    Messages
    122
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Distribution

    Informations forums :
    Inscription : février 2007
    Messages : 122
    Points : 366
    Points
    366

    Par défaut

    Citation Envoyé par Gugelhupf Voir le message
    La couleur et la police dépendent de l'éditeur de texte utilisé.[*]L'indentation à 4 espaces, ne jamais utiliser la tabulation \t car l'affichage varie en fonction de l'éditeur de texte utilisé.[/LIST]
    Mais quelle horreur 4 espaces ! Ça ne va pas du tout c'est 3 espaces qu'il faut !
    La seule vrai bonne normes d'écriture d'un beau code c'est l'équipe qui développe qui la défini (comme dit dans l'article). Mais c'est frustrant d'arrivé dans un projet déjà commencé avec des normes qui ne correspondent pas à nos habitude.
    Parce que ma blague sur les espaces, elle est un peu vrai, je fais mes projets avec 3 espaces, au travail avec des \t les projets que je fork ça dépens.

    Ce qu'il faudrait c'est un descripteur de normes pour le projet pour qu'il soit toujours versionné avec les mêmes normes et un descripteur de normes perso sur chaque poste pour les dev l'IDE faisant les conversions automatiquement.
    L'expérience est une lanterne que l'on porte sur le dos et qui n'eclaire jamais que le chemin parcouru.

    La nature fait les choses sans se presser, et pourtant tout est accompli.

  10. #10
    Membre régulier

    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    janvier 2010
    Messages
    106
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : janvier 2010
    Messages : 106
    Points : 93
    Points
    93
    Billets dans le blog
    1

    Par défaut Les guidelines sont indispensables

    Personnellement j'utilise la norme aviva en C# : https://csharpguidelines.codeplex.com/
    Il est indispensable de choisir soigneusement des Guidelines avant de débuter un projet et de s'y tenir fermement surtout si plusieurs codeurs travaillent sur le même projet.
    jdd deschamps
    RPL - VB6 - C# - Wordpress - Python3 - Xamarin

  11. #11
    Membre expérimenté
    Inscrit en
    juin 2009
    Messages
    529
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 529
    Points : 1 477
    Points
    1 477

    Par défaut

    Citation Envoyé par jdddeschamps Voir le message
    Personnellement j'utilise la norme aviva en C# : https://csharpguidelines.codeplex.com/
    Il est indispensable de choisir soigneusement des Guidelines avant de débuter un projet et de s'y tenir fermement surtout si plusieurs codeurs travaillent sur le même projet.
    Interessant ce pdf, je le garde sous le coude

    par contre, tout est toujours sujet à débat.

    En l'occurence :
    AV1545 Don’t use if-else statements instead of a simple (conditional) assignment 
    Express your intentions directly. For example, rather than
    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    bool pos;
    if (val > 0) 
    { 
     pos = true; 
    } 
    else 
    { 
     pos = false; 
    }
    write
    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    bool pos = (val > 0); // initialization
    Or instead of
    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
     
    string result; 
     
    if (someString != null) 
    { 
     result = someString; 
    } 
    else 
    { 
     result = “Unavailable”; 
    } 
     
    return result;
    write
    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    return someString ?? “Unavailable”;
    Je suis d'accord avec cette règle (et en généralisation, j'aime bien l'opérateur ternaire sur des condition/résultat simples et direct), mais la plupart de mes collègues sont complètement contre.

  12. #12
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    8 849
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 8 849
    Points : 23 423
    Points
    23 423

    Par défaut

    Citation Envoyé par Gugelhupf Voir le message
    L'indentation à 4 espaces, ne jamais utiliser la tabulation \t car l'affichage varie en fonction de l'éditeur de texte utilisé.
    AH non, sacrilège, l'indentation, c'est 2 espaces, pas 4 ! Non, mais on va-t-on ?

    Citation Envoyé par AoCannaille Voir le message
    Je suis d'accord avec cette règle (et en généralisation, j'aime bien l'opérateur ternaire sur des condition/résultat simples et direct), mais la plupart de mes collègues sont complètement contre.
    Et moi je donne raison à ..... toi et tes collègues.

    Ces règles sont effectivement plus facile à écrire, et sont plus condensées, compréhensibles de prime abord (quoique j'ai toujours un peu plus de mal avec le second exemple).
    Par contre, lors de la recherche d'un bug un peu tordu, elles peuvent favoriser le fait qu'un cas d’exécution passe inaperçue car en lisant rapidement le code on interprète pas toujours, ou pas toujours correctement ces lignes-là.
    Alors qu'un IF..ELSE classique, même en survolant le code, on le loupe pas.

    Bref, je fais parti des mitigés qui les utilisent au codage et rouspète après le codeur de les avoir utilisées lors d'analyse ou de recherche de plantage pas facile à trouver.

    Sinon pour en revenir au sujet : Peut-on définir des normes d’écriture d’un beau code ?
    Oui, mais cette norme sera différente d'une équipe à l'autre, voire d'un projet à l'autre.
    Le plus important n'est pas la norme, le plus important est qu'elle soit clairement et explicitement définie, respectée, appliquée et défendue par tous et partout ou elle s'applique.
    Au delà de la norme, comme il a été dit, c'est la cohérence qui prime.
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  13. #13
    Expert confirmé
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    1 914
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 914
    Points : 4 202
    Points
    4 202

    Par défaut

    Citation Envoyé par sevyc64 Voir le message
    AH non, sacrilège, l'indentation, c'est 2 espaces, pas 4 ! Non, mais on va-t-on ?
    Pour être exact 2 espaces pour le HTML, javascript, XML [autres] et 4 espaces pour les vrai langages: C, C++, Java [autres]

    Mais mon IDE actuel (C++ Builder) considère une tabulation comme 3 espaces

    L'idée du nombre d'espaces c'est d'éviter de coder des lignes trop longues (le strict c'est 80 colonnes) et d'avoir trop d'imbrications (par exemple 3 - 4 boucles imbriquées)
    C'est pour cela certains mettent 6 ou 8 espaces


    Enfin il faut mettre des tabulations en début de ligne, mais ensuite sur la ligne il faut mettre des espaces (pour aligner des affectations par exemple.)

  14. #14
    Membre actif Avatar de NotNow
    Homme Profil pro
    Etudiant ingénieur en développement logiciel
    Inscrit en
    avril 2015
    Messages
    83
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Etudiant ingénieur en développement logiciel
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2015
    Messages : 83
    Points : 266
    Points
    266

    Par défaut

    Citation Envoyé par foetus Voir le message
    le strict c'est 80 colonnes
    Oui, mais c'était plus avant... Maintenant, on a de grands écrans, souvent double, cette règle est un peu désuète depuis le temps non ? Surtout que desfois, en Java, on peut vite y arriver !

  15. #15
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 124
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 124
    Points : 9 127
    Points
    9 127

    Par défaut

    Justement je viens de retomber sur quelques discussions Github mémorables, comme celle-ci : https://github.com/twbs/bootstrap/issues/3057

    Le point-virgule a remplacé la croix de nos jours.

    ne jamais utiliser la tabulation \t car l'affichage varie en fonction de l'éditeur de texte utilisé.
    C'est précisément la raison pour laquelle j'utilise les tabulations. Chacun lui donne la largeur qu'il veut, et ça évite le débat inutile du nombre d'espaces.
    One Web to rule them all

  16. #16
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    novembre 2014
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 25
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : novembre 2014
    Messages : 4
    Points : 12
    Points
    12

    Par défaut

    Citation Envoyé par Gugelhupf
    L'indentation à 4 espaces, ne jamais utiliser la tabulation \t car l'affichage varie en fonction de l'éditeur de texte utilisé.
    Justement je trouve que le \t a cet avantage là : laisser le choix à un utilisateur quant à son indentation. Un éditeur de code un tant soit peu bien fait devrait faire ça !

    Citation Envoyé par Angelsafrania
    Ce qu'il faudrait c'est un descripteur de normes pour le projet pour qu'il soit toujours versionné avec les mêmes normes et un descripteur de normes perso sur chaque poste pour les dev l'IDE faisant les conversions automatiquement.
    Y a là une bonne idée de projet mais je crois que ça commence déjà à se faire.

  17. #17
    Membre du Club
    Profil pro
    Inscrit en
    mars 2006
    Messages
    65
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2006
    Messages : 65
    Points : 59
    Points
    59

    Par défaut

    Salut à tous!

    Je me dois un petit peu de réagir sur ce genre de débat qui est souvent présent sur DVP

    Tout ce que vous décrivez, je l'ai vécu pas mal dans différents projets, dès que je change de boite, les mentalités changent, les équipes changent et leurs habitudes/normes aussi.

    Pour ma part, je ne me prends plus la tête avec tout ce qui est indentation, les accolades en fin de ligne ou à la ligne, etc etc.... Il y a des normes, chacun a ses habitudes... etc etc là aussi.
    Je travaille souvent avec des langages populaires comme Java, C ou encore C# et pour cela, j'ai découvert un projet magique qui m'a changé la vie: Artistic Style!
    http://astyle.sourceforge.net/

    Vous rentrez les paramètres de formatage et cela transforme votre code. Personnellement, a chaque début de projet, je le configure selon l'équipe (car même si je respecte les normes de codage, j'ai déjà travaillé avec des équipes qui préféraient leurs règles qui vont parfois à l'encontre des bonnes pratiques....) et je l'ajoute en automatique à GIT. Ainsi, dès que je pousse du code, ce dernier est automatiquement formaté comme demandé et à l'inverse, dès que je récupère du code, il est formaté selon mes préférences (et au cas où vous vous poseriez la question, le code est formaté avant les merges, bien évidemment)
    Vous pouvez tout paramétrer: indentation X espaces, la place des accolades, l'espacement avant et après les blocs, les fins de lignes (\n ou \n\r), le placement des étoiles désignant les pointeurs en C (un débat éternel là aussi)...

    Voilà, un petit coup de pub, à essayer
    Et effectivement, comme dit axellink, ce genre de projet voit le jour de plus en plus!

    Après cela ne fonctionne pas pour tous les langages. Mais du coup, certains IDE deviennent intelligents. Par exemple, je travaille dernièrement en Python et Golang, où la compilation dépend du formatage. Des éditeurs comme Sublime Text permettent d'intenter correctement le code à chaque sauvegarde.

  18. #18
    Expert confirmé
    Avatar de TiranusKBX
    Homme Profil pro
    Développeur C, C++, C#, Python, PHP, HTML, JS
    Inscrit en
    avril 2013
    Messages
    1 304
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur C, C++, C#, Python, PHP, HTML, JS
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2013
    Messages : 1 304
    Points : 4 303
    Points
    4 303
    Billets dans le blog
    6

    Par défaut

    Citation Envoyé par SylvainPV Voir le message
    Justement je viens de retomber sur quelques discussions Github mémorables, comme celle-ci : https://github.com/twbs/bootstrap/issues/3057

    Le point-virgule a remplacé la croix de nos jours.

    C'est précisément la raison pour laquelle j'utilise les tabulations. Chacun lui donne la largeur qu'il veut, et ça évite le débat inutile du nombre d'espaces.
    Je suis d'accord la tabulation évite de nombreux problèmes, et ceux qui trouve ça nul/moche/affreux n'on plus qu'à changer d'éditeur de texte !
    car dès que l'on commence a mettre que des espaces une tab vas arriver et foutre la merde, d'autant plus sous python

  19. #19
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2013
    Messages : 485
    Points : 2 120
    Points
    2 120

    Par défaut

    Pour moi, plus que recherchez le "beau code", je trouve qu'il est important d'aller à la chasse au "vilain code"

    Et pour moi, les antipattern (http://fr.wikipedia.org/wiki/Antipattern) sont de vilains codes.
    De prendre du temps pour faire de la relecture de code à plusieurs pour les identifier est une bonne chose.
    Attention: on "juge" alors le code, pas le développeur - tout le monde peut produire un antipattern

    Pour revenir à l'idée de JCD_31 avec son outil, moi j'utilise le plus possible des outils d'analyses statiques de code (genre lint, PMD, FxCop, pylint, ...)
    Cela permet une cohérence de nommage en plus de détecter un certain nombre d'antipattern classique.

    Cet article fait écho à celui ci : http://www.developpez.net/forums/d15...ment-logiciel/

  20. #20
    Membre expérimenté
    Inscrit en
    juin 2009
    Messages
    529
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 529
    Points : 1 477
    Points
    1 477

    Par défaut

    Citation Envoyé par sevyc64 Voir le message
    Et moi je donne raison à ..... toi et tes collègues.

    Ces règles sont effectivement plus facile à écrire, et sont plus condensées, compréhensibles de prime abord (quoique j'ai toujours un peu plus de mal avec le second exemple).
    Par contre, lors de la recherche d'un bug un peu tordu, elles peuvent favoriser le fait qu'un cas d’exécution passe inaperçue car en lisant rapidement le code on interprète pas toujours, ou pas toujours correctement ces lignes-là.
    Alors qu'un IF..ELSE classique, même en survolant le code, on le loupe pas.

    Bref, je fais parti des mitigés qui les utilisent au codage et rouspète après le codeur de les avoir utilisées lors d'analyse ou de recherche de plantage pas facile à trouver.
    C'est pour ça que je dis que tout est toujours sujet à débat. Personnellement je trouve cela bien plus clair, et si le cas passe inaperçu à la relecture, c'est que l'auteur de la relecture manque de rigueur.

    Le seul inconvénient que je constate coté debug/maintenance c'est qu'en général le debugger passe juste la ligne, sans passer "visuellement" dans le cas traité.

    Dans une mission avionique, on avait un analyseur syntaxique qui remontais des erreurs à chaque non respect de la charte. Et s'il y avait des erreurs, il n'y avait pas de Qualif'. Autant dire que ça blaguait pas trop sur la syntaxe... (mais bon, dans ce cas là, les règles étaient l'exact inverse de celles proposées par Aviva)

Discussions similaires

  1. Peut-on définir des fonctions dans un script ?
    Par nchristedem dans le forum MATLAB
    Réponses: 20
    Dernier message: 11/08/2009, 11h38
  2. Peut-on regrouper des feuilles Excel contenant du code VBA ??
    Par souheil59 dans le forum Macros et VBA Excel
    Réponses: 1
    Dernier message: 18/11/2008, 11h43
  3. Peut-on définir des constantes en CSS ?
    Par JeanMarc_T2k dans le forum Mise en page CSS
    Réponses: 14
    Dernier message: 29/02/2008, 14h30
  4. Réponses: 2
    Dernier message: 17/01/2007, 09h24
  5. Réponses: 1
    Dernier message: 04/01/2007, 22h52

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