Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 166 sur 167 PremièrePremière ... 66116156158159160161162163164165166167 DernièreDernière
Affichage des résultats 4 951 à 4 980 sur 5004
  1. #4951
    Elle est très bien la syntaxe Python Vous n'avez aucun goût, c'tout. Au pire, votre IDE préféré peux vous assister.

  2. #4952
    Comme disait mon grand oncle* les langages sans typage statique sont des langages de sans race

    *source contestée

  3. #4953
    Citation Envoyé par gros_bidule Voir le message
    Au pire, votre IDE préféré peux vous assister.
    Prettier > all (si votre langage est supporté).
    C'est la faute à Arteis

  4. #4954
    Citation Envoyé par Cwningen Voir le message
    C'est quoi le "formatage C++" et le "formatage Java" ? Parce qu'il y a plein de styles d'indentation des accolades et ce n'est pas lié au langage. Le style GNU est connu pour ne pas mettre les accolades à la même indentation et il a été conçu pour du C.
    Celui, que j'ai le plus pratiqué (bon, ma pratique pro du C++ n'est pas récente, les deux premiers tiers des années 2000), j'ai surtout utilisé et vu utilisé Allman Style (je ne connaissais pas le nom).
    C'est vraiment celui que je trouve le plus lisible.
    L'accolade ouvrante au même niveau que la commande me parait plus difficile à repérer (et je dis Java, parcequ'il me semble que c'est dans toutes les variantes de styles sont comme ça dans ce langage).

    Le style GNU, je trouve ça moins esthétique

    Mon blog figurines: UglyMiniatures

  5. #4955
    Citation Envoyé par Cwningen Voir le message
    C'est quoi le "formatage C++" et le "formatage Java" ? Parce qu'il y a plein de styles d'indentation des accolades et ce n'est pas lié au langage. Le style GNU est connu pour ne pas mettre les accolades à la même indentation et il a été conçu pour du C.
    le style Java 'officiel' tel que poussé par les conventions de Sun au début du langage c'est une variante du style K&R, en reprenant la definition de la page wikipedia que tu as posté.

    Variant: Java
    While Java is sometimes written in other styles, a significant body of Java code uses a minor variant of the K&R style in which the opening brace is on the same line not only for the blocks inside a function, but also for class or method declarations. This style is widespread largely because Sun Microsystems's original style guides[14][15][16] used this K&R variant, and as a result most of the standard source code for the Java API is written in this style. It is also a popular indentation style for ActionScript and JavaScript, along with the Allman style.
    Code:
    while (x == y) {
        something();
        somethingelse();
    }

    Tout projet Java normallement constitué suit globalement une légère variante des conventions d'origines de Sun.
    Mais dans certaines équipes j'ai pu trouvé du Java avec du style 'C' (plutôt genre Allman en reprenant la nomenclature de la page wikipedia), et c'était soit des 'anciens' biberonnés au C/C++ ou des transfuges de C# qui n'arrivaient pas à changer leurs habitudes...
    Comme ça donc:
    Code:
    while (x == y)
    {
        something();
        somethingelse();
    }
    J'ai été dans un projet Java issu d'un portage d'une appli en C des années 90 avec tout le projet formatté en style 'Allman'. J'en ai bavé pour essayé de prendre l'habitude de lire/écrire le code sous ce format.
    C'est con mais le formattage structure le code et les doigts réfléchissent plus vite que le cerveau quand quand je tape ces parties (accolades et ponctuations).
    Je mets par exemple systématiquement des ';' à la fin de mes lignes en Python par exemple car j'en fais peu et je suis trop habitué à ponctuer mes instructions avec.

    Je trouve que le choix radical de Python et à la fois très con et à la fois génial. Je déteste qu'on m'impose des trucs, mais en même temps ça évite les conflits stérils pour ce genre de 'détails' qui peuvent devenir rapidement irritant.

  6. #4956
    Vala, puis Go fait pareil et là on crie au génie

  7. #4957
    Citation Envoyé par William Vaurien Voir le message
    Je déteste qu'on m'impose des trucs, mais en même temps ça évite les conflits stérils pour ce genre de 'détails' qui peuvent devenir rapidement irritant.
    Ben c'est là que les formateurs de code (comme Prettier que j'ai cité plus haut) sont très pratiques.
    Tu te mets d'accord sur la configuration en début de projet et roule ma poule.

    Pas besoin d'apprendre de nouvelles habitudes, le formateur met les { aux bons endroits, enlève/ajoute les ";", met les bons type de quotes, etc.

    Résultat : la codebase est uniforme et y'a plus aucun conflits liés au style.
    C'est la faute à Arteis

  8. #4958
    Dans mon équipe actuel un des dev Java n'arrive pas à se débarasser de son style 'Allman' (alors qu'il n'a jamais codé en C/C++/C# de sa vie) et il colle aussi des préfixe de type devant ses noms de variable (strMaString et lstMaListe)...
    Il avait également l'habitude de ne pas mettre d'accolades pour les cas 'simple' qui tienne sur une ligne.
    Lui faire accepter le guide de formattage à failli tourner au pugilat entre lui et un autre collègue et il n'a pas totallement accepté les règles même après plusieurs années...

    Nous devrions mettre une étape de formattage auto dans le pipeline de build pour éviter ce genre de petits problèmes...
    Mais après je trouve que les formatters auto font souvent de la merde quand il y a des lambdas et dans d'autres cas (genre annotation avec requête dans du JPA) un peu tordus.

    De mon côté je me suis habitué à voir un code formatté avec plusieurs styles. Ca ne me dérange plus trop ce style 'patchwork'. Et ça a un avantage: on reconnait d'un seul coup d'oeil qui est l'auteur du code.
    Et chacun à ses petites habitutes: le collègue qui voulait ses accolades au bon endroit a du mal avec le nombres de paramètres ou la complexité cyclomatique de son code et va planquer ça sous le tapis avec des //NOSONAR...
    Je dois aussi avoir mes habitudes chiantes...
    ça donne parfois des revues de code un peu mouvementé pour pas grand chose. Mais c'est drôle de voir que chacun est finalement sensible a des trucs différents.

    Bref c'est pas forcément de bonnes habitudes et on aurait sans doute du mettre des règles plus strictes dès le début du projet...

  9. #4959
    Citation Envoyé par William Vaurien Voir le message
    il colle aussi des préfixe de type devant ses noms de variable (strMaString et lstMaListe)...


    Citation Envoyé par William Vaurien Voir le message
    Mais après je trouve que les formatters auto font souvent de la merde quand il y a des lambdas et dans d'autres cas (genre annotation avec requête dans du JPA) un peu tordus.
    J'ai pas testé ceux en Java mais dans le monde web JS ça fait le café et c'est entrain de devenir un peu standard.

    Citation Envoyé par William Vaurien Voir le message
    Et chacun à ses petites habitutes: le collègue qui voulait ses accolades au bon endroit a du mal avec le nombres de paramètres ou la complexité cyclomatique de son code et va planquer ça sous le tapis avec des //NOSONAR...
    Et ça passe en merge-request ça ?

    Citation Envoyé par William Vaurien Voir le message
    Bref c'est pas forcément de bonnes habitudes et on aurait sans doute du mettre des règles plus strictes dès le début du projet...
    C'est surtout ça en fait.
    Tu mets en place l'outil dès le début du projet avec un git hook pour formater au commit (même si perso je configure mon IDE pour le faire à la sauvegarde).
    C'est la faute à Arteis

  10. #4960
    Le nombre de paramètres ça ne passe pas. Par contre la complexité cyclomatique par défaut dans Sonar c'est quand pas super élevé... La config du Sonar est global pour notre boîte, on ne peut pas modifier les règles, alors on fait au cas par cas...

    Pour l'historique j'ai commencé à bosser sur une refonte de code existant (flash / action script vers Java) avec un chef qui codait en style 'Allman'... donc compliqué de venir lui dire de changer. Ensuite j'ai commencé en parallèle un projet de zéro (mon premier "green field" ), je n'avais de problèmes qu'avec moi même...
    Ensuite le projet est devenu pérenne et il y a eu des recrutements (dont les 2 collègues dont j'ai parlé), et mon chef est venu participer au dev. A ce moment le formattage du projet a pris du plomb dans l'aile et c'était assez compliqué de venir forcer la main du chef... Il y a eu quelques discutions houleuses, un accord a été trouvé (que les tenants du style Allman se sont empressés de ne pas respecter )

    Donc on a parlé de mettre un formatter auto en plus de Sonar mais nous n'avons pas sauté le pas... C'était il y a 3 ans, nous avons obtenus gain de cause pour les accolades obligatoires même pour des 'one-liner', le reste est devenu un statu-quo... (nous sommes tous des internes, ça joue aussi: plus difficile d'imposer des trucs)

    Le premier projet doit subir une migration technique, c'est une équipe externe qui doit s'en charger, ils ont le feu vert pour faire sauter le style patchwork et nous comptons sur cet événement pour mettre en place un formatter auto...

    Mais c'est quasi tragi-comique de voir le temps et l'énergie dépensé pour un truc qui de l'extérieur semble si futile...


    J'aime bien le petit paragraphe de la doc de go à ce sujet:
    Formatting issues are the most contentious but the least consequential. People can adapt to different formatting styles but it's better if they don't have to, and less time is devoted to the topic if everyone adheres to the same style. The problem is how to approach this Utopia without a long prescriptive style guide.

  11. #4961
    Moi je m'adapte mais j'aime bien le ''Whitesmiths style''.
    Plus c'est espacé mieux c'est.

    Je dois être un des rares au taf à programmer sur fond blanc...

  12. #4962
    C'est étrange d'associer plus Allman au C/C++, et K&R au Java. K&R, c'est les auteurs de quel livre déjà ?

  13. #4963
    Java est très proche du C au niveau de la syntaxe. Et le style 'officiel' de Java c'est une variante du K&R...
    Après j'associe Allman au C/C++ car à chaque fois que j'ai vu du code dans ce langage (ou du Java déviant) c'était avec du format 'Allman'.
    J'ai jamais vu 'en action' les autres variantes de formattage listé sur la page wikipedia. Je classifie d'après mon expérience, mais ça semble partagé:montre du code avec les accolades comme ça à un dev:
    Code:
    while (x == y) {
        something();
        somethingelse();
    }
    et il y a de grandes chance qu'il te dise "Java" (voir Java Caca s'il a été contraint de faire des EJB vers 2004 et n'a plus touché au langage depuis, ou qu'il n'a jamais touché au langage tout court).

  14. #4964

  15. #4965
    Moi je mets des .editorconfig en réglant tous les paramètres de formatage pour qu'ils s'affichent en tant qu'erreurs.

  16. #4966
    Au boulot j'en ai qui me font des nommage de variable en snake case dans les projets java, j'en peux plus

  17. #4967
    Ils ont bien raison c'est illisible camel case

  18. #4968
    Citation Envoyé par war-p Voir le message
    Au boulot j'en ai qui me font des nommage de variable en snake case dans les projets java, j'en peux plus
    C'est un problème par rapport au snake case ou par rapport au java ?
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  19. #4969
    Citation Envoyé par Kamikaze Voir le message
    Ils ont bien raison c'est illisible camel case
    le snake case c’est pour les vieux qui ont les yeux flingués et voient tellement flou qu’ils sont incapable de différencier une majuscule d’une minuscule
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  20. #4970
    Ha tient, je ne connaissais pas le kebab case

    Dernière modification par Foudge ; 02/07/2022 à 11h50.

  21. #4971
    C'est une caisse de transport pour un Kebab ?
    "Déconstruire", c'est "détruire" en insérant des "cons".
    Battle.net (Diablo 3) : Fbzn#2658 ----- / ----- / ----- Steam ID

  22. #4972
    Citation Envoyé par Lazyjoe Voir le message
    C'est un problème par rapport au snake case ou par rapport au java ?
    La convention communément utilisée en java est le camelCase.
    Je préfère aussi le snake case (vieux inside ), mais en Java, c'est hérésie .

    Mon blog figurines: UglyMiniatures

  23. #4973
    Citation Envoyé par teocali Voir le message
    le snake case c’est pour les vieux qui ont les yeux flingués et voient tellement flou qu’ils sont incapable de différencier une majuscule d’une minuscule
    oui et alors monsieur!!!

  24. #4974
    Je fais principalement du script shell (oui ça existe encore) et c'est assez chiant à lire comme ça, donc snake_case et on minimise les ';'
    Code:
    my_file=/my/file.txt
    if test -f ${my_file}
    then
        [...]
    fi
    # au lieu de
    if test -f ${my_file}; then
        [...]
    fi

  25. #4975
    "Déconstruire", c'est "détruire" en insérant des "cons".
    Battle.net (Diablo 3) : Fbzn#2658 ----- / ----- / ----- Steam ID

  26. #4976
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  27. #4977

  28. #4978
    Citation Envoyé par William Vaurien Voir le message


    c'est vraiment n'importe quoi...
    Mais ça marche...
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  29. #4979

  30. #4980
    Ça fait 10 ans qu'il y a ce genre d'articles sur js qui sortent quotidiennement.

    Moi je m'en fous je code en TypeScript
    Citation Envoyé par ExpertCPC Voir le message
    J'ai vu le monde éveillé. J'ai vu le monde endormi. J'ai vu le monde en rêve.

Page 166 sur 167 PremièrePremière ... 66116156158159160161162163164165166167 DernièreDernière

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
  •