Discussion :

[yahiko]

Des options similaires existent dans Eclipse, dans Visual Studio (via un plugin) et autres. L'alignement à la main, c'est juste pas possible...

[jmi57]

Avec les IDE "modernes" qui formatent le code automatiquement, c'est un peu un débat dépassé je trouve. On peut passer d'une convention à une autre en une fraction de seconde et ça n'impacte pas le versioning, donc bon...

Quand on travaille sur des vieilles technos, si ça arrive . Même en 2016 !

CVS par exemple considère le même fichier sur 2 branches différentes comme différent si un contient des espaces et un autre des tabulations. Ça arrive souvent vu que certains développeurs activent l'option "remplacer les tabulations par des espaces" (et commitent tout sans vérifier ce qui a été modifié !).

Ca pose de gros problème d'intégration...
On va me dire qu'il existe une option sur CVS de type "ignore white spaces"... Alors oui, on ne verra plus les différences, mais ces fichiers sont quand même considérés comme différent, et il faut les comparer un par un afin de vérifier s'il faut les livrer ou pas... Alors quand on a 130 classes impactées dont 70 uniquement pour des histoires de tabulation, ça énerve !

C'est souvent compliqué lorsque le même projet CVS contient des sources JAVA (avec plein de tabulations) et des sources COBOL (uniquement des espaces) par exemple.

Edit : Dans le monde des Bisounours, on ne devrait pas avoir ce problème :

• le code sera bien formatté/indenté dès le départ
• les développeurs n'oublieraient pas de formatter leur modif
• On met en place un système de norme sur la façon de coder (espace vs tab par ex)
• Tous les IDE du même projet seraient configurés de façon identique
• Les développeurs ne commiteraient pas des fichiers non modifiés
• On ne travaillerait plus avec des vieux trucs style CVS

[hbomb]

De notre coté, on code beaucoup en PHP et on utilise les espaces, vu que ce sont les recommandations pour PHP.
Au moins, comme ça, tout le monde voit le même code (puisqu'en plus on utilise le même IDE).

[ac_wingless]

Pour un hobbyiste ou des professionnels intervenant seuls sur leur code, il n'y a aucun problème avec les tabs, il y a même des avantages (soulignés ici par plusieurs).

En revanche, en environnement professionnel, il est pénalisant d'utiliser autre chose qu'uniquement des espaces (pas de tabs du tout, pas de mix).
En effet, sur un programme d'envergure on n'est jamais seul, ou dans un seul langage, ou dans un seul IDE (ou la même version, cf. les nombreuses différences introduites dans VS2013 puis gardées dans 2015 sur la gestion des tabs par rapport à VS2012 qui avait besoin des Powertools). On est aussi toujours dans un environnement SCM. Cette combinaison fait que de nombreux faux positifs interviennent dans les suivis de gestion. Pour une simple modification locale de 50 lignes on a des nouveaux embauchés qui reformattent le fichier à leur gout (parfois sans le savoir, en utilisant l'IDE), et on se prend à rechercher les 50 parmi les 2000. Au delà des étapes de merge proprement dites, il est courant qu'une historique de fichier dépasse les 1000 états. Si quand on l'examine on est parsemé de faux positifs concernant la tabulation, c'est bien plus difficile à gérer.

Nous le voyons régulièrement à chaque nouvelle embauche, malgré la formation sur nos conventions de codage. Il faut quelques semaines voire mois pour arrêter les faux positifs sur les tabs/espaces. Nous exportons par exemple des paramètres de formattage globaux à la société (fonction bien pratique de VS, qu'on n'a pas dans d'autres IDEs plus frustes).

Ceci est général et concerne aussi les conventions de commentaires. Si quelqu'un s'amuse à reformater ce que quelqu'un d'autre a écrit, on a aussi de faux positifs. Les outils SCM ne sont pas tous cohérents sur le filtrage, et de nombreux cas passent nos filtres (nous utilisons Perforce/Helix).

Un cas récent concerne les lambdas en C++: le formattage par défaut de VS ne gère bien sûr pas tous les cas correctement, avec des indentations aberrantes. Nous ne savons pas encore comment gérer ceci correctement, mais au moins n'avoir que des espaces limite la casse.

[SylvainPV]

@ac_wingless: Il suffit de s'accorder sur une convention de style en début de projet et d'intégrer un style checker dans la phase de build. J'ai toujours utilisé les tabulations en environnement professionnel et ça se passe très bien D'autant que ce problème de faux positifs se pose aussi bien pour les tabulations que pour les espaces d'après tes dires. Bien sûr, si quelqu'un dans l'équipe configure n'importe comment son IDE et désactive le style checker, là on aura toujours un problème mais il sera davantage de nature humaine que technique.

[TiranusKBX]

Perso j'utilise les tabulation puis les espaces pour faire des jolis alignement d'assignation de variable

[ac_wingless]

@SylvainPV: c'est bien évidemment du problème humain que je parle.
"Il suffit de s'accorder sur une convention de style en début de projet". C'est un peu ce que dit jmi57 dans sa liste. Ta phrase n'existe tout simplement pas dans les programmes un peu gros.

[d3v10]

Dans un monde parfait, le SCM stockerait le code en brut ou dans un format pré-défini et la conversion se ferait à la volée côté client selon le paramétrage du format défini dans les préférences de l'IDE. Fini les débats sur le formatage, les conventions de style, les comparaisons de code foireuses suite à un reformatage en masse, etc. A chacun ses préférences sans que ça crée d'impact en équipe. On vit encore à l'âge de pierre sur ce sujet-là, les outils doivent évoluer.

[SylvainPV]

"Il suffit de s'accorder sur une convention de style en début de projet". C'est un peu ce que dit jmi57 dans sa liste. Ta phrase n'existe tout simplement pas dans les programmes un peu gros.

En fait c'est précisément sur les gros projets qu'on s'accorde sur une convention de style, puisque c'est eux qui occasionnent le plus de maintenance et le plus grand nombre de développeurs différents. Pour les petits projets, on est moins regardants et la chaîne d'intégration est plus "légère".

Il y a parfois des débats internes sur telle ou telle règle de style, mais généralement on clôt le débat assez vite sur l'argument que peu importe la convention choisie, le plus important est que tout le monde suive la même.

[jmi57]

En fait c'est précisément sur les gros projets qu'on s'accorde sur une convention de style, puisque c'est eux qui occasionnent le plus de maintenance et le plus grand nombre de développeurs différents. Pour les petits projets, on est moins regardants et la chaîne d'intégration est plus "légère".

Il y a parfois des débats internes sur telle ou telle règle de style, mais généralement on clôt le débat assez vite sur l'argument que peu importe la convention choisie, le plus important est que tout le monde suive la même.

Je suis d'accord avec toi sur les nouveaux projets en effet.
Si on met en place des processus très stricts dès les premières lignes de code, on ne rencontre pas trop ce genre de problèmes.

Par contre, quand on récupère la maintenance d'un projet, et que le "style checker" n'a a jamais été mis en place, c'est chaud à rattraper...

[ac_wingless]

En fait c'est précisément sur les gros projets qu'on s'accorde sur une convention de style, puisque c'est eux qui occasionnent le plus de maintenance et le plus grand nombre de développeurs différents. Pour les petits projets, on est moins regardants et la chaîne d'intégration est plus "légère".

Il y a parfois des débats internes sur telle ou telle règle de style, mais généralement on clôt le débat assez vite sur l'argument que peu importe la convention choisie, le plus important est que tout le monde suive la même.

Je parle de choses très concrètes: un stagiaire/sous traitant/consultant/nouvel embauché installe VS2015, check-out un fichier, fait sa modif, fait son Ctrl-K+D Ctrl-S et submit vers une branche de dev. Son collègue fait une autre modif, et submit en respectant la fameuse "convention de style". Ou bien l'un travaille sur C++ Builder et l'autre sur VS. Ou bien l'un est indiscipliné et n'en a rien à foutre de ce boulot de merde alors que l'autre est tout juste promu et fayote. Dire que ces cas n'arrivent pas est assez utopique (jmi57 parle même de "bisounours"), d'autant plus que le nombre de programmeurs est grand, la durée longue (décennies), les langages et outils différents, et le déploiement complexe. Or les conséquences sont définitives (c'est comme la compta: on ne peut plus enlever!) et peuvent "percoler" jusqu'à rendre l'historique des versions inutilisable.

En effet, les lignes communes sont détectées différentes. Les dégâts ne se limitent pas à un resolve fastidieux, car l'historique de modification est polluée définitivement, et se propage de branche à branche. Pire, son inverse se propage aussi si quelqu'un se met en tête de "corriger" l'erreur, surtout plus tard quand 50 autres commits sont intervenus entre temps. Deux ans après, quand on regarde l'historique sur une release pour un bug client, on voit une contribution d'une AUTRE personne que le coupable ou son collègue innocent, celui qui a fait l'intégration 3 semaines plus tard. Au lieu de voir cette intégration et sa documentation, on voit des modifications qui n'ont aucun rapport.

A l'usage (désolé d'être un peu vieux, mais avec 31 ans de carrière j'en ai vu des exemples de gros programmes qui merdent), les outils SCM ont réussi à faire abstraction de problèmes simples (CR/LF vs CR, trailing white space), mais sont toujours pourris au niveau tab/espace, malheureusement pour une raison assez fondamentale tant qu'il n'auront pas une connaissance sous-jacente leur permettant d'analyser le texte (peut-être un jour avec LLVM?). Même Helix, qui est quand même assez moderne, n'est pas cohérent sur ses filtres: les outils de resolve font bien abstraction de ce qui est attendu en matière de mix tabs/space, je dirais même avec finesse, mais le mécanisme de détection de conflit est beaucoup plus strict au niveau du serveur, sans doute parce qu'il doit être général et par exemple détecter les évolutions de fichiers binaires ou mixant binaire et texte. Résultat: même si le merge se fait bien ou facilement, l'historique est polluée irrémédiablement. Si on a 200 ou 300 branches, avec même juste 3 gugusses qui s'amusent à ça de temps en temps, au bout de 5 ans c'est une galère.

Dans la réalité de la gestion de projet, ignorer les techniques défensives simples en faisant confiance aux vœux pieux est risqué. C'est pourquoi je me permets d'être en désaccord avec ta recommandation. Pour moi, c'est un peu comme si tu répondais à quelqu'un qui conseille la programmation défensive "en fait, plus le programme est complexe, plus les enjeux en termes de qualité sont gros, et plus les gens font attention, donc pas la peine".

[SylvainPV]

Je ne connais pas bien le monde C++ mais ça doit bien exister un style checker pour ce langage non ? Tiens je viens d'en tomber sur un : https://kitware.github.io/KWStyle/

Il ne s'agit pas de vœux pieux, quand je dis qu'on s'accorde sur une convention de style, je veux dire par là qu'on s'accorde sur une configuration du style checker qui tournera systématiquement à chaque modification des sources et s'exécute avant chaque commit. Le seul moyen d'outrepasser cette règle est de désactiver manuellement le style checker en modifiant la config de build. Personne ne l'a fait jusqu'ici, et je pense que celui qui ose aura vite droit à un recadrage.

[jmi57]

Je parle de choses très concrètes: un stagiaire/sous traitant/consultant/nouvel embauché installe VS2015, check-out un fichier, fait sa modif, fait son Ctrl-K+D Ctrl-S et submit vers une branche de dev. Son collègue fait une autre modif, et submit en respectant la fameuse "convention de style". Ou bien l'un travaille sur C++ Builder et l'autre sur VS. Ou bien l'un est indiscipliné et n'en a rien à foutre de ce boulot de merde alors que l'autre est tout juste promu et fayote. Dire que ces cas n'arrivent pas est assez utopique (jmi57 parle même de "bisounours"), d'autant plus que le nombre de programmeurs est grand, la durée longue (décennies), les langages et outils différents, et le déploiement complexe. Or les conséquences sont définitives (c'est comme la compta: on ne peut plus enlever!) et peuvent "percoler" jusqu'à rendre l'historique des versions inutilisable.

Oui j'aime bien le terme "monde des bisounours". Dans la théorie la MOA fait des docs fonctionnelles toutes propres, les développeurs font du code tout beau et bien commenté, les tests sont réalisés correctement et les chefs de projets encadrent très bien leur équipe et tous les plannings sont respectés... ALors on peut mettre en place tout plein de conventions et documentation en place. Dont les fameuses "convention de styles".

En vrai, la MOA ne sait pas ce qu'elle veut et se contredit, les chefs de projets sont débordés, les développeurs font tout dans l'urgence et ne sont pas toujours très rigoureux, et il y a un réel turn-over au sein de l'équipe (en tout cas sur des projets gérés par des prestataires...) Aors respecter une "convention de style" est loin d'être une priorité sur un projet.
Ca a comme effet de rendre du code illisible et non documenté. Et comme dit ac_wingless l'historique des versions devient inutilisable.
Alors au bout de quelques années, un développement sera beaucoup plus long à faire, et on prendra encore plus de retard...

Bien enendu, il y a les adeptes des outils homogènes.
Je suis tout à fait pour d'ailleurs mettre en place (dans le monde Java) une plate-forme d'intégration continue, et des IDE identiques et configurés de manière identique pour tous les développeurs.
Mais il y a aura toujours un développeur qui aura une config différente soit par choix, soit par mégarde.
Et même au bout de 2 ou 3 ans , il faudra bien mettre à jour les outils. Et là paf, on oublie une config sur la nouvelle version de l'IDE et hop le code change de format...

Ou alors on travaille en mode ultra-sécurisé. Avec des verrous de partout, des relectures de codes ultra-poussés entre collègues, des outils ultraprefectionnés qui ne laissent rien passer... Mais dans ce cas le projet n'avance plus... On commence tellement à réfléchir sur la forme du code qu'on ne réfléchit plus vraiment sur l'algorithme lui-même...

[Logan Mauzaize]

Edit : Dans le monde des Bisounours, on ne devrait pas avoir ce problème :

• le code sera bien formatté/indenté dès le départ
• les développeurs n'oublieraient pas de formatter leur modif
• On met en place un système de norme sur la façon de coder (espace vs tab par ex)
• Tous les IDE du même projet seraient configurés de façon identique
• Les développeurs ne commiteraient pas des fichiers non modifiés
• On ne travaillerait plus avec des vieux trucs style CVS

Je pense que tu as également oublié :

• la convention ne change pas en cours de route
• le formatteur et le checker ont été bien configurés pour être cohérent

Pour le problème humain, à mon avis, c'est surtout lié au manque de "dev leader" / "responsable technique" attitré dans les projets. On pense souvent à placer un "chef de projet" pour fliquer le planning et les dépenses mais moins souvent à la personne qui va fliquer le code et le travail réalisé. Ce n'est pas un rôle très sympas (je sais ce que c'est, je l'ai fait) mais je pense nécessaire pour un projet sur le long terme et si on a une conscience professionnelle.

J'ai toujours travaillé dans un environnement avec des personnes volontaires, et les personnes ayant fait des erreurs ont toujours acceptés de se corriger. Si ce n'est pas le cas, je ne suis pas sûr que ce(s) personne(s) soi(en)t adapté(s) au projet et pour le travail en équipe de manière générale.

[Madmac]

La tabulation devrait-être la norme. Tout simplement parce que cela permet de personnaliser l'indentation du code selon les préférences personnelles des individus sans que cela affecte le code.
Permettre ce genre de flexibilité est une délicatesse que me semble normal entre collaborateurs

De plus, avec des langages comme python, oublie un espace d'un caractère est difficile à repérer.

[jmi57]

La tabulation devrait-être la norme. Tout simplement parce que cela permet de personnaliser l'indentation du code selon les préférences personnelles des individus sans que cela affecte le code.
Permettre ce genre de flexibilité est une délicatesse que me semble normal entre collaborateurs

De plus, avec des langages comme python, oublie un espace d'un caractère est difficile à repérer.

Pour Python ou Java d'accord.

Mais d'autres langages comme COBOL fonctionnent en "position".
Or 1 espace = 1 position.
Le code commence réellement à la position 8.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

      * voici une ligne de commentaire COBOL

Comment gérer les tabulations alors ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

tab tab * voici une ligne de commentaire COBOL

Alors le Coboliste qui travaille sous Eclipse va configurer son IDE pour remplacer une tabulation par 4 espaces par exemple.

[jmi57]

cela permet de personnaliser l'indentation du code selon les préférences personnelles des individus sans que cela affecte le code.

Tout-à-fait d'accord.

En fait, souvent on considère la tabulation comme un ensemble d'espaces. Mais non. La tabulation ne sert pas à éviter d'appuyer 4 fois sur la touche espace.

La tabulation est en effet un "curseur" configurable (que ce soit au niveau du code ou d'un traitement de texte) qui définit le passage d'une zone à une autre.
Donc dans la théorie, on ne peut pas remplacer une tabulation par n espaces, ça n'a pas de logique.

En réalité, c'est courant de faire ça. Même les IDE ont des options pour cela...

[CoderInTheDark]

La tabulation devrait-être la norme. Tout simplement parce que cela permet de personnaliser l'indentation du code selon les préférences
De plus, avec des langages comme python, oublie un espace d'un caractère est difficile à repérer.

Je commence python et c'est ma hantise de faire une erreur de bloque.
J'aimerai bien avoir du Python avec accolades

Alors je pense mettre des commentaires pour pas me perdre
#End if #End for ....
Un peu comme en Pascal car je trouve ça dangereux
Une collègue faisait ça sur notre code javas.
Je trouvait ça un peu exagéré, mais quand on code sans les yeux ça aide.

En ce moment ça va car je fais que des petits Script Python pour découvrir
Mais sur un gros script ça doit être facil de se perdre

[Logan Mauzaize]

Je commence python et c'est ma hantise de faire une erreur de bloque.
J'aimerai bien avoir du Python avec accolades

Regardes du côté de Ruby ou Crystal

[yahiko]

Je trouve tout de même "surprenant" que les résultats du sondage sur ce topic soit diamétralement opposé aux statistiques sur Github.
J'aurais tendance à penser que la population des développeurs qui ont répondu ici n'est pas vraiment représentative. J'aurais été curieux de savoir quel était le langage de prédilection de chaque votant.