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.
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.
Comme disait mon grand oncle* les langages sans typage statique sont des langages de sans race
*source contestée
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
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:
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.Code:while (x == y) { something(); somethingelse(); }
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.
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
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...
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.
Et ça passe en merge-request ça ?
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
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.
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...
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à ?
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:
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).Code:while (x == y) { something(); somethingelse(); }
Je dirai même plus... Javascript.
Moi je mets des .editorconfig en réglant tous les paramètres de formatage pour qu'ils s'affichent en tant qu'erreurs.
Au boulot j'en ai qui me font des nommage de variable en snake case dans les projets java, j'en peux plus
Ils ont bien raison c'est illisible camel case
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
Ha tient, je ne connaissais pas le kebab case
Dernière modification par Foudge ; 02/07/2022 à 12h50.
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
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
c'est vraiment n'importe quoi...
oui, c'est le plus terrible dans l'histoire. Quelle merde ce js !
Ç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