Reprise du message précédent :

 
C'est la différence entre faire le taf et le faire bien

Bien sûr, no prob

avant que tout le monde ici ne croie que je bosse comme un porc, je tiens à dire que c'est juste à cause d'un manque de communication entre les différents acteurs du projet sur lequel je bosse qui est à l'origine de cette semaine supplémentaire

 

 
Il fallait faire appel à l'expert un peu plus tôt

keyword : fishbone diagram / Ishikawa diagram (le truc vient en standard avec des familles de critères, que tu peux utiliser ou remplacer comme tu veux)
c'est très courant d'utilisation dans la qualité, ou les post-mortems, souvent en combinaison avec "5 whys"
tu pars d'un problème : le pare-brise du cockpit de l'avion s'est arraché en plein vol
et tu listes les causes : vis n'ayant pas le bon pas de vis, QA foireuse sur la réparation
et tu déroules chaque cause  de la même manière

tu veux le générer, ou le faire à la main ?
à la main à peu près tous les outils de diagramme gèrent ce truc, sinon tu peux prendre un outil de mindmapping (en mettant tous les nodes que d'un seul coté)

sinon un nas 8 baies ?

Tiens Devil’s tiger tu devrais aller dire a Ian Young que c’est un vilain pas gentil qui critique les morts, vu que c’est un vilain pas gentil qui critique les morts (et qui déclare y prendre grand plaisir): https://twitter.com/ianjamesyoung70 [...] 3137497090

Il te verras plus souvent que Gfive au basket donc.

ça se voit que tu as du temps libre, tu es affuté

J'espère qu'il va pas sortir sur blessure dès la première fois, en tout cas.

https://www.lexpress.fr/actualite/s [...] 52072.html  c'est ballot

Bof, au bout d'un mois sur le projet (j'ai pas écris une ligne de code), je dois faire 6h de formation sur "la sécurité en javascript" alors que je pars dans 3 semaines.

j'ai reçu mon nouveau casque ( microsoft surface ) : encore plus confortable que le sony que j'avais avant
 
 à voir sur la durée

Et tu n'es pas acteur de cette communication en tant que membre du projet ?

   
 
Il est en forme skeye aujourd'hui. C'est le variant bordelais ?

 
Il fait beau et Harko galère (un peu) sur des trucs qui relèvent de mon expertise...donc oui ça va, plutôt en forme et de bon poil.

Ola, pour ceux qui bossent en équipe, jusqu'où vous allez dans la formalisation des "conventions de code" ? Au delà des trucs basiques genre formatting (pris en charge par les outils type linter ou autres outils de formatting automatique). A quel point vous rentrez dans le détail et à quel moment vous considérez que ça rentre dans "le choix/liberté du dev" ? Et notamment comment vous placez le curseur ?

Exemple concret pour illustrer (mais qui est juste mon cas le plus récent): sur du Python, on a un mec dans l'équipe qui voudrait qu'on décide d'imposer que la valeur de nos enums soient des strings (dans la pratique pour le moment c'est effectivement le cas dans la codebase actuelle) et de bannir du coup par la même occasion l'utilisation de "auto()". En gros d'avoir dans le code que des enums du style :

class Source(Enum):
    MANUAL = "MANUAL"
    AUTO = "AUTO"

Son argument principal en gros c'est "que c'est plus facile, ça évite d'avoir à se poser des questions quand tu ajoutes une enum si t'as qu'une seule façon de faire". De mon coté, j'ai l'impression que ça rentre vraiment trop dans le détail et que sans une autre raison plus fondamentale (des impacts en terme de perf, de sécurité, etc...), c'est pas suffisant pour ajouter ce type de trucs dans notre "rulebook".

Vos avis ? En dehors de cet exemple précis, j'imagine que vous avez eu pleins de cas de divergence de style entre des devs, qui soient pas reglés par des outils/recos communs types PEP8, du coup vous faites quoi ? Vous tranchez systématiquement ? Vous acceptez plusieurs façons de faire ? Obiwan ?

Mon collègue avec qui je bosse est contre les linter ou formatage de code comme prettier.    
 
 
Cela dit, ça m’empêche pas d’en utiliser et d’avoir rien à apporter comme réponse à ta question.

 
Depuis le temps qu'on dit que PHP c'est un truc d'expert. Il comprend enfin

Je ne sais pas ce que fait auto(), mais moi quand j'ai fait une liste de règles, je l'ai écrite et ensuite on a fait une réunion où je l'ai proposée à toute l'équipe et on a discuté ensemble chacune des règles et un vote a été fait sur chacune pour la garder ou la rejeter.
Pour les règles d'indentation, elles sont imposées par un pretty printer.

En dehors de ça, je suis assez libéral, parce que trop de règles ultra strictes enlève le plaisir de coder, et imposer des règles que personne ne veut est le meilleur moyen pour que qu'elles ne soient pas respectées et de générer des frustrations inutiles. Mais si les règles ont été votées, elles sont plus facilement acceptées même par ceux qui sont récalcitrants.

J'autorise le dev à utiliser le style de son choix (faut rester raisonnable bien sûr), tant que le style est cohérent dans un fichier (idéalement dans un module) ça reste lisible et ça va.
 
Pour le formatage automatique j'ai toujours trouvé ça moyennement convainquant, notamment si un dev a aligné verticalement ses '=' je ne veux pas perdre ça dans ce genre d'outils...

Les bons outils de formatage alignent les symboles automatiquement.

1- le linter est le juge de paix.
Si tu veux autre chose, tu peux faire une suggestion de code, mais je n'écrirais pas  une ligne de code en comptant les espaces.
J'ai par exmeple tendance à écrire des codes compacts, peu espacés.

2 plus le linter va loin, moins on utilise de temps de cerveau pour les vérifier.

Donc perso, si l'ajout du linter supplémentaire ne fait pas ramer le processus de build et que la base de code est déjà comme ça, je l'ajouterai en contrôle auto

 
 
Là c'est plutôt sql/métier, mais oui.

 
et du coup ton collègue il aime avoir des conflits sur des whitespaces pendant les merges, et avoir la chaine de CI qui considère que du code a changé alors que pas ?
Ça fait très arrière garde comme débat en 2021...

 
https://www.youtube.com/watch?v=pqBD5Xejdbk

Oh punaise l'horreur, et puis si t'as le malheur de changer un pauvre truc dans le fichier, la gueule du commit si c'était pas bien indenté et tout  

 
Oué enfin ya pas que les symboles...
 
Si quelqu'un a écrit ça :  
 

 
ou ça :  

 
perso je ne me permets pas de ré-indenter à ma sauce.

Dans les langages que j'utilise il y a des 'use' pour éviter les A big namespace

 
En C++ tu évites les 'use' dans les .h car ça se propage à toute ta base de code (mais c'est ok dans les. cpp)

Je ne suis pas du tout d'accord avec ça, c'est même le contraire pour moi. Je déteste devoir choisir parmi trois façons de faire un truc, j'aime les style guide les plus assertifs qui soient.

Les contraintes nourrissent la créativité, je n'ai vraiment pas le sentiment que ce soit un frein au plaisir de créer. Par contre c'est clair que c'est un effort, et qu'on y perd en vélocité immédiate'

Ben c'est ta façon de voir, mais elle est loin d'être largement partagée.
Je ne dis pas que tu as tort, je dis que si tu dis à tes collègues "suivez mes règles, ça nourrira votre créativité", tu ne vas pas être très bien reçu. Si quelqu'un trouve que tes règles sont cons, il n'appréciera pas trop que tu les lui imposes.

Thx, c'est le coeur de ma question en fait. Pour tout ce qui est formatting, on utilise de toutes manières black, un autoformatter en Python qui règle 99% des questions sur les trucs types sauts de lignes, indentations, etc... Du coup pour ça la question est réglée.
 
Mon point est plus "pour les autres trucs", par exemple les petites spécificités liées à un langage (en Python on pourrait imaginer par exemple l'utilisation  de map/filter VS les comprehension list), à quel point vous aimez bien que ce soit tranché avec une seule façon de faire, ou au contraire "les deux sont autorisés", et comment vous faites pour décider tout ça ?

Je ne touche pas aux langages qui sont restés à la notation hongroise comme en 1990.

à partir du moment ou il y a des code review, je pense que le style doit être contrôler par le linter. Le linter doit pouvoir être configuré pour pouvoir mettre en forme le code à la sauvegarde, ou , à la limite, être intégré à l'IDE  
 
Ainsi le débat sur la review pourra être sur des trucs utiles : est ce que ça fait le job, est ce que c'ets implémenté de manière efficace, est ce que les tests sont pertinents ,....

Personnellement c'est surtout les trucs qui posent problème, et à la limite les trucs qui changent beaucoup le code entre des choix différents.

class Source(Enum):
    MANUAL = "MANUAL"
    AUTO = "AUTO"

J'ai un mal fou avec l'idée non seulement de se faire chier pour un truc qui a un impact ridiculement faible (c'est pas tous les jours que tu vas écrire ou éditer une enum), mais en plus de sacraliser l'alternative la plus moisie possible.

J'ai plus tendance à laisser faire, mais derrière je réécrit le code pendant que je le lis, puis je revert parce-que c'est pas "utile"
 
Après généralement mes bricolages c'est plus sur des questions d'APIs pas utilisées ou mieux utilisables, et ça c'est souvent difficile à comprendre pour un simpler linter / formatter, faut passer à des trucs genre règles semgrep dédiées.

Ya des outils qui permettent de formatter que ce que tu touches  

Mais le résultat est mochachier

Mais si tu n'imposes pas de style ou de linter, tu ne discutes pas de style lors de la code review du coup. Ça serait gros de reprocher à quelqu'un une histoire de style APRÈS avoir déclaré que c'était ok pour 'chacun son style' et pas de linter

L'architecture sale/propre est un critère bien plus important pour la lisibilité et ça tout le monde est ok pour en discuter en code review

cf ma réponse à Hephaistos

Si tu dis à tes collègues "suivez mes règles, ça nourrira votre créativité", tu ne vas pas être très bien reçu. Si quelqu'un trouve que tes règles sont cons, il n'appréciera pas trop que tu les lui imposes. C'est pour ça que je pense que les règles doivent être acceptées collégialement par l'équipe plutôt qu'imposées de force à l'équipe. Bien souvent, cette discussion écarte les règles les plus débiles.

De même, pour les revues de code, lors d'une mission je n'appréciais pas trop les revues de code d'un/e architecte assez autiste qui faisait chier sur des conneries cosmétiques (du moins ce que je considérais comme des conneries) sur lesquelles je n'étais pas d'accord, là ou un Xavier_OM laisse une certaine liberté. Dans ce cas-là, le linter/beautifier est le juge de paix.

 
https://google.github.io/styleguide/pyguide.html tiens Sidi
 
J'aime assez le styleguide Google pour Python (et les stylesguides Google en general) pour plusieurs raison :  
- la raison du pourquoi est expliquée
- c'est souvent assez pragmatique, et conçu pour empecher la branlette de dev genre "wow putain comme il est trop beau mon one liner qui tient sur 3 lignes et qui réussit le tour de force d'être moins maintenable qu'une regex"
- ils sont toujours "idiomatiques" (si tu regardes celui sur Python, le linter demande if foo is not None, et pas if foo != None)
- déroger est possible si t'as une bonne justification (c'est au reviewer de décider si c'est valable)

Merci pour les différentes réponses    
 

Je ne suis pas un grand fan de toutes les décisions de black, mais la plus value de virer toutes les discussions en PR liées au formatting est tellement énorme que je fais avec (et en plus quasi toute l'équipe était pour) et tant pis pour les quelques cas ou je trouve le code résultant moche

Oui en général je me base sur les style guides Google.