Vos petites manies de développeurs

En termes d'indentation, l'asynchrone est effectivement un peu à part.

Le code ci-dessus est clairement mauvais, il aurait certainement fallu isoler certaines fonctions de callback, déjà pour pouvoir les tester de façon unitaire en injectant des données de test, ensuite pour pouvoir les documenter à l'aide d'un outil adapté (jsdoc en l'occurrence).

Mais quand même, du code asynchrone nécessite forcément des callbacks, et la manipulation de données (filtrage de collections par prédicat, recherche dans des collections, …) passent souvent par une lambda ou assimilé (et nécessite indentation, du coup). Et si on découpe tout petit bouts de fonctions et qu'on se trimballe des références ça devient aussi illisible… Malheureusement, c'est affaire de compromis.

Mouais, ça signifie que dans une classe, dans une méthode, tu ne peux même pas mettre une condition dans une boucle, par exemple.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

<?php
// en PHP, mais c'est pareil dans les autres languages qui possèdent des
// classes

class Foo
{
        public function Bar()
        {
                while (true) {
                        if (true) {
                                echo 'Baz';
                        }
                }
        }
}

8 espaces pour indenter, 4 niveaux, ça passe toujours. La plus longue ligne arrive à la colonne 44. Bien entendu , je recommande pas 8 espaces, mais c'est pour montrer que c'est tout à fait acceptable.

(D'ailleurs, un autre argument contre les tabs : on contrôle pas toujours la taille qu'ils font.)

Ou alors faut pas indenter la classe

Linus fait du C, il y a pas de classes déjà.

Non, en Java tu écris bien dans le class{}, mais ça n'oblige en rien à indenter dedans, ce qui serait franchement inutile.

Ceux qui font du PHP ou du ruby ou du Python. Je suis sûr que, malheureusement, il y a plein d'autres languages dans ce cas.

J'avais retiré un bout de ma phrase, c'est pour cela qu'elle ne veut pas dire grand chose : on ne contrôle pas toujours la taille que les tabulations font, même dans notre propre environement. Je ne sais pas comment changer la taille des tabs dans Windows (dans la command prompt) ni dans celle de Linux.

Tu ne supportes donc pas la limite à trois d'intentation ? J'avais mal compris, my bad.

Evidemment: tab vs space, c'est un des plus vieux trolls de l'informatique. L'argument d'autorité (surtout sorti de son contexte), c'est la base du troll. C'est évident qu'il ne faut pas généraliser à partir des standards du kernel linux, et, pourtant, l'histoire du code mal écrit est plutôt fondée ici.

Personnellement, je rejoins Stranger: on ne devrait pas tener de contrôler l'affichage du code chez les autres. C'est dans cette optique que je tente le plus souvent de ne rien aligner. L'indentation a une valeur sémantique (elle indique le sens du code pour le développeur, le compilateur C s'en fiche, évidemment), l'alignement n'est là que pour faire joli. Les outils devraient afficher le code sous la forme la plus lisible pour le développeur (le fameux gg=G), à partir du sens du code. l'affichage des accolades en fin de ligne ou à la ligne ne devrait pas être fixé par le dev qui a écrit le code. En fait, on devrait pourvoir sauvegarder le code source sur une ligne, et laisser les éditeurs recréer la structure.

Même en ayant bien suivi ce débat et lu tous les avis, je reste campé au mien : PEP-08, donc 4 espaces et 80 colonnes.

C'est spartiate et arbitraire, certes, mais à l'usage, je me rends compte qu'en imposant ça, tous les devs qui interviennent sur le projet sur lequel je travaille ont fini par prendre le même style de nommage de variables que moi (à savoir des variables locales de 3-4 lettres la plupart du temps, style hdr pour un header, ffd au lieu de folder_file_descriptor), plus personne ne commite du premier coup des chaînes du style doc.root.child('stuff').data.decode('utf-8') (le genre de ligne qui est de toute façon amené à péter un beau jour, parce que doc n'est pas initialisé et n'a pas de noeud root, ou parce que root n'a pas d'enfant nommé stuff, ou parce que ce nœud est potentiellement vide… Sachant que je bosse sur un projet sur lequel on doit de toute manière adopter un style de programmation très défensif), et on peut coder en ouvrant 2 ou 3 fichiers côte à côte sans jamais pourrir l'affichage en forçant l'éditeur à wrapper les lignes.

Par extension, plus on utilise de lignes courtes et atomiques dès le départ, plus lisibles sont les diffs quand on modifie juste un détail.

Alors pour le coup, ouais, je remercie la PEP-08 d'imposer strictement le style de présentation du code et je me félicite que les commits qui ne la respectent pas soient automatiquement rejetés par notre tool de code review, parce que même après un gros rush de 2 semaines de correction de bugs dans l'urgence, notre code base est aussi propre et lisible qu'au départ, donc plus facile à appréhender pour le nouveau qui arrive sur le projet.

En somme, je tenais juste à faire remarquer que quelle que soit la coding-style qui est utilisée à la base dans un projet, il est important que tous les développeurs qui bossent sur ce projet l'adoptent et la respectent pour que cela reste, à tout prix, uniforme, parce que les conséquences de ces choix dépassent largement les seules considérations esthétiques.

PS : Et aussi parce que les commits de réindentation du type qui a décidé d'adopter une coding-style différente et qui a fait un gg=G sur le fichier avant de fixer un bug donné, c'est un des moyens les plus sûrs de se prendre un coup de machette, chez moi.

PPS : Pas parce que je suis violent. Juste parce que ça pourrit complètement les diffs et l'historique du repo.

Au pire, ils embauchent un stagiaire pour faire le refactoring

@nohar : je l'avais déjà coté mais Python est un cas un peu a part. Déja part ce que l'indentation fait partie de la syntaxe du langage (et ce n'est donc pas à l'outils de reformater ton code), ensuite parce qu'il y a effectivement la PEP-8 qui standardise ça et enfin parce qu'en Python3, le mix tab/space provoque des exceptions très facilement (probablement volontairement pour que les dev arrêtent de mixer les deux).

En Python ce n'est pas tant la forme des tabulations qui fait débat, c'est surtout la limite des 80 colonnes.

Je lis à droite à gauche qu'avec des écrans modernes on pourrait passer à 120 colonnes ou plus, mais au final ça ne me convainc pas. Je hais les variables trop verbeuses du style objects_to_delete d'une part, et les longues lignes de 3km dont j'ai oublié le début en arrivant à la fin.

De même, ça a tendance à limiter les niveaux d'indentation, donc ça incite à presenter le code en petites fonctions annexes simples.

Au final, dans un langage dynamique tout-est-objet et black-magic-friendly comme Python, la coding-style est un carcan qui évite de partir en sucette.

Mais je ne parlais pas seulement de Python. En C, en C++ et en Perl aussi j'utilise la PEP correspondant à la coding-style C de CPython, pour les raisons citées plus haut.

@nohar : pour faire du python et avoir essayé de suivre la PEP-8 à la lettre, j'ai une grande question qui m'est venue : comment, grand Dieu comment fait-on tenir du code python sur 80 caractères ? comment ? J'ai des lignes de 100 caractères, mais je peux juste pas décemment les diminuer proprement pour la simple et bonne raison que j'aime avoir des noms de variables explicites, et donc potentiellement longs (après tout, tout le monde a l'autocomplete aujourd'hui, je refuse de faire plaisir à ceux qui ne l'ont pas) et dans ces cas-ci, le moindre appel de fonction ne tient simplement pas sur une ligne… Comment faire dans ce cas ? Des splits dégueulasses au milieu des parenthèses ? Et après tout, pourquoi se limiter à 80 caractères alors que n'importe quel éditeur (éditeurs en console compris) offre une fonctionnalité de soft wrap ? Pourquoi se casser la tête à salir volontairement son code alors que les éditeurs d'aujourd'hui peuvent l'adapter à notre écran/nos splits ?

80 caractères c'est la mort quand même

Dire que l'on met des noms de variables longs parce qu'il y a l'autocomplétition, c'est presque comme dire que c'est mieux d'écrire des preuves à la pré-Newton, parce que tout le monde sait lire le français.

L'avantage des codes court, c'est qu'ils sont facilement lisible surtout.

3 niveaux c'est vrai que c'est un peu faible. 4 ou 5 d'accord, mais 3… par contre je pense effectivement que ça doit être assez vrai dans n'importe quel langage. Quand on commence d'avoir une boucle dans un if d'une autre boucle, mieux vaut essayer de faire des fonctions plus courtes pour mieux s'y retrouver. Sinon difficile de bien voir quels sont tous les cas et scénarios possibles.

Après bon, pour le java, le niveau 1 on ne peut pas vraiment le compter, parce qu'en-dehors des imports, tout est dans une classe. ET les try…catch aussi c'est assez particulier.

Non. Merci.

Pourquoi ? Tu choisis de ne pas avoir un autocomplete, même naïf (je sais que même vim l'a par défaut avec Ctrl+P), c'est ton problème, pas le mien

C'est une question de goût et d'habitude. Personnellement, je n'en ai pas non plus. J'ai horreur d'avoir une espèce de boite de dialogue qui s'ouvre dès que j'écris un mot et qui m'empêche de naviguer confortablement dans mon code avant même de finir d'écrire mon mot. Donc, non, tout le monde n'en utilise pas et ça n'est pas un handicap ni même un "problème".