Discussion :

[koala01]

Perso j'en fais parti...
Après ça vient certainement du fait que je fais du calcul scientifique et qu'il faut avoir une limite très ferme à l'OO. A trop en mettre on perd la lisibilité des equations, de la problématique qu'on traite (et surtout l'optimisation). A ne pas en mettre on perd de la flexibilité. Il faut placer un curseur.

Mais, là, on aborde un thème particulier qui est plutôt... le choix du bon outil pour faire ce que l'on souhaite.

A l'extrème limite (en fait, non, même pas à la limite ), dans ton cas particulier, un langage fonctionnel sera très largement supérieur à n'importe quel langage impératif, OO ou no

Ce qui pourrait le plus s'en rapprocher en C++, c'est la programmation générique, mais sur le long terme, cela risque de poser des problèmes de... temps de compilation (surtout si le calcul à exécuter est complexe )

Il faut bien comprendre que même les langages qui se veulent "généralistes" sont souvent malgré tout "particulièrement adaptés" à une utilisation particulière, ou à des besoins particuliers.

On peut, bien sur, faire tout avec tout, mais il faut avouer que les langage .NET (C# entre autres) seront plus faciles à l'intégration dans les outils de chez microsoft, que java sera à préférer si l'idée est de fournir un applet web, que C sera sans doute plus intéressant pour créer un pilote de carte PCI et que C++ sera très intéressant dans de nombreux autres cas (ce ne sont que des exemples, hein )

De même, bien que depuis sa sortie, on considère que l'OO est "la solution ultime", ou peu s'en faut, à "tous les problèmes", il faut admettre que le pur paradigme procédural ou ou le paradigme générique, voire, le paradigme fonctionnel ont de très beaux jours devant eux dans certaines situations.

Pour finir je pense que:
Ce n'est pas parce que tu as une voiture qui peut rouler à 200km/h que tu dois rouler en toutes circonstances à 200km/h.

non, parce que tu as quelque chose (de sensé) qui te l'interdit et que l'on appelle le code de la route

Dans le cas des règles que l'on remet en cause, cela reviendrait à placer un article dans le code de la route qui t'obligerait à avoir au minimum une "galette" t'interdisant de rouler à plus de 80 km/h comme roue utilisée: cela n'aurait aucun sens, quand on sait le danger que représentent ce type de galettes, et quand on sait que la vitesse est limitée à 120 en certains endroits (en Belgique, du moins, 130 en France, 110 au Luxembourg )

[Luc Hermitte]

[C++ Moderne]
a- Après ça vient certainement du fait que je fais du calcul scientifique et qu'il faut avoir une limite très ferme à l'OO.
b- A trop en mettre on perd la lisibilité des equations,

a- Hum ...
Ma vision de modernité du C++ vient de la constatation que le C++ c'est bien plus que de l'OO. C'est aussi une bibliothèque standard non OO (<algorithm> & cie), et du RAII.

Pour d'autres, c'est de l'abus de templates. Et ma foi Blitz++ était une expérience très intéressante en matière de calcul scientifique.

b- Mouais. SAXPY n'est pas quelque chose que je trouve très lisible personnellement quand on compare à ce que nous apportent des libs matricielles C++ (boost.ublas, Blitz++, newmat, ...)
C'est une question d'habitude certainement.


Pour rebondir sur d'autres choses qui ont été dites.
Je n'aime pas non plus les standards qui ressemblent à du nivellement par le bas. Mais si on veut sortir de cela, il ne faut pas rester passif, mais discuter des règles déjà existantes, en montrer d'autres plus pertinentes, former les gens, etc.
Où je suis, j'ai dépoussiéré des règles qui dataient d'avant le standard. Du coup, j'en ai profité pour faire du ménage et dégager des choses comme "sus au SEME" et enforcer à la place "le RAII tu utiliseras" et "ta fonction, courte tu maintiendras" (et expliquer pourquoi ailleurs le SESE est obligatoire, mais pas ici (ici == C++ RAIIen)), ou virer encore "jamais tu ne pré-incrémenteras" (WTF?!) pour parler à la place de choses comme le LSP, déméter, etc.
Bref, j'ai écarté les artéfacts de syntaxe sans importance pour recentrer sur les éléments nécessaires à une maintenance en douceur.

Ai-je trop nivelé par le haut à la place ? C'est une bonne question. Avec une migration des masses & nouveaux projets vers d'autres langages qui paraissent plus simples je ne pense pas qu'il soit si grave d'avoir inversé le sens du nivellement.

Dernier truc, je confirme que les règles de google ont une visibilité non négligeable, elles ont déjà été évoquées à plusieurs reprises sur SO, ici, sur clc++(m), etc. Quand on regarde la genèse des règles en cours dans nos sociétés, je soupçonne que de tels documents ont plus d'impacts que des ressources comme le bouquin de Sutter & Alexandrescu. Ce n'est pas parce que des règles sont imposées qu'il ne faut pas discuter/éduquer ceux qui les pondent voire se substituer à eux.

[Goten]

C++ modern ne veut pas dire OO (j'ai même envie de dire, au contraire).

(parce que c'est passer à la trappe).

"jamais tu ne pré-incrémenteras" (WTF?!)

T'as vraiment trouvé ça? wow, en effet, WTF .

[koala01]

Où je suis, j'ai dépoussiéré des règles qui dataient d'avant le standard. Du coup, j'en ai profité pour faire du ménage et dégager des choses comme "sus au SEME" et enforcer à la place "le RAII tu utiliseras" et "ta fonction, courte tu maintiendras" (et expliquer pourquoi ailleurs le SESE est obligatoire, mais pas ici (ici == C++ RAIIen)), ou virer encore "jamais tu ne pré-incrémenteras" (WTF?!) pour parler à la place de choses comme le LSP, déméter, etc.
Bref, j'ai écarté les artéfacts de syntaxe sans importance pour recentrer sur les éléments nécessaires à une maintenance en douceur.

Ai-je trop nivelé par le haut à la place ? C'est une bonne question. Avec une migration des masses & nouveaux projets vers d'autres langages qui paraissent plus simples je ne pense pas qu'il soit si grave d'avoir inversé le sens du nivellement.

Je ne crois honnêtement pas...

J'aurais tendance à dire que tu as fait un nivellement "sensé", en incitant les gens qui n'ont jamais entendu parler de certains principes jugés primordiaux à s'y intéresser, et en incitant les "vieux briscards" (soit dit sans offance ) à se remettre en question (au niveau de SESE, par exemple)

Tu aurais sans doute poussé le nivellement vers le haut à l'extrême si tu avais introduit des règles (tout aussi absurdes ) comme "toute fonction / classe doit en priorité être implémentée sous forme générique"... ce que je doute que tu aies fait

[Luc Hermitte]

T'as vraiment trouvé ça? wow, en effet, WTF .

Au milieu d'autres choses dont je comprenais mieux l'origine comme "pas d'héritage privé" -- à la place, j'ai préféré expliquer LSP et réutilisation --, ou pas d'opérateur ternaire (là j'ai montré comment le rendre lisible, et j'ai rappelé les règles sur const-proactif et sur les fonctions courtes.
[EDIT: J'ai poussé le vice à ne pas effacer les règles aberrantes (de mon point de vue) qui sont récurrentes, pour à la place écrire des contre-règles/conseils préventifs à destination de futurs mainteneurs du document]

Tu aurais sans doute poussé le nivellement vers le haut à l'extrême si tu avais introduit des règles (tout aussi absurdes ) comme "toute fonction / classe doit en priorité être implémentée sous forme générique"... ce que je doute que tu aies fait

Ceci n'est plus du nivellement. Comme tu le dis très bien, c'est absurde.

[koala01]

Ceci n'est plus du nivellement. Comme tu le dis très bien, c'est absurde.

Ben oui, je sais bien, mais c'est le seul exemple "suffisamment gros" qui me soit venu à l'esprit

Mais le niveau d'absurdité d'une règle tirant à vue sur le SEME, interdisant les exceptions ou préconisant une fonction init à la place du RAII me semble tout à fait identique

[ac_wingless]

Désolé, mais vu ce sur quoi tourne la discussion, je pense qu'il faut un peu remettre en contexte les règles de codage et à quoi elles servent.

Support des outils.
Il n'y a pas que Visual Studio 10 / gcc 4.5 dans notre métier. Une proportion incalculable mais très élevée des projets C++ n'a pas un seul compilateur mais plusieurs, dont certains n'ont tout bêtement pas de support pour un tas d'éléments du C++ moderne, ou bien les supportent avec des petits tics incompatibles (comment vous portez du C++ moderne depuis x86 vers le dernier DSP? comment vous portez les codes avec constructeurs sur les architectures à mémoire fixe? comment vous "démanglez" entre deux puces de constructeurs différents? comment vous implémentez une fonction virtuelle sur GPU (merci Fermi!!!)? etc. ). En attendant, il faut livrer le code, parce que la programmation pure ne pèse pas forcément grand chose dans l'édifice: il y a des dizaines d'autres corps de métier qui ne se sentent pas concernés par les ergotages acronymiques C++iens. Comment dire au responsable du génie civil qui vient de couler 1300 tonnes de béton qu'il faut revenir l'année prochaine parce qu'on a eu un problème de régression de templates au passage de VS2008 à VS2010?

Pourquoi est-ce qu'on utilise encore le C dans l'embarqué? Parce que si on utilise le compilateur C++ disponible (s'il y en a un), on n'a pas de fiabilité avec les templates, tr1 et tout le tralala. Ce n'est parce que C serait plus adapté! Pourquoi on utilise l'assembleur? Parce dès fois qu'on n'a même pas C (je n'ai heureusement plus d'exemple en 2010, mais c'était encore vrai il y a peu, et cela le reste pour le support de projets allant de 3 à 25 ans d'age).

Donc les règles de codage ont une importance ABSOLUMENT CAPITALE dans la partie programmation des projets non purement informatiques: il est exclu de prendre le moindre risque pour des raisons de productivité de ce qui n'est qu'une portion du système, si importante qu'elle nous paraisse. Discuter de nivellement par le bas ou par le haut du point de vue du programmeur est donc HORS SUJET: on nivelle au niveau des outils disponibles, qui se trouve être bas par définition, puisqu'il n'est matériellement pas possible d'être à la pointe de la productivité dans des projets d'envergure ne serait-ce que par leur durée significative et leur étendue de domaine.
Tant pis pour la productivité de l'équipe informatique, les autres corps de métier en font autant dans leur domaine de toute façon.

En déduire un peu rapidement que "des grosses boites font des choses qui peuvent ne pas être bonnes", ou que les développeurs impliqués "n'aiment pas le C++ moderne" est désobligeant, et heureusement sans fondement. Une bonne partie des innovations et du C++ moderne vient aussi de ces grosses sociétés ayant en place des règles de codage nivelant par le bas. Outre les exemples passés (C++ est né dans un labo d'une grosse boite...), on peut parier qu'à l'avenir les divers outils nécessités par l'industrie continuent d'enrichir le standard. Par exemple, je pratique de plus en plus des règles de codage intégrant un mécanisme permettant d'obtenir des "exceptions déterministes". Comme indiqué dans mon post précédent, les exceptions au sens C++ sont interdites dans nombre de projets industriels pour de très bonnes raisons. Cependant, l'intérêt des exceptions n'échappe pas à ces benêts aux commandes dans les grosses boites...

Fiabilité interne et externe
Je sais pas avec quelles équipes vous tournez, mais en ce qui me concerne, même si je pense avoir une équipe du tonnerre avec qui on a pu sortir des projets incroyables qui ont laissé nos partenaires et clients stupéfaits, on a tous des jours sans, des problèmes de gamins à garder, des vacances à prendre, et puis ça reste un métier, pas une art ou une croisade. Certains d'entre nous ont bien plus de 25 ans. Si, si, je sais c'est dur à croire mais c'est vrai.
Dans ces conditions, il n'est pas toujours possible de demander à toute l'équipe, à des stagiaires, à des intérimaires, voire aux sous-traitants ou intervenants extérieurs d'adopter des mêmes pratiques de codage évangélistes, quelles que soient les qualités de ces pratiques. Une règle de codage prend en compte la réalité qui fait qu'une équipe n'est pas homogène. Dans ce cas se pose la question du niveau à cibler, une fois pris en compte le principal ci-dessus (le niveau proposé par les outils): vers le bas, ou vers le haut? Et pourquoi pas viser juste?

Dans bien des projets, il faut accepter que des intervenants non payés suffisamment n'auront pas la motivation, la formation ou la compétence de mettre en œuvre des méthodes sophistiquées.
Même pour du personnel de très haut niveau ultra-bien payé, des problèmes d'un autre ordre se posent: il faut aussi réaliser que dans certains pays, les relations programmeur / employeur sont des rapports de force sans pitié ni état d'âme... dans les deux sens. Je ne vais pas rentrer dans les détails, mais ceux qui ont travaillé aux USA savent de quoi je parle, et plus encore ceux qui ont employé des programmeurs dans un environnement par exemple texan.

Pour maitriser ces phénomènes, il faut donc viser un niveau qui tienne compte à la fois de la productivité et de la maitrise du projet (vu du point de vue de la grosse boite, pas de celui du chef de projet). Bien évidemment, ce niveau en question n'a aucune raison de coïncider avec ce qu'un programmeur individuel ou habitué a de petites équipes se croit en droit d'espérer.

Inertia or momentum?
Si on fait abstraction des deux points évoqués ci-dessus (nivellement par les outils et par l'équipe), et qu'on se place dans un cas idéal: disons, deux ou trois personnes motivées démarrent un projet open source sans but lucratif, sous environnement VC10 / Boost 1.43 avec des PC de fous, sans date limite. Quelles vont-être les règles de codage? On voit d'après cette discussion qu'il va y avoir un peu de bagarre sur des points de détail. On peut aussi prédire des changements assez fréquents. On peut enfin être certain que les règles en question vont être bien plus "évoluées" que celles des projets industriels significatifs.
Par contre on voit aussi tout de suite à quel point c'est impossible à mettre en place dans une structure de grande taille, même à supposer une homogénéité et une qualité exceptionnelle de l'équipe. Imaginons des règles de codage démocratiques chez la R&D Thales, juste pour rire!
Être à la pointe des recherches en productivité a pour contrepartie obligatoire l'impossibilité d'avoir fait ses preuves sur la durée. On en revient aux grands classiques: quel équilibre entre la réactivité et la stabilité? C'est un problème presque culturel et n'ayant pas de solution tranchée.
(petit hors sujet pour montrer l'universalité de la question: doit-on virer la moitié du personnel dans les mauvaises années et rater le redémarrage, comme Boeing, ou bien tenir son cap coute que coute, et foncer dans le mur comme Airbus réalisant deux ans trop tard ses problèmes d'assemblage de l'A380?)

Productivité globale
Alors on a défini un niveau de programmation selon les outils, les intervenants, et on a choisi un niveau de réactivité. Il reste un paramètre: l'arbitrage entre l'assurance qualité et la programmation. Il est clair que les couts d'assurance qualité vont baisser si le code est facile à contrôler automatiquement, ce qui ne se fait aujourd'hui qu'avec des règles de codages simples.
On a un effet pervers à l'œuvre: en simplifiant la palette utilisable en programmation, on facilite le travail du contrôleur de la qualité sans assurer une meilleure qualité, bien au contraire. Tout en perdant de la productivité!

Mais là encore, tout n'est pas aussi simple: si on ne met pas en place des règles strictes et enforçables, on s'expose à des catastrophes, et comme on est dans le cadre de grosses boites voyant défiler des nuées de programmeurs, la loi de la Tartine s'applique. Alors que faire? Pour voir, prenez une feuille blanche, et remplissez là. Relisez bien le résultat. Allez voir votre responsable QA et votre directeur régional. Séchez vos larmes, et recommencez...

Conclusion
Les règles de codage ont ceci comme avantage qu'elles ont une vue bien plus ambitieuse de la fiabilité que la myopie focalisée sur le code seul: elles établissent, et valident dans des cas difficiles, des pratiques globales, pragmatiques et débarrassées de tout évangélisme plus ou moins durable. Elles prennent en compte localement (projet ou entreprise) l'environnement industriel, économique, voire sociologique et culturel de la programmation.
Dans tous les cas que j'ai vu, les règles de codages ne sont pas pondues par un stagiaire après coup, mais sont au contraire extrêmement bien réfléchies, raffinées au cours des années, avec des rationalisations élaborées sur pratiquement tous les points (à ce propos, le document de Google cité au départ me semble beaucoup moins élaboré que les règles de codage d'autres grandes entreprises, comme je le disais dans mon post précédent).

Comme ces règles sont en général beaucoup moins permissives que celles de Google, tout en ayant fait leurs preuves sur des projets parfois remarquables, je suis un peu estomaqué de voire l'arrogance avec laquelle elles sont considérées dans cette discussion. Je n'ai pas encore lu le principe de Peter, mais on dirait que ça vient...
Et si en fait les professionnels ayant pondu ces documents savaient en fait de quoi ils parlent, avaient pesé le pour et le contre à la lumière de projets réels, et pris des décisions éclairées?

[Klaim]

Pour résumer globalement, c'est principalement une question de pragmatisme.

Juste?

[nikko34]

Pour résumer, chacun ses contraintes (plus ou moins justifiées), mais pas la peine de s'en rajouter parce que "google fait comme ça". Tout le monde n'est pas google.

[Goten]

Comme ces règles sont en général beaucoup moins permissives que celles de Google, tout en ayant fait leurs preuves sur des projets parfois remarquables, je suis un peu estomaqué de voire l'arrogance avec laquelle elles sont considérées dans cette discussion. Je n'ai pas encore lu le principe de Peter, mais on dirait que ça vient...
Et si en fait les professionnels ayant pondu ces documents savaient en fait de quoi ils parlent, avaient pesé le pour et le contre à la lumière de projets réels, et pris des décisions éclairées?

On n'a pas craché sur google hein non plus faut voir à pas exagérer. On discute d'un papier (ici c'est des règles) qu'un forumeur a posté, comme on aurait pu discuter du dernier papier d'(Alexandrescu|inséré qui vous voulez) et ne pas être totalement d'accord avec lui, c'est tout. Si on peut même plus discuter de règles sans être taxé d'arrogance autant mettre la clef sous la porte hein...

[gl]

Désolé, mais vu ce sur quoi tourne la discussion, je pense qu'il faut un peu remettre en contexte les règles de codage et à quoi elles servent.

<snip>

Je comprends ton propos et globalement je suis assez d'accord avec ce que tu dis.

Maintenant, commenter, expliquer ou discuter de ce type de règles hors d'un contexte particulier ne signifie pas forcément casser du sucre sur le dos de Google.

Partager les différents points de vue est assez intéressant (même si, dans la forme, certains propos peuvent paraitre un peu extrême).

En outre, comme la fait remarque Loic dans un message, si cela permet de faire comprendre les limites et raison d'être de certaines règles et qu'elles sont valables (enfin pas toujours) dans un contexte particulier et donc pas transposables tel quel ailleurs - bref si cette discussion permet de pousser les gens à réfléchir à la mise en place de règles appropriées plutôt que de récupérer des règles toutes faites mais inapplicables - je pense que c'est positif.

[ox223252]

Aujourd'hui je viens de me faire gronder car mes accolade sont sur une ligne vide et car mes indentation sont de d'une tabulation, alors que c'est pas ce qui est marqué dans les regles google (non je ne travail pas chez google et le projet ne suit pas de regles particulière )

Je me demande qui à pondu les règles googles, je me demande si il programmes , car après 10h sur mon éditeur de texe une indentation de deux espaces et illisible ^^.

Sinon plus globalement j'ai travaillé pour des projets dans le militaire et dans le médicale, et je peux vous garantir que les règles google ils s'en tamponnes, pour eux ce qui compte c'est la simplicité et la lisibilié du truc qui compte vaiment. Et quand on voit leurs raisons on peut se dire qu'ils ont raison.

par exemple ça ils en veulent pas :

Code :

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

if(test==0&&truc>2)machin=3;

c'est remplacé par ça :

Code :

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

1
2
3
4
if ( ( l_uiTest == 0 ) && ( l_uiTruc > 2 ) )
{
	l_uiMachin = 3;
}

Ca c'est vérifié par un logiciel et tout code qui ne correspont pas aux éxigences doit être éxpliqué et justifié, car la vie de gens est en jeux derrière

[Luc Hermitte]

En matière d'indentation, il y a deux règles, valables partout:
1- on indente sous les structures de contrôles, et dans les définitions (struct & co, fonctions...)
2- on ne mélange pas tab et espace.

Après tab ou espace, chacun a des arguments pour l'un ou pour l'autre. Mais souvent, il s'agit de mélanger des outils qui ne sont pas configurés pareil, voire pas configurés.

Pour le reste, c'est toujours la problématique que des gens veulent un style uniforme partout. Certains sont très rigides là dessus, et il ne s'agit pas toujours des premiers concernés (i.e. les développeurs).

Et vu qu'il s'agit d'un déterrage, on peut dire que depuis les CppCoreguidelines sont sorties et qu'elles méritent d'être employées pour dépoussiérer bien des choses que l'on utilise.

[ox223252]

Et vu qu'il s'agit d'un déterrage, on peut dire que depuis les CppCoreguidelines sont sorties et qu'elles méritent d'être employées pour dépoussiérer bien des choses que l'on utilise.

J'avais pas vu la date, mais le sujet reste d'actualité

[foetus]

2- on ne mélange pas tab et espace.

Si on peut le faire les tabulations c'est pour indenter (début de lignes - à gauche), et les espaces pour "l'ascii art" (en fin de lignes - à droite)

Exemple:

Code :

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

1
2
3
4
5
6
7
8
9
    var a    = 0;
    var a1   = 0;
    var a2   = 0;
    var b    = 0;
    var b01  = 0;
    var b02  = 0;
    var c    = 0;
    var c001 = 0;
    var c002 = 0;

[Bktero]

Notez que les règles de codage de Google sont désormais ici : https://google.github.io/styleguide/cppguide.html




L'ASCII art c'est de la cr***e !

[Luc Hermitte]

Si on peut le faire les tabulations c'est pour indenter (début de lignes - à gauche), et les espaces pour "l'ascii art" (en fin de lignes - à droite)

Effectivement, c'est la seule façon intelligente de les mixer.

Dans les faits il n'y a que emacs qui sache faire ça je crois. Du coup, ce n'est pas vraiment utilisable sur un projet où notepad++, emacs, eclipse, QtCreator sont chacun utilisés par une personne différente.

[Mickael_Istria]

Si on peut le faire les tabulations c'est pour indenter (début de lignes - à gauche), et les espaces pour "l'ascii art" (en fin de lignes - à droite)

Tout a fait d'accord! J'avais chercher a repandre la bonne parole dans un blog il y a quelques mois: https://mickaelistria.wordpress.com/...bs-and-spaces/
L'air de rien ce debat est serieux, il concerne la lisibilite/portabilite du code et il contient des notions de models vs rendering qui sont importantes dans pas mal des domaines. Meme si je n'en ferais pas un critere de selection important en entretien d'embauche, je jetterai le pave dans la mare quand meme pour voir comment reagit la personne (si elle comprend deja la notion de model/rendering, si elle sait pourquoi des gens preferent 2-4-8 espaces pour une tab selon le type de fichier et l'editeur, si elle est ouverte a la discussion ou si elle est bornee en disant "Chez Google ils font comme ca, c'est que c'est mieux" sans presenter d'esprit critique, ...)

Dans les faits il n'y a que emacs qui sache faire ça je crois. Du coup, ce n'est pas vraiment utilisable sur un projet où notepad++, emacs, eclipse, QtCreator sont chacun utilisés par une personne différente.

Tous les editeurs savent inserer une tab quand tu appuies sur tab, et un espace quand tu appuies sur espace... A un moment, c'est aussi au developpeur de se poser la bonne question sur 1. ce qu'il cherche a inserer et 2. ce que l'editeur insere effectivement.
Dans Eclipse IDE, je recommande a tous les utilisateurs avec lesquels j'ai l'occasion de passer du temps a code d'afficher les tabs/espaces avec des caracteres en gris clair ( http://help.eclipse.org/oxygen/topic...ditorprefs.htm > "Show whitespace characteres" ). Jusqu'ici j'ai pas eu de retour negatif sur cette pratique et j'ai eu quelques commentaires tres positifs du genre "ouah, c'est degueulasse! Je savais pas qu'on indentait si mal!"

[Luc Hermitte]

Si c'est à la main que l'on indente en appuyant explicitement sur la touche tab puis des espaces pour aligner les lignes suivantes, on a perdu, et il faut changer d'outil ou apprendre à se servir de celui que l'on utilise. C'est à l'éditeur de prendre en charge cela. Dit autrement, il ne faut pas à avoir à appuyer sur tab, mais juste sur: "aller à une nouvelle ligne" (a.k.a. <entrée>), ou "réindente la(/es) ligne(s) courante(s)" (utile en cas de refactoring/import de code). Si on appuie explicitement sur <tab>, cela veut dire que la tâche de mise en conformité avec le style retenu pour le projet n'est pas automatisable.

NB: je ne fais pas référence au cas trivial de

Code :

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

1
2
<destabs>auto i   = 42;
<destabs>auto str = "toto"s;

Mais à celui de

Code :

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

1
2
3
<destabs>auto r   = expression(complexe)
<destabs>         + une(autre(expression * complexe)) // ici je veux bien que l'on intervienne pour aligner le + sur le =, et encore l'éditeur doit proposer de lui-même un retrait par défaut à défaut d'être intelligent
<destabs>         - une(dernière);                    // ici, l'indentation doit être automatique!

La difficulté arrive quand en début de ligne on commence par des tabulations pour indenter une fois par niveau d'imbrication, et autant de fois que nécessaire pour aligner avec la ligne précédente. Tous les outils ne savent pas détecter une continuation de la précédente expression et permettre d’enchaîner tabs puis espaces dans ce cas là, sans parler des développeurs qui pourraient utiliser notepad qu'ils ne verraient pas de différence dans leur process d'indentation.

C'est pour cela que pour le coup je prêche pour le nivellement par le bas, et que l'indentation intelligemment mixée... je n'y crois pas sur des équipes mixtes en termes d'environnements de développement, et en termes de profils de développeurs.

NB: pour montrer qu'ils indentent comme des pieds (/avec des outils mal paramétrés), je les envoie sur le portail web du gestionnaire de version, souvent les mélanges d'indentation y sont criants. En général, c'est la conséquence de projet qui impose d'indenter avec des espaces, et d'outils qui n'ont pas été configurés.

En ce qui me concerne, dans tous les cas, l'indentation (avec ou sans alignement supplémentaire) doit être automatisée : si on passe un outil sur le code, c'est l'outil qui a raison. A nous de bien configurer l'outil.

[Mickael_Istria]

Si c'est à la main que l'on indente en appuyant explicitement sur la touche tab puis des espaces pour aligner les lignes suivantes, on a perdu, et il faut changer d'outil ou apprendre à se servir de celui que l'on utilise. C'est à l'éditeur de prendre en charge cela. Dit autrement, il ne faut pas à avoir à appuyer sur tab, mais juste sur: "aller à une nouvelle ligne" (a.k.a. <entrée>), ou "réindente la(/es) ligne(s) courante(s)" (utile en cas de refactoring/import de code).

La plupart des outils repetent tout simplement l'identation de la ligne precedente sur un retour a la ligne. C'est generalement une heuristique tres satisfaisante. Ensuite, les outils plus avances (Eclipse JDT par exemple) ont en place un formatter qui comprend mieux le langage. L'affichage des whitespaces n'est pas contradictoire avec le fait que l'outil fais le gros du boulot, ca permet surtout de se rendre compte de quand on fait quelque chose de mal et de le corriger immediatement.

le style retenu pour le projet n'est pas automatisable.

Je ne suis pas adepte de l'idee qu'un style doive etre automatisable. Il doit surtout etre desautomatisable des que necessaire, eg quand un developpeur humain pense qu'un autre developpeur humain preferera une ligne de 81 caracteres. La finalite c'est la lecture humaine, pas l'automatisation.

Pour montrer qu'ils indentent comme des pieds (/avec des outils mal paramétrés), je les envoie sur le portail web du gestionnaire de version, souvent les mélanges d'indentation y sont criants. En général, c'est la conséquence de projet qui impose d'indenter avec des espaces, et d'outils qui n'ont pas été configurés.

C'est donc une correction a posteriori. Afficher les whitespaces dans l'editeur permet de se rendre compte du probleme beaucoup plus tot, et evite des allers-retours. "fail fast"!