[Débat] convention de nommage

Je suis d'accord avec le début de ton post, mais:

1. Bien que j'aie pris le réflexe de comparer explicitement pointeurs et entiers, je ne compare pas un booléen à true ou false, puisque le booléen représente déjà une condition.
2. Franchement, les préfixes, ça aide. Autant pour m_ on peut à la rigueur s'en passer, autant pour les variables statiques et globales on a besoin de tous les rappels qu'on peut avoir.

Certes, on peut reformater, et c'est ce que je fais régulièrement. Mais je ne dis pas le bronx quand il s'agit de fusionner des codes via git -- quand il n'a a donc pas de commit-hook qui reformate à la volée.

Pour les "m_", ma foi je m'en sers, et j'avoue que c'est bien pratique quand on reprend des codes qui sont tout sauf courts. Cela permet de voir d'où vient une variable sans pourrir le code avec des this-> qui ne sont pas mieux. Rarement, cela permet aussi de réaliser des micro-optimisations à moindre coût : on calcule un résultat via une boucle qui stocke les valeurs intermédiaires dans une variable locale, et on "sauve/commite" à la fin dans une variable membre éponyme, au détail du "m_" en plus.

Pour les espaces/tabs, au pire on peut demander à l'IDE de transformer les tabs en espaces. La plupart des IDE le font maintenant.

Concernant les préfixes, je suis très étonné par vos remarques. Mais elles sont sensées. Comme quoi, il faut toujours se remettre en question. :)

Note: c'est moi que je remet en question hein, pas vous :)

Citation:

---

Envoyé par r0d

Pour les espaces/tabs, au pire on peut demander à l'IDE de transformer les tabs en espaces. La plupart des IDE le font maintenant.

---

Sauf que souvent, ça fait de la merde. Globalement, il faut distinguer ce que j’appelle l’indentation sémantique (je commence un nouveau bloc, j’indente) et l’indentation esthétique (je fais commencer mes paramètres sur une nouvelle ligne et sur la même colonne).

L’indentation sémantique se gère très bien avec des tabulations. L’indentation esthétique se gère uniquement avec des espaces, et mélanger les deux donne généralement un résultat catastrophique dès qu’on change la taille des tabulations --> obligé de gérer l’indentation sémantique avec des espaces…

C’est d’autant plus con que globalement, l’indentation « esthétique » devrait être uniquement de l’affichage au niveau de l’IDE, pas exister réellement dans le fichier. Quant à l’indentation sémantique, je suis de ceux qui seraient partisan d’une erreur de compilation (comme en python) si elle n’est pas bonne :).

Citation:

---

Envoyé par r0d

Pour les espaces/tabs, au pire on peut demander à l'IDE de transformer les tabs en espaces. La plupart des IDE le font maintenant.

---

Sauf qu'à plusieurs sur un projet, avec plusieurs centaines/milliers de fichiers et d'autant plus de lignes...
Si tu t'amuses à réindenter, tu vas surtout pourrir ton commit :aie:

Citation:

---

Envoyé par white_tentacle

Sauf que souvent, ça fait de la merde. Globalement, il faut distinguer ce que j’appelle l’indentation sémantique (je commence un nouveau bloc, j’indente) et l’indentation esthétique (je fais commencer mes paramètres sur une nouvelle ligne et sur la même colonne).

L’indentation sémantique se gère très bien avec des tabulations. L’indentation esthétique se gère uniquement avec des espaces, et mélanger les deux donne généralement un résultat catastrophique dès qu’on change la taille des tabulations --> obligé de gérer l’indentation sémantique avec des espaces…

C’est d’autant plus con que globalement, l’indentation « esthétique » devrait être uniquement de l’affichage au niveau de l’IDE, pas exister réellement dans le fichier. Quant à l’indentation sémantique, je suis de ceux qui seraient partisan d’une erreur de compilation (comme en python) si elle n’est pas bonne :).

---

Tout-à-fait d'accord, j'ai pris les mêmes réflexes de séparation entre les deux types.

Même si je ne fais jamais ceci:

Code:

---

1 2	void foofoofoo(int bar, int baz);

---

Quand je trouve que ceci est plus simple et tout aussi lisible:

Code:

---

1 2 3

void foofoofoo( int bar, int baz);

---

(dépendant du langage ou du beautificateur intégré à l'IDE, j'utilise une tab ou un espace simple)

Mouais. Je sais pas. Je n'ai jamais rencontré de problème d'indentation. Mais j'avoue que sur la majorité des projets sur lesquels j'ai travaillé, tout les développeurs utilisaient le même IDE. Et même lorsque ce n'était pas le cas, c'étaient des IDE suffisamment bien faits pour qu'il n'y ait pas ce problème (en général code::blocks && msvc).

Quant à la question de l'indentation "esthétique", je découvre encore quelque chose. Vous écrivez donc:

Code:

---

1 2 3

void foofoofoo( int bar, int baz);

---

Pourquoi ne pas écrire:

Code:

---

void foofoofoo(int bar, int baz);

---

J'ai l'impression qu'il y a encore quelque chose qui m'échappe.
Le problème c'est lorsqu'il y a trop de paramètres?
Si c'est le cas, je considère que c'est une erreur de conception, pas une erreur d'indentation. Il faut dire que j'ai été élevé avec la MFC, et que depuis que j'en suis sorti, je ne supporte plus les fonctions avec trop de paramètres. Au pire je passe par une structure conteneur.

Pour être précis, généralement, dans mes projet personnels en C ou C++ j'écris ça:

Code:

---

1 2 3 4

void foofoofoo( int bar, //[in] Description de ce que fait le paramètre int baz //[in] Description de ce que fait le paramètre ); //Description courte de valeur de retour, s'il y en a une

---

Bien sûr, cela ne s'applique pas aux langages où j'utilise un générateur de doc.

Citation:

---

Envoyé par Médinoc

Pour être précis, généralement, dans mes projet personnels en C ou C++ j'écris ça:

Code:

---

1 2 3 4

void foofoofoo( int bar, //[in] Description de ce que fait le paramètre int baz //[in] Description de ce que fait le paramètre ); //Description courte de valeur de retour, s'il y en a une

---

Bien sûr, cela ne s'applique pas aux langages où j'utilise un générateur de doc.

---

Tu n'utilises pas Doxygen ?

Citation:

---

Envoyé par r0d

Quant à la question de l'indentation "esthétique", je découvre encore quelque chose. Vous écrivez donc:

Code:

---

1 2 3

void foofoofoo( int bar, int baz);

---

Pourquoi ne pas écrire:

Code:

---

void foofoofoo(int bar, int baz);

---

J'ai l'impression qu'il y a encore quelque chose qui m'échappe.
Le problème c'est lorsqu'il y a trop de paramètres?

---

Le problème, c'est aussi (et surtout) si les paramètres sont des types assez longs, dans des namespaces, parfois des instanciations particulière d'une classe template.

Certains trouveront parfois cela beaucoup trop verbeux, mais il n'est pas rare que dans mon code le nom complet d'un type dépasse les 30 caractères...

Citation:

---

Envoyé par Médinoc

Code:

---

1 2 3 4

void foofoofoo( int bar, //[in] Description de ce que fait le paramètre int baz //[in] Description de ce que fait le paramètre ); //Description courte de valeur de retour, s'il y en a une

---

---

Moi j'ai arrêté d'appliquer une méthode systématique pour les commentaires. Désormais, je ne commente que ce qui n'est pas clairement explicité sans ambigüité par les noms de variables et de fonctions. Car le problème des commentaires, c'est un peu comme la duplication de code: ça implique des modifications supplémentaires à chaque modification. Je préfère donc éviter tant que faire se peut.

Citation:

---

Envoyé par white_tentacle

Le problème, c'est aussi (et surtout) si les paramètres sont des types assez longs, dans des namespaces, parfois des instanciations particulière d'une classe template.

Certains trouveront parfois cela beaucoup trop verbeux, mais il n'est pas rare que dans mon code le nom complet d'un type dépasse les 30 caractères...

---

Personnellement, dans ce cas j'utilise des typedef. Cela permet de limiter la verbosité, mais surtout, ça permet d'enrichir la sémantique.

Comme quoi, tous les chemins mènent à Rome ;)