Bof, perso, que l'indentation change entre les dev, je m'en cogne mais alors, royal... parce qu'il existe un outil tout simple, tout con, pour éviter ce type d'emmerdes: astyle (d'ailleurs, GNU ferait bien de s'en servir quand ils font des release de la libcpp!).
Une fois combiné avec des hook dans le gestionnaire de version, ça ne pause plus vraiment de souci, et il n'y à pas que l'indentation que ça permets de corriger (malheureusement, je ne connait pas d'outil permettant d'altérer les noms d'un code-style à l'autre mais c'est la seule chose qui reste :) ).
Après tout, on impose bien des règles comme "pas d'exceptions, pas de RTTI, etc" dans certains projets, qui sont vérifiées par un outil (le compilo) alors on est plus à ça près.
Et ce n'est pas comme si cet outil était récent, je suis persuadé qu'il existe bien avant python. Au final, mieux vaut laisser les dev faire comme ils veulent, surtout quand on sait qu'il existe des outils permettant de rendre tout le monde heureux (perso, j'utilise -jyntA1 mais il reste quelques détails à corriger qui ne me satisfont pas encore).
Ce n'est quand même pas compliqué de mettre un hook dans git pour vérifier que le style est correct, rejeter sinon (voire éventuellement demander si on force le nettoyage du style, mais j'ai jamais testé cette solution) histoire que le contributeur mette un coup de astyle pour vérifier qu'il n'y à pas de bug introduit. Juste dommage que git prenne en compte les différences de style quand on diff/add. Me demande si y'a pas moyen de l'éviter. Ça ne me surprendrais pas.
Perso, je suis bien plus gêné non par les espaces, mais par le fait de ne pas avoir les accolades sur des lignes spécifiques, parce que mon œil trace instinctivement une ligne entre 2 accolades de même indentation (c'est aussi pour ça que je ne suis pas un super fan des langages qui utilisent begin/end, ou case/esac, mais bon... tant qu'ils sont sur leur ligne spécifique, j'ai rien à redire, ça reste une question de goût.). Donc, sur du code python je suis au final déstabilisé quand même.
De même, je sait directement qu'une ligne est la continuation de la précédente en fonction de l'alignement (indentation complétée à coups d'espaces => continuation de ligne), sans devoir aller lire la fin de la ligne précédente pour vérifier qu'elle à un '\'.
[^] # Re: Parenthèses vs indentation
Posté par freem . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 1.
Bof, perso, que l'indentation change entre les dev, je m'en cogne mais alors, royal... parce qu'il existe un outil tout simple, tout con, pour éviter ce type d'emmerdes: astyle (d'ailleurs, GNU ferait bien de s'en servir quand ils font des release de la libcpp!).
Une fois combiné avec des hook dans le gestionnaire de version, ça ne pause plus vraiment de souci, et il n'y à pas que l'indentation que ça permets de corriger (malheureusement, je ne connait pas d'outil permettant d'altérer les noms d'un code-style à l'autre mais c'est la seule chose qui reste :) ).
Après tout, on impose bien des règles comme "pas d'exceptions, pas de RTTI, etc" dans certains projets, qui sont vérifiées par un outil (le compilo) alors on est plus à ça près.
Et ce n'est pas comme si cet outil était récent, je suis persuadé qu'il existe bien avant python. Au final, mieux vaut laisser les dev faire comme ils veulent, surtout quand on sait qu'il existe des outils permettant de rendre tout le monde heureux (perso, j'utilise -jyntA1 mais il reste quelques détails à corriger qui ne me satisfont pas encore).
Ce n'est quand même pas compliqué de mettre un hook dans git pour vérifier que le style est correct, rejeter sinon (voire éventuellement demander si on force le nettoyage du style, mais j'ai jamais testé cette solution) histoire que le contributeur mette un coup de astyle pour vérifier qu'il n'y à pas de bug introduit. Juste dommage que git prenne en compte les différences de style quand on diff/add. Me demande si y'a pas moyen de l'éviter. Ça ne me surprendrais pas.
Perso, je suis bien plus gêné non par les espaces, mais par le fait de ne pas avoir les accolades sur des lignes spécifiques, parce que mon œil trace instinctivement une ligne entre 2 accolades de même indentation (c'est aussi pour ça que je ne suis pas un super fan des langages qui utilisent begin/end, ou case/esac, mais bon... tant qu'ils sont sur leur ligne spécifique, j'ai rien à redire, ça reste une question de goût.). Donc, sur du code python je suis au final déstabilisé quand même.
De même, je sait directement qu'une ligne est la continuation de la précédente en fonction de l'alignement (indentation complétée à coups d'espaces => continuation de ligne), sans devoir aller lire la fin de la ligne précédente pour vérifier qu'elle à un '\'.