Discussion :

[Médinoc]

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.

[Luc Hermitte]

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.

[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.

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

[white_tentacle]

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 .

[Bousk]

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

[Médinoc]

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 C++ :

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

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

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

Code C++ :

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

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)

[r0d]

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 :

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

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

Pourquoi ne pas écrire:

Code :

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

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.

[Médinoc]

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

Code C++ :

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

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.

[dragonjoker59]

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

Code C++ :

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

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 ?

[white_tentacle]

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

Code :

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

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

Pourquoi ne pas écrire:

Code :

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

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...

[r0d]

Code C++ :

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

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.

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