Discussion :

[Amine Horseman]

Que signifie le terme « meilleures pratiques » dans le développement logiciel ?
Un sénior déclare qu'il est dénué de sens et utilisé à tort

Un article publié par Erik Dietrich, blogueur et auteur de deux livres sur le développement, a fait le buzz récemment sur DeadTech. L’article concerne l’utilisation « abusive » du terme « meilleures pratiques » dans les articles et les tutoriels traitant du développement logiciel qu’on peut trouver sur internet.

Selon Erik Dietrich, l’expression « meilleures pratiques » est vague et subjective. En effet, il commence par donner la signification officielle du terme, qu’il décrit comme étant : « la pratique dont la preuve empirique démontre qu’elle est supérieure aux autres pratiques ». Il s’agit là de la définition « idéale » selon Dietrich. La deuxième signification, dite « réelle », la décrit comme étant « une convention sur la manière de faire quelque chose, souvent établie par des organismes de standardisation tels qu’ISO par exemple ».

La troisième définition, celle proposée par Dietrich, la décrit néanmoins comme étant un terme basique et dénué de sens très souvent utilisé par des personnes voulant faire croire que leurs actions sont plus importantes et raisonnables qu’elles ne le sont réellement, et ceci bien sûr sans preuve empirique ou scientifique pour justifier ce choix. En d’autres termes, cette dernière définition, dite « cynique », coïncide avec « l’utilisation la moins crédible » du terme.

« Je suis sûr que je ne suis pas le seul à avoir entendu les gens utiliser le terme "meilleures pratiques" pour justifier leurs actions quand il était clair que cette "pratique" n’a été ni empiriquement démontrée comme étant la meilleure ni approuvée par convention ou par un organisme de normalisation », déclare l’auteur de l’article. Selon lui, ceci peut aussi s’appliquer aux processus industriels. Il donne une liste d’exemples jugés comme étant de bonnes pratiques dans l’industrie des logiciels sans qu’il y ait pour autant de preuves universelles qui démontrent leur supériorité par rapport aux autres pratiques existantes. Parmi cette liste d’exemples, on peut citer :

• Le développement agile
• Le développement dirigé par les tests
• L’intégration continue
• Les design patterns
• Le code review
• Le pair programming

Erik Dietrich insiste sur le fait que ces exemples sont souvent controversés, mais le fait est que l'industrie en général a évolué dans une direction où ces techniques sont largement adoptées. « Il y a une fine ligne entre la sagesse conventionnelle et la fausse idée commune » déclare-t-il. « Comment peut-on savoir si ces pratiques sont vraiment de bonnes idées et, plus important encore, comment peut-on savoir si ces pratiques sont bonnes pour le développeur et pour son organisation ? ».

Source : DeadTech

Et vous ?

Que pensez-vous de l’avis d’Erik Dietrich ?

Les exemples qu’il cite sont-ils de bonnes pratiques ou de simples fausses idées communes ?

[Laurent 1973]

Je considère, pour ma part, que les 7 pratiques évoqués font partie sinon des "meilleures pratiques" de "bonnes pratiques" dans le développement logiciel.
Pour moi, les ayant pratiqués plusieurs fois dans divers projets, je considère que leur pratique empirique m'a démontré qu’elles donnent de meilleurs résultats que de ne pas les utiliser.

Là où je pense que la polémique est présent c'est que dans certain cas elle ne donne pas le résultat escompté par ce qu'on ne les met pas en place complètement: un peu d'agité, un peu de contrôle continue, un peu de TDD, pas trop de pair programming, ....
Ces pratiques nécessite pas mal de changement dans la façon de penser à la fois de la part des développeurs, que du management et parfois, le changement est difficile.
Il peut même s'opposer à des réticences ou des incompatibilité avec des intérêt personnels.

Après, que l'on appelle ça "meilleures pratiques", "bonnes pratiques", "pratiques à la modes" ou "les pratiques d'Erik Dietrich", j'avoue que je trouve ça inutile comme débat et sans grand intérêt.

[el_slapper]

pour le pair programming, il existe de la littérature qui mesure les couts, mais aussi les bénéfices.

[NSKis]

C'est vraiment le genre de polémique pour mettre un peu d'ambiance à l'heure de l'apéro!!!

Le plus important est de savoir que l'on peut établir toutes les "bonnes", "meilleures" et autres pratiques, la qualité du logiciel dépendra toujours en premier lieu de la qualité et de l'état d'esprit du développeur!!!

Je parle bien d'état d'esprit et pas de diplôme!!! Le développeur doit être réfléchi et METICULEUX, avoir l'esprit du détail...

J'ai ici une pensée émue pour les pseudo-développeurs que certainement tout le monde a eu à subir, de ceux qui, lorsqu'ils doivent corriger un bug, vous retournent un code avec 10 nouveaux bugs qui n'existaient pas avant leur intervention... Et ceux-là vous pouvez leur imposer toutes les bonnes pratiques du monde, ils vous fourniront toujours de la daube...

[DonQuiche]

pour le pair programming, il existe de la littérature qui mesure les couts, mais aussi les bénéfices.

J'adore : tu es la seule personne ici à fournir un lien vers une étude compilant diverses sources empiriques plutôt qu'une opinion et tu te manges un score de -1 !

L'important sur les réseaux sociaux, c'est de brosser dans le sens du poil. Prière de ne pas sortir du cadre.

[dfiad77pro]

Beaucoup de bonnes pratiques doivent prendre en compte le facteur humain ( ce qui ne ressort jamais dans les stats !).

- Le TDD : c'est sur si on laisse pas le temps au développeur de faire les choses, ça va échouer ! ( ou pire on choisit un dev qui ne sait et ne veut pas savoir ce que c'est qu'un test unitaire)
- Dans beaucoup d'équipes hétérogènes certaines personnes ne savent même pas ce que c'est , et il n'y a souvent pas d'architecte.
- Le développement par pair : si le binôme n'est pas bon ou ne s'entend pas c'est l'échec. Par contre si il s’entendent, ça peut donner de superbes résultats.
- L'agile est souvent du faux agile (XP avec 6 intermédiaires avant le métier, faut pas s'étonner que ça échoue )



Bref les managers ne pensent souvent qu'en terme de coût (je simplifie avec une pincée de mauvaise fois ) donc l’intérêt des méthodes reste très difficile à prouver lorsque la moitié des projets échouent(ou dépassent le budget) à cause d'une mauvaise gestion.

[bountykiler]

C'est quelque chose que l'on voit de plus en plus (il me semble), à savoir remettre en cause tout un ensemble de pratiques que beaucoup de personnes considèrent comme étant "meilleures". Et j'avoue que cette remise en question n'est pas une mauvaise chose en soi.
Je pense que c'est aussi une question de personnalité. Certains vont directement chercher à appliquer le dernier truc à la mode alors que d'autres (comme moi) vont prendre tout cela avec plus de recul. Puis c'est vrai qu'en fonction des personnes, du type de projet et probablement d'autres facteurs ces techniques se révèleront être plus ou moins efficace.

- Le TDD : c'est sur si on laisse pas le temps au développeur de faire les choses, ça va échouer ! ( ou pire on choisit un dev qui ne sait et ne veut pas savoir ce que c'est qu'un test unitaire)
- Dans beaucoup d'équipes hétérogènes certaines personnes ne savent même pas ce que c'est , et il n'y a souvent pas d'architecte.

Tiens, perso je suis assez anti-TDD. Pas pour les raisons que tu cites, mais parce que le fait de faire du TDD a tendance à avoir un impact sur le code que l'on va écrire, en ce sens que l'on voudra rendre celui-ci testable. Cela a comme conséquence de rendre le code plus complexe que nécessaire (souvent via l'ajout d'interfaces qui n'ont de sens que dans le contexte du TDD), le rendant du coup plus difficile à maintenir.

- Le développement par pair : si le binôme n'est pas bon ou ne s'entend pas c'est l'échec. Par contre si il s’entendent, ça peut donner de superbes résultats.

Bof. Pour ce que j'en ai pratiqué, cela ne c'est jamais avéré productif. Je sais que beaucoup de personnes ne seront pas d'accord avec moi, mais je vais toujours plus vite quand je travaille seul, sans avoir quelqu'un d'autre à qui je dois expliquer ce que je fais, pourquoi, comment je compte m'y prendre,... Par contre cela peut avoir de l'intéret quand in a une personne + expérimentée qui explique ce qu'elle fait à qqun d'autre.

- L'agile est souvent du faux agile (XP avec 6 intermédiaires avant le métier, faut pas s'étonner que ça échoue )

Ca sent le vécu .
Et là dessus je te dirai que je que assez d'accord avec toi. Bien souvent, les supérieurs hiérarchiques demandent que l'on travaille de manière agile parce que c'est + mieux, mais ne comprennent en rien ce que cela signifie et/ou implique.

Bref les managers ne pensent souvent qu'en terme de coût (je simplifie avec une pincée de mauvaise fois ) .

Elle est ou la mauvaise fois? C'est juste un fait. Les managers ne pensent qu'en terme de cout et de revenus sans rien comprendre au reste, ce qui abouti en effet souvent à une mauvaise gestion. (en tout cas, cela a été comme cela dans la grande majorité des boites pour lesquelles j'ai déjà travaillé.)

Sinon, pour continuer la liste:
- L’intégration continue
Quasi présent partout ou je suis passé, cela a touours apporté un plus et je n'ai pas d'exemple ou cela a été contre-productif.
- Les design patterns
Oui et non. Attention à bien les appliquer judicieusement, et ne pas chercher à mettre des design pattern pour mettre des design pattern. (j'ai déjà vu cela).
- Le code review
On en fait dans la boite ou je suis actuellement, et cela apporte un plus indéniable.
- Certains ont parlé des conventions d'écriture de code.
Sans vouloir entrer dans un débat sur ce sujet (ce serait bien trop long), il en est une qui est des plus basiques et qui est systématiquement non-respectée par nombre de programmeurs : faites des méthodes courtes!!! Trop souvent, je vois des méthodes qui font plus de 300 lignes de code, ont plusieurs niveaux d'imbrications (4 voir plus), ou contiennent une grande part de code dupliqué. C'est bien là quelque chose que je ne comprendrai jamais...

[dfiad77pro]

Bof. Pour ce que j'en ai pratiqué, cela ne c'est jamais avéré productif. Je sais que beaucoup de personnes ne seront pas d'accord avec moi, mais je vais toujours plus vite quand je travaille seul, sans avoir quelqu'un d'autre à qui je dois expliquer ce que je fais, pourquoi, comment je compte m'y prendre,... Par contre cela peut avoir de l'intéret quand in a une personne + expérimentée qui explique ce qu'elle fait à qqun d'autre.

Justement d'ou l'intérêt de bien s'entendre et de savoir répartir les tâches, ça dépends aussi du contexte ( nouveau projet, etc).
Moi aussi je travail plus vite seul si le domaine est trop ciblé

L'intérêt lorsque qu'une personne est plus expérimenté, c'est que cela fait de la formation et de la répartition de connaissance
*


pour les conventions d'écriture de code, je me méfie, beaucoup d'entreprises , par exemple basés sur un SI Oracle ( ou autres) prennent des conventions de nommage oracle pour le java ça donne des méthodes du genre :

Code :

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

1
2
3
4
5
6
7

public void PKG_XY_MAJ_TABLE_T(30 paramétres){

// Code d'accès à la procédure

}

et c'est pas une blague, je l'ai notamment vu dans une énorme structure sur l'ensemble des logiciels ...

[Laurent 1973]

Tiens, perso je suis assez anti-TDD. Pas pour les raisons que tu cites, mais parce que le fait de faire du TDD a tendance à avoir un impact sur le code que l'on va écrire, en ce sens que l'on voudra rendre celui-ci testable. Cela a comme conséquence de rendre le code plus complexe que nécessaire (souvent via l'ajout d'interfaces qui n'ont de sens que dans le contexte du TDD), le rendant du coup plus difficile à maintenir.

J'ai l'impression que tu confonds de notion.
Le TDD: Test Driven Developpement - dont l'idée première est d'écrire un test simple avant de développer.
Les Tests Unitaires en isolation: pratique qui veux tester chaque couche une par une en s'isolant de l'aval et l'amont via des versions Fakes les simulant.

Donc ce serait plus de l'anti-Tests Unitaires en isolation que tu serais au vu de ton explication.

Je voudrais te posé une question simple: Comment réalise tu des tests unitaires si tu n'as pas la possibilité d'isolé facilement chaque couche?
Tu n'en fais peut-être pas, et tu réalises seulement des tests integrations/fonctionnelles.
Tu dois avoir alors pas mal de la complication pour réaliser des tests métiers en te trainant des couches persistantes (fichiers, BD, ...) difficile et lourde à configurer.
Et dans ce cas là, quant un test échoue suite à des améliorations/corrections, il est beaucoup plus dure de déterminer quel couche a provoqué la régression.
Ne valider un logiciel que par des tests fonctionnelles peut conduire aussi à un manque de couverture de tests (surtout au limite) et donc d'augmenter les tickets de support.

En faite, ces "interfaces" qui apparaissent via les besoins du Test Unitaire, je les trouves au contraire utile pour une compréhension "black-box" de chaque couche.
En effet, si on documente l'API de ces interfaces (via du doxygene par exemple), lorsque on doit réaliser des modifications amonts ou avales à cette couche, on a pas à aller voir systématiquement le code de cette partie.
Et de plus chaque couche à un rôle bien défini qui donne une architecture plus propre (enfin c'est mon avis)

En plus, et cela m'est arrivé, si pour les besoins d'une évolution en maintenance, on a besoin de refaire entièrement une couche: l'isolation déjà intégrer dans cette architecture le rend plus facile combiner à des tests de comportement déjà prêt.

Bof. Pour ce que j'en ai pratiqué, cela ne c'est jamais avéré productif. Je sais que beaucoup de personnes ne seront pas d'accord avec moi, mais je vais toujours plus vite quand je travaille seul, sans avoir quelqu'un d'autre à qui je dois expliquer ce que je fais, pourquoi, comment je compte m'y prendre,... Par contre cela peut avoir de l'intéret quand in a une personne + expérimentée qui explique ce qu'elle fait à qqun d'autre.

Là c'est toute la notion de travail en équipe.
Depuis que je travail dans l'informatique, j'ai toujours été amené à partager mon code avec mon collègue.
De travailler sur du code sensible à deux (j'avoue que je ne pratique pas le pair programming systématiquement) permet déjà de partager les idées et les connaissances sur ce code.
Mais aussi, le co-pilote est là pour relire à mesure ce que le pilote tape: toutes les "bonnes" pratiques que l'équipe s'en engager à respecter sont plus assuré à deux que tout seul.

Ce n'est pas une pratique à réserver pour un couple novice+expert.
Deux experts au contraire ont de l’intérêt de travailler ainsi.
Déjà, le pilote n'a pas besoin d'expliqué ce qu'il fait, l'autre comprend en générale assez vite où le premier veux en venir.
Et puis justement, c'est l'occasion d'échanger de façon bref les idées (ex: "On met en place MVC, ok?" - "Tu pense pas que le pattern Observer n'est pas plus adéquat?")
Les experts vont échangé sur le fond des idées, afin justement de confronté leurs idées et de faire émerger le meilleur algorithme possible tout en respectant du premier coup des bonnes pratiques.

Mais sinon je te suis totalement sur ta remarque sur le manque d'implication de la hiérarchiques sur l'organisation concrète des équipes.
Et ils ne raisonnent qu'à cours terme, rarement sur du moyen et long terme.

+1 sur les longueurs de méthodes.
C'est aussi pour cela que j'utilise des outils d'analyses statiques de code (comme lint en c++)
Ces outils mettre en avant les méthodes, les classes, et les fichiers trop long.
Ils calculent souvent aussi la complexité cyclomatique (nombre chemin possible dans une fonction) limitant aussi les nombres d'imbrication de condition et boucle.

[bountykiler]

Je voudrais te posé une question simple: Comment réalise tu des tests unitaires si tu n'as pas la possibilité d'isolé facilement chaque couche?
Tu n'en fais peut-être pas, et tu réalises seulement des tests integrations/fonctionnelles.
Tu dois avoir alors pas mal de la complication pour réaliser des tests métiers en te trainant des couches persistantes (fichiers, BD, ...) difficile et lourde à configurer.
Et dans ce cas là, quant un test échoue suite à des améliorations/corrections, il est beaucoup plus dure de déterminer quel couche a provoqué la régression.
Ne valider un logiciel que par des tests fonctionnelles peut conduire aussi à un manque de couverture de tests (surtout au limite) et donc d'augmenter les tickets de support.

En faite, ces "interfaces" qui apparaissent via les besoins du Test Unitaire, je les trouves au contraire utile pour une compréhension "black-box" de chaque couche.
En effet, si on documente l'API de ces interfaces (via du doxygene par exemple), lorsque on doit réaliser des modifications amonts ou avales à cette couche, on a pas à aller voir systématiquement le code de cette partie.
Et de plus chaque couche à un rôle bien défini qui donne une architecture plus propre (enfin c'est mon avis)

J'ai l'impression que pour toi le fait de faire des tests unitaires et le fait de découper son applications en différentes couches sont liés. Sache qu'il n'en est rien! Ce n'est pas parce que je ne prends pas en compte la testabilité de mon application lors du dev que je ne la découpe pas en différentes couches. Au contraire, ce découpage est quelque chose d'essentiel si je veux etre en mesure de maintenir mon application efficacement, aussi je le fait non pas pour que mon application soit testable mais pour qu'elle soit maintenable (et aussi pour que certaines parties soient réutilisables ailleurs).
Après, pour ce qui est des couches persistantes comme tu les appelles, je ne les trouve pas lourde à configurer du tout. Ce qui me prends le plus de temps c'est plutot de faire en sorte que ma db ou mes fichiers contiennent bien les infos correspondant à mon cas de test, cela étant fortement lié à la complexité du test que je veux effectuer. Maintenant, il est vrai que lors de mes tests je m'autorise à accéder directement à des fichiers et/ou à une base de données, chose que des puristes ne tolèreraient pas.

Là c'est toute la notion de travail en équipe.
Depuis que je travail dans l'informatique, j'ai toujours été amené à partager mon code avec mon collègue.
De travailler sur du code sensible à deux (j'avoue que je ne pratique pas le pair programming systématiquement) permet déjà de partager les idées et les connaissances sur ce code.
Mais aussi, le co-pilote est là pour relire à mesure ce que le pilote tape: toutes les "bonnes" pratiques que l'équipe s'en engager à respecter sont plus assuré à deux que tout seul.

Ce n'est pas une pratique à réserver pour un couple novice+expert.
Deux experts au contraire ont de l’intérêt de travailler ainsi.
Déjà, le pilote n'a pas besoin d'expliqué ce qu'il fait, l'autre comprend en générale assez vite où le premier veux en venir.
Et puis justement, c'est l'occasion d'échanger de façon bref les idées (ex: "On met en place MVC, ok?" - "Tu pense pas que le pattern Observer n'est pas plus adéquat?")
Les experts vont échangé sur le fond des idées, afin justement de confronté leurs idées et de faire émerger le meilleur algorithme possible tout en respectant du premier coup des bonnes pratiques.

Déjà, pour moi ce n'est pas au moment de coder le projet que l'on doit se poser la question de savoir si on fait du MVC, du MVVM, si on mets des observers ou tout autre pattern en place. Pour moi c'est quelque chose qui doitavoir été réfléchi en amont (et effectivement à plusieurs c'est mieux). Après pour ce qui est du partage des connaissances et les échanges d'idées, je trouve que le code review est au moins aussi efficace à ce niveau, avec le défaut certes il est vrai qu'il faut parfois recommencer une partie du travail suite à une remarques d'un collègue. Par ailleurs je trouve cela un mal pour un bien en ce sens que personne n'aime faire 2 fois le même travail. Du coup, quand un collègue fait des remarques, on a plutot tendance à les prendre en compte et/ou à en débattre, histoire que cela ne se reproduise pas le coup d'après. En un sens, c'est quelque chose qui nous oblige à avancer et à apprendre de nos erreurs.

[RyzenOC]

Que signifie le terme « meilleures pratiques » dans le développement logiciel ?

Celle qui marche (qui ont fait leurs preuves), ainsi que le respect les conventions, par exemple pour les variables, ont ne les nommes pas n'importe comment, i et j son réservé dans les boucles, a b et c dans les calcules arithmétiques...

[Saverok]

Je suis en phase avec le post de Laurent 1973
Si on se mets à débattre sur tous les termes de sémentique marketing, on n'a pas fini et surtout, il ne nous resterai plus de temps pour développer et les mettre en pratique justement lol

[Laurent 1973]

.. comment, i et j son réservé dans les boucles, a b et c dans les calcules arithmétiques...

Je suis d'accord sur avoir des conventions de nommages, c'est une bonne pratique en effet.
Mais pour moi, je m'interdis les variables de moins de 3 caractères qui n'ont pas la signification de ce qu'elles contiennent.

Pour une boucle ce sera plutôt "truc_index" et "machin_index" que i et j (voir k, l, m, n ... on en finit plus).
Au moins, quand on reviens dans le code, on comprends plus facilement à quoi correspond chaque index de boucle.

Pour information: dans beaucoup de langages, la longueur maximum d'une variable et d'une fonction c'est 255 caractères, alors on peux être explicite et éviter les abréviations incompréhensibles.

Donc, désolé, mais utiliser i, j, a, b, c ... n'est pas pour moi une bonne pratique.
Comme quoi la notion de bonnes pratiques est subjective aussi.

Tiens, a ce propos, 2 "bonnes" pratiques que je rajoute souvent dans mes projets informatiques:
- aucun warning en compilation
- utilisation d'un outil d'analyse statique de code (comme lint en C++) avec zéro erreur à l’intégration continue

[tomlev]

• Le développement agile
• Le développement dirigé par les tests
• L’intégration continue
• Les design patterns
• Le code review
• Le pair programming

Dans le tas j'en vois quand même plusieurs qui contribuent indubitablement à la qualité du code :

• design patterns : ce n'est pas pour rien qu'on appelle ça des patterns, ce sont des solutions éprouvées pour résoudre certaines classes de problèmes. A condition de les utiliser avec discernement, ça ne peut être que bénéfique.
• code review : dans ma boite, on est longtemps passé à côté ; maintenant qu'on le fait régulièrement, 95% des code reviews permettent d'identifier en amont des problèmes qui se seraient peut-être révélés beaucoup plus tard autrement.
• intégration continue : c'est clairement un des meilleurs moyens de s'assurer qu'on ne commite pas n'importe quoi...

Pour le reste, c'est plus des questions d'opinion. Par exemple la méthode Agile a ses avantages, mais ce n'est sans doute pas une "bonne pratique" dans le sens où il faut obligatoirement le faire.

[RyzenOC]

Pour une boucle ce sera plutôt "truc_index" et "machin_index" que i et j (voir k, l, m, n ... on en finit plus).
Au moins, quand on reviens dans le code, on comprends plus facilement à quoi correspond chaque index de boucle.

Sa dépend du langage je dirais, prend le c:

Code :

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

1
2
3
4
for (i=1; i<6; i++) {
 printf("%d", i);

}

Je n'ai jamais vu de

Code :

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

1
2
3
4
for (nombredepointeurdansmonobjetdemonprogrammesouslinux=1; nombredepointeurdansmonobjetdemonprogrammesouslinux<nombredepointeurquejedoismettrepourquesamarche; nombredepointeurdansmonobjetdemonprogrammesouslinux++) {
 printf("%d", nombredepointeurdansmonobjetdemonprogrammesouslinux);

}

C'est beau 255 caractère dans une variable , je reconnais je suis de mauvaise foi.
Dans mon premier exemple, tu peut remplacer 6 par un nom explicite, mais je vois l’intérêt de remplacer i par autre chose ?

[Laurent 1973]

Sa dépend du langage je dirais, prend le c:

Code :

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

1
2
3
4
for (i=1; i<6; i++) {
 printf("%d", i);

}

C'est très jolie ta petite boucle.
Mais à quoi correspond chaque itération de celle ci? un temps? la tentative d'une action qui peux échoué? une parcours dans une liste?
De plus "6", numéro magique qui tombe comme un cheveux dans la soupe: privilégier l'utilisation d'une constante explicitant le sens de ce "6"

Sinon, je trouve que "index_du_pointeurs_dans_mon_objet_de_mon_programme_sous_linux" et "nombre_de_pointeurs_que_je_dois_mettre_pour_que_ca_marche" sont plus lisible que "nombredepointeurdansmonobjetdemonprogrammesouslinux" et "nombredepointeurquejedoismettrepourquesamarche" mais chacun ses goûts .
Et en tout cas bien plus que ton nombre "6"

Et c'est pas parce que l'on utilise i, j, k dans les boucles depuis 40 ans (à une époque où les variables étaient limité à 8 caractères) que c'est une bonne chose.

Bon, je suis aussi un peu de mauvaise foi au sens que je n'utilise jamais 255 caractères pour nommer une variables.
Mais entre 10 et 30 c'est assez classique et cela m'évite de rajouter un commentaire pour expliquer son rôle.

[RyzenOC]

Et en tout cas bien plus que ton nombre "6"

J'ai préciser que le nombre 6 doit être une variable explicite.

Moi j'ai toujours utiliser des i,j dans mes boucle for/while, j'ai toujours trouvé cela clair, j'ai des mauvaises pratique

[sdevilcry]

Sa dépend du langage je dirais, prend le c:

Code :

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

1
2
3
4
for (i=1; i<6; i++) {
 printf("%d", i);

}

C'est beau 255 caractère dans une variable , je reconnais je suis de mauvaise foi.
Dans mon premier exemple, tu peut remplacer 6 par un nom explicite, mais je vois l’intérêt de remplacer i par autre chose ?

Beaucoup de mauvaise foi en effet
Crois moi ton "i" tu peux l'appeler simplement currentQuelQuelChoseExplicit ce que je fais tout le temps et c'est plus agréable à la lecture.

Typiquement et un exemple parmi tant d'autre et peu importe le langage :
Avec des objects :
myObjectsList = [0 => object1, 1 => object2, ...]; foreach (myObjectsList as currentObject => object)
Ou des tableaux :
myArraysList = [0 => array1, 1 => array2, ...]; foreach (myArraysList as currentArray => arrayInfo)
(Vous pouvez remplacer le foreach par un for hein c'est juste pour faire un exemple ou le besoin d'utiliser l'index est présent).

Et la quand je lis le code je sais ce que ça fait etc etc. Après c'est peu être subjectif ?

[RyzenOC]

(Vous pouvez remplacer le foreach par un for hein c'est juste pour faire un exemple ou le besoin d'utiliser l'index est présent).

Je suis clairement pas d'accord, un foreach n'a rien na voir avec un for, quand je fais un foreach je ne mets jamais de i ou de j, je mets des variables explicites.

Je mets des i et des j uniquement dans des "for" et des "while"

[redbullch]

Donc, désolé, mais utiliser i, j, a, b, c ... n'est pas pour moi une bonne pratique.

C'est aux mathématiciens qu'il faut expliquer ça