J'écris systématiquement l'accolade ouvrante et l'accolade fermante
sur une même colonne :
if (condition)
{
action;
}
Cette convention d'écriture me permet de voir immédiatement la
structure en blocs, d'autant que la plupart des éditeurs ont une
couleur spéciale pour les accolades.
Aussi ai-je énormément de mal à lire du code écrit avec l'autre type
de convention :
if (condition) {
action;
}
J'aimerais savoir si les gens qui ont l'habitude des deux conventions,
arrivent à lire aussi facilement la deuxième que la première. Et,
accessoirement, s'il existe des éditeurs capables de mettre les deux
éléments de même "niveau" (i.e. "if (condition) {" et "}") de la même
couleur.
On Fri, 11 Jun 2004 00:37:17 -0400, "Michel Michaud" wrote:
Entre autres, tu verras que les instructions ne sont pas toujours au même endroit, si tu ne mets pas de bloc lorsqu'il n'y a qu'une instruction.
Je me suis très vite aperçu que ne pas mettre d'accolades quand un bloc ne contient qu'une seule instruction, était rarement une bonne idée.
-- ;-) FLL, Epagneul Breton
Pierre Maurette
Loïc Joly typa: [...]
Il y a un "effet secondaire" à cette variabilité de l'indentation, qui me sert bien souvent : lorsque que je reprends le programme d'un autre, en général, je commence par le réindenter "à ma sauce", à la main... Ça me permet de survoler le code en repérant les tests et autres boucles, de cerner sa structure, tout en le rendant plus lisible pour moi car, oui, la force de l'habitude est importante à ce niveau-là !
Et si tu faisait ça chez moi, je t'en voudrais.
Déjà il y a le problèmes des règles de codage qui ne seraient alors plus respectées, mais en plus et surtout, il y a le fait que toutes ces modifications qui ne servent à rien cacheraient celles qui servent à quelquechose, par exemple quand on fait un diff entre deux version du fichier, rendant le code bien moins maintenable. Effectivement, ça vous met en l'air un beau gestionnaire
historique/différences. Il y a une solution : un reformatage automatique paramétrable puissant. Il suffit de toujours reformater (dans le format commun s'il y a lieu) avant sauvegarde, ainsi que le tampon avant comparaison. Chaque développeur peut travailler avec ses préférences. Mon IDE fait très bien tout ça. Ce qu'il ne fait pas mais qui serait facile à ajouter, c'est la fonction "différences intelligentes" (il suffirait de chercher les différences à partir de copies temporaires reformatées). -- Pierre
Il y a un "effet secondaire" à cette variabilité de l'indentation, qui me
sert bien souvent : lorsque que je reprends le programme d'un autre, en
général, je commence par le réindenter "à ma sauce", à la main... Ça me
permet de survoler le code en repérant les tests et autres boucles, de
cerner sa structure, tout en le rendant plus lisible pour moi car, oui, la
force de l'habitude est importante à ce niveau-là !
Et si tu faisait ça chez moi, je t'en voudrais.
Déjà il y a le problèmes des règles de codage qui ne seraient alors plus
respectées, mais en plus et surtout, il y a le fait que toutes ces
modifications qui ne servent à rien cacheraient celles qui servent à
quelquechose, par exemple quand on fait un diff entre deux version du
fichier, rendant le code bien moins maintenable.
Effectivement, ça vous met en l'air un beau gestionnaire
historique/différences. Il y a une solution : un reformatage
automatique paramétrable puissant. Il suffit de toujours reformater
(dans le format commun s'il y a lieu) avant sauvegarde, ainsi que le
tampon avant comparaison. Chaque développeur peut travailler avec ses
préférences. Mon IDE fait très bien tout ça. Ce qu'il ne fait pas mais
qui serait facile à ajouter, c'est la fonction "différences
intelligentes" (il suffirait de chercher les différences à partir de
copies temporaires reformatées).
--
Pierre
Il y a un "effet secondaire" à cette variabilité de l'indentation, qui me sert bien souvent : lorsque que je reprends le programme d'un autre, en général, je commence par le réindenter "à ma sauce", à la main... Ça me permet de survoler le code en repérant les tests et autres boucles, de cerner sa structure, tout en le rendant plus lisible pour moi car, oui, la force de l'habitude est importante à ce niveau-là !
Et si tu faisait ça chez moi, je t'en voudrais.
Déjà il y a le problèmes des règles de codage qui ne seraient alors plus respectées, mais en plus et surtout, il y a le fait que toutes ces modifications qui ne servent à rien cacheraient celles qui servent à quelquechose, par exemple quand on fait un diff entre deux version du fichier, rendant le code bien moins maintenable. Effectivement, ça vous met en l'air un beau gestionnaire
historique/différences. Il y a une solution : un reformatage automatique paramétrable puissant. Il suffit de toujours reformater (dans le format commun s'il y a lieu) avant sauvegarde, ainsi que le tampon avant comparaison. Chaque développeur peut travailler avec ses préférences. Mon IDE fait très bien tout ça. Ce qu'il ne fait pas mais qui serait facile à ajouter, c'est la fonction "différences intelligentes" (il suffirait de chercher les différences à partir de copies temporaires reformatées). -- Pierre
drkm
"Michel Michaud" writes:
Dans news:, Fabien LE
On Wed, 09 Jun 2004 19:50:54 +0200, drkm wrote:
Je suppose qu'il s'agit d'une histoire de compacité du code. Ma console est en 35x80
Je n'ai que 27 lignes "utiles" pour le code, mais comme généralement, je lis le code à la roulette (de la souris), ça ne me dérange pas trop qu'un bloc soit très long :-)
Un bloc de 27 lignes EST TROP LONG (sauf dans des cas très précis, comme un long switch ou une série de if équivalente).
Un bloc de définition de fonction ?
--drkm
"Michel Michaud" <mm@gdzid.com> writes:
Dans news:ouihc0h7vsnlps6gkn28trmf5dtdg56jge@4ax.com, Fabien LE
On Wed, 09 Jun 2004 19:50:54 +0200, drkm
<usenet.fclcxx@fgeorges.org> wrote:
Je suppose qu'il s'agit d'une histoire de compacité du code.
Ma console est en 35x80
Je n'ai que 27 lignes "utiles" pour le code, mais comme
généralement, je lis le code à la roulette (de la souris), ça
ne me dérange pas trop qu'un bloc soit très long :-)
Un bloc de 27 lignes EST TROP LONG (sauf dans des cas très
précis, comme un long switch ou une série de if équivalente).
Je suppose qu'il s'agit d'une histoire de compacité du code. Ma console est en 35x80
Je n'ai que 27 lignes "utiles" pour le code, mais comme généralement, je lis le code à la roulette (de la souris), ça ne me dérange pas trop qu'un bloc soit très long :-)
Un bloc de 27 lignes EST TROP LONG (sauf dans des cas très précis, comme un long switch ou une série de if équivalente).
Un bloc de définition de fonction ?
--drkm
drkm
Fabien LE LEZ writes:
On Thu, 10 Jun 2004 21:59:36 +0200, "Yalbrieux" wrote:
J'utilise donc if( ...) { .... }
Question subsidiaire : comment se présente ce genre d'écriture quand la condition ne tient pas sur une ligne ?
Mal, je trouve. C'est le seul point négatif que je rencontre de temps en temps. Il m'arrive de temps en temps de passer l'accolade ouvrante sur la ligne suivante. Un manque de cohérence, peut-être, pour certains cas où cela rend le code plus lisible (bien que le manque de cohérence lui-même obfusque peut-être le code ...).
--drkm
Fabien LE LEZ <gramster@gramster.com> writes:
On Thu, 10 Jun 2004 21:59:36 +0200, "Yalbrieux" <yalbrieux@wanadoo.fr>
wrote:
J'utilise donc
if( ...) {
....
}
Question subsidiaire : comment se présente ce genre d'écriture quand
la condition ne tient pas sur une ligne ?
Mal, je trouve. C'est le seul point négatif que je rencontre de
temps en temps. Il m'arrive de temps en temps de passer l'accolade
ouvrante sur la ligne suivante. Un manque de cohérence, peut-être,
pour certains cas où cela rend le code plus lisible (bien que le
manque de cohérence lui-même obfusque peut-être le code ...).
On Thu, 10 Jun 2004 21:59:36 +0200, "Yalbrieux" wrote:
J'utilise donc if( ...) { .... }
Question subsidiaire : comment se présente ce genre d'écriture quand la condition ne tient pas sur une ligne ?
Mal, je trouve. C'est le seul point négatif que je rencontre de temps en temps. Il m'arrive de temps en temps de passer l'accolade ouvrante sur la ligne suivante. Un manque de cohérence, peut-être, pour certains cas où cela rend le code plus lisible (bien que le manque de cohérence lui-même obfusque peut-être le code ...).
--drkm
PurL
Je me suis très vite aperçu que ne pas mettre d'accolades quand un bloc ne contient qu'une seule instruction, était rarement une bonne idée.
Niveau lisibilité ? ou à d'autres niveaux ?
PurL
Je me suis très vite aperçu que ne pas mettre d'accolades quand un
bloc ne contient qu'une seule instruction, était rarement une bonne
idée.
Je me suis très vite aperçu que ne pas mettre d'accolades quand un bloc ne contient qu'une seule instruction, était rarement une bonne idée.
Niveau lisibilité ? ou à d'autres niveaux ?
PurL
PurL
if (condition) { action; }
if (condition) { action; }
Moi je considère que les accolades font parti du if comme si l'accolade ouvrante indiquait le "begin du if" (et non pas du bloc) et l'accolade fermante le "end du if" :
if (condition) { action; }
Apparement, personne ne fait comme cela mais je trouve qu'on repere plus vite le code du if en défilant rapidement le code. C'est comme les fonctions, je fais :
void mafonc() { code; }
si je suis votre logique, pour une fonction vous faites ceci :
void mafonc() { code; }
autant pour le if je pourrais m'y faire, mais pour une fonction je ne trouve pas ca jolie...
PurL
if (condition)
{
action;
}
if (condition) {
action;
}
Moi je considère que les accolades font parti du if comme si l'accolade
ouvrante indiquait le "begin du if" (et non pas du bloc) et l'accolade
fermante le "end du if" :
if (condition)
{
action;
}
Apparement, personne ne fait comme cela mais je trouve qu'on repere plus
vite le code du if en défilant rapidement le code.
C'est comme les fonctions, je fais :
void mafonc()
{
code;
}
si je suis votre logique, pour une fonction vous faites ceci :
void mafonc()
{
code;
}
autant pour le if je pourrais m'y faire, mais pour une fonction je ne trouve
pas ca jolie...
Moi je considère que les accolades font parti du if comme si l'accolade ouvrante indiquait le "begin du if" (et non pas du bloc) et l'accolade fermante le "end du if" :
if (condition) { action; }
Apparement, personne ne fait comme cela mais je trouve qu'on repere plus vite le code du if en défilant rapidement le code. C'est comme les fonctions, je fais :
void mafonc() { code; }
si je suis votre logique, pour une fonction vous faites ceci :
void mafonc() { code; }
autant pour le if je pourrais m'y faire, mais pour une fonction je ne trouve pas ca jolie...
PurL
Richard Delorme
On Thu, 10 Jun 2004 21:59:36 +0200, "Yalbrieux" wrote:
J'utilise donc if( ...) { .... }
Question subsidiaire : comment se présente ce genre d'écriture quand la condition ne tient pas sur une ligne ?
Normalement comme cela :
if (unePremiereTropLongueCondition || uneDeuxiemeTropLongueCondition || uneTroisiemeTropLongueCondition) { expression1; expression2; }
Où est le problème ?
-- Richard
On Thu, 10 Jun 2004 21:59:36 +0200, "Yalbrieux" <yalbrieux@wanadoo.fr>
wrote:
J'utilise donc
if( ...) {
....
}
Question subsidiaire : comment se présente ce genre d'écriture quand
la condition ne tient pas sur une ligne ?
Normalement comme cela :
if (unePremiereTropLongueCondition
|| uneDeuxiemeTropLongueCondition
|| uneTroisiemeTropLongueCondition) {
expression1;
expression2;
}
Je me suis très vite aperçu que ne pas mettre d'accolades quand un bloc ne contient qu'une seule instruction, était rarement une bonne idée.
Niveau lisibilité ?
Lisibilité (et consistance, qui va avec) et extensibilité.
-- ;-) FLL, Epagneul Breton
Jean-Marc Bourguet
Fabien LE LEZ writes:
On Thu, 10 Jun 2004 21:59:36 +0200, "Yalbrieux" wrote:
J'utilise donc if( ...) { .... }
Question subsidiaire : comment se présente ce genre d'écriture quand la condition ne tient pas sur une ligne ?
J'ai tendance (*) a passer de
if (...) { }
a
if (...) { }
a
if (cond1 && cond2 && (cond3 || cond4)) {
* Pour les projets ou les conventions de codage demandent la premiere forme mais ne specifient pas ce qu'il faut faire quand les lignes sont trop grandes.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Fabien LE LEZ <gramster@gramster.com> writes:
On Thu, 10 Jun 2004 21:59:36 +0200, "Yalbrieux" <yalbrieux@wanadoo.fr>
wrote:
J'utilise donc
if( ...) {
....
}
Question subsidiaire : comment se présente ce genre d'écriture quand
la condition ne tient pas sur une ligne ?
J'ai tendance (*) a passer de
if (...) {
}
a
if (...)
{
}
a
if (cond1
&& cond2
&& (cond3
|| cond4))
{
* Pour les projets ou les conventions de codage demandent la premiere
forme mais ne specifient pas ce qu'il faut faire quand les lignes sont
trop grandes.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
On Thu, 10 Jun 2004 21:59:36 +0200, "Yalbrieux" wrote:
J'utilise donc if( ...) { .... }
Question subsidiaire : comment se présente ce genre d'écriture quand la condition ne tient pas sur une ligne ?
J'ai tendance (*) a passer de
if (...) { }
a
if (...) { }
a
if (cond1 && cond2 && (cond3 || cond4)) {
* Pour les projets ou les conventions de codage demandent la premiere forme mais ne specifient pas ce qu'il faut faire quand les lignes sont trop grandes.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Fabien LE LEZ
On Fri, 11 Jun 2004 09:26:56 +0200, "PurL" wrote:
if (condition) { action; }
Apparement, personne ne fait comme cela
D'après la doc de "Artistic Style", ta méthode est nommée "ansi", tandis que la mienne est nommée "gnu". Donc les deux sont raisonnablement communes.
si je suis votre logique, pour une fonction vous faites ceci :
void mafonc() { code; }
Je devrais faire :
void mafonc() { code; }
Mais je ne le fais pas -- sans vraiment savoir pourquoi, et en ayant conscience que c'est inconsistant.
Je crois que je mettrai un peu d'ordre dans mes conventions personnelles... quand je serai au pied du mur ;-)
-- ;-) FLL, Epagneul Breton
On Fri, 11 Jun 2004 09:26:56 +0200, "PurL" <purl-nospam@chez.com>
wrote:
if (condition)
{
action;
}
Apparement, personne ne fait comme cela
D'après la doc de "Artistic Style", ta méthode est nommée "ansi",
tandis que la mienne est nommée "gnu". Donc les deux sont
raisonnablement communes.
si je suis votre logique, pour une fonction vous faites ceci :
void mafonc()
{
code;
}
Je devrais faire :
void mafonc()
{
code;
}
Mais je ne le fais pas -- sans vraiment savoir pourquoi, et en ayant
conscience que c'est inconsistant.
Je crois que je mettrai un peu d'ordre dans mes conventions
personnelles... quand je serai au pied du mur ;-)
