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.
"Michel Michaud" a écrit dans le message de news:_b0yc.43639$
Dans news:, Fabien LE
J'aimerais savoir si les gens qui ont l'habitude des deux conventions, arrivent à lire aussi facilement la deuxième que la première.
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.
-- Loïc
Jean-Noël Mégoz wrote:
"Michel Michaud" <mm@gdzid.com> a écrit dans le message de
news:_b0yc.43639$sS2.1555218@news20.bellglobal.com...
Dans news:v5eec0ddtobbguos0vp0b972diupp2gs66@4ax.com, Fabien LE
J'aimerais savoir si les gens qui ont l'habitude des deux
conventions, arrivent à lire aussi facilement la deuxième que
la première.
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.
"Michel Michaud" a écrit dans le message de news:_b0yc.43639$
Dans news:, Fabien LE
J'aimerais savoir si les gens qui ont l'habitude des deux conventions, arrivent à lire aussi facilement la deuxième que la première.
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.
-- Loïc
Jean-Noël Mégoz
"Loïc Joly" a écrit dans le message de news:caaikg$ggs$
Jean-Noël Mégoz wrote:
"Michel Michaud" a écrit dans le message de news:_b0yc.43639$
Dans news:, Fabien LE
Et si tu faisait ça chez moi, je t'en voudrais.
Je ne parle pas d'intégrer un projet en cours pour en gérer une partie :
dans ces cas-là, il faut se plier aux règles du groupe. Quand je dis "reprendre un programme", c'est réellement hériter de la totalité d'un projet. D'autant que bien souvent, la mise en forme du prédécesseur est tout simplement abominable ! Cela dit, je n'ai jamais bossé dans un boîte où les règles d'indentation ou de nomenclature pour les noms de variables (sujet déjà évoqué sur de longs threads) aient été vraiment imposés. Ce qui est un tort, je l'admet.
"Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message de
news:caaikg$ggs$1@news-reader1.wanadoo.fr...
Jean-Noël Mégoz wrote:
"Michel Michaud" <mm@gdzid.com> a écrit dans le message de
news:_b0yc.43639$sS2.1555218@news20.bellglobal.com...
Dans news:v5eec0ddtobbguos0vp0b972diupp2gs66@4ax.com, Fabien LE
Et si tu faisait ça chez moi, je t'en voudrais.
Je ne parle pas d'intégrer un projet en cours pour en gérer une partie :
dans ces cas-là, il faut se plier aux règles du groupe.
Quand je dis "reprendre un programme", c'est réellement hériter de la
totalité d'un projet. D'autant que bien souvent, la mise en forme du
prédécesseur est tout simplement abominable !
Cela dit, je n'ai jamais bossé dans un boîte où les règles d'indentation ou
de nomenclature pour les noms de variables (sujet déjà évoqué sur de longs
threads) aient été vraiment imposés. Ce qui est un tort, je l'admet.
"Loïc Joly" a écrit dans le message de news:caaikg$ggs$
Jean-Noël Mégoz wrote:
"Michel Michaud" a écrit dans le message de news:_b0yc.43639$
Dans news:, Fabien LE
Et si tu faisait ça chez moi, je t'en voudrais.
Je ne parle pas d'intégrer un projet en cours pour en gérer une partie :
dans ces cas-là, il faut se plier aux règles du groupe. Quand je dis "reprendre un programme", c'est réellement hériter de la totalité d'un projet. D'autant que bien souvent, la mise en forme du prédécesseur est tout simplement abominable ! Cela dit, je n'ai jamais bossé dans un boîte où les règles d'indentation ou de nomenclature pour les noms de variables (sujet déjà évoqué sur de longs threads) aient été vraiment imposés. Ce qui est un tort, je l'admet.
Gabriel Dos Reis
James Kanze writes:
[...]
| |> Je pratique déjà | | |> struct S : T, U, private V { | |> }; | | C'est marrant. Moi, je mets bien l'accolade dans le colonne 1 pour les | fonctions et les classes. Pour la raison ultra-pratique que la seule | définition du début d'une fonction que comprend vi, c'est un { dans le | colonne 1.
vi est programmé en FORTRAN ? ;-p
-- Gaby
James Kanze <kanze@gabi-soft.fr> writes:
[...]
| |> Je pratique déjà
|
| |> struct S : T, U, private V {
| |> };
|
| C'est marrant. Moi, je mets bien l'accolade dans le colonne 1 pour les
| fonctions et les classes. Pour la raison ultra-pratique que la seule
| définition du début d'une fonction que comprend vi, c'est un { dans le
| colonne 1.
| |> Je pratique déjà | | |> struct S : T, U, private V { | |> }; | | C'est marrant. Moi, je mets bien l'accolade dans le colonne 1 pour les | fonctions et les classes. Pour la raison ultra-pratique que la seule | définition du début d'une fonction que comprend vi, c'est un { dans le | colonne 1.
vi est programmé en FORTRAN ? ;-p
-- Gaby
Gabriel Dos Reis
Alexandre BACQUART writes:
| James Kanze wrote: | > C'est marrant. Moi, je mets bien l'accolade dans le colonne 1 pour les | > fonctions et les classes. Pour la raison ultra-pratique que la seule | > définition du début d'une fonction que comprend vi, c'est un { dans le | > colonne 1. | | C'est pareil pour emacs.
Huh??
J'utilise Emacs comme éditeur de texte et cc-mode n'a pas de mal à retrouver ses petits.
[...]
| C'est une économie de lignes, mais perso, je trouve pas ça joli. Enfin
Quand j'étais jeune, je trouvais cela très moche (surtout la première fois que je l'ai vu dans TC++PL2). Et puis, le style de codage a tendance à varier avec le temps, l'expérience, et l'environnement. Ce n'est pas vraiment par économie de ligne que je pratique cela. Je vois "struct", "enum", "namespace" comme des types et le machin entre accolades qui suit comme expression d'initialisation. Pareil pour "int abs(int x)". De même pour "while (cond)", "switch (tag)", "try" ou "catch(Exception e)", que je conceptualise comme typant un graphe de calcul. Comme, tu vois, ce n'est pas que je suis à court de ligne :-)
-- Gaby
Alexandre BACQUART <tek512@hotmail.com> writes:
| James Kanze wrote:
| > C'est marrant. Moi, je mets bien l'accolade dans le colonne 1 pour les
| > fonctions et les classes. Pour la raison ultra-pratique que la seule
| > définition du début d'une fonction que comprend vi, c'est un { dans le
| > colonne 1.
|
| C'est pareil pour emacs.
Huh??
J'utilise Emacs comme éditeur de texte et cc-mode n'a pas de mal à
retrouver ses petits.
[...]
| C'est une économie de lignes, mais perso, je trouve pas ça joli. Enfin
Quand j'étais jeune, je trouvais cela très moche (surtout la première
fois que je l'ai vu dans TC++PL2). Et puis, le style de codage a
tendance à varier avec le temps, l'expérience, et l'environnement.
Ce n'est pas vraiment par économie de ligne que je pratique cela. Je
vois "struct", "enum", "namespace" comme des types et le machin entre
accolades qui suit comme expression d'initialisation.
Pareil pour "int abs(int x)". De même pour "while (cond)",
"switch (tag)", "try" ou "catch(Exception e)", que je conceptualise
comme typant un graphe de calcul. Comme, tu vois, ce n'est pas que
je suis à court de ligne :-)
| James Kanze wrote: | > C'est marrant. Moi, je mets bien l'accolade dans le colonne 1 pour les | > fonctions et les classes. Pour la raison ultra-pratique que la seule | > définition du début d'une fonction que comprend vi, c'est un { dans le | > colonne 1. | | C'est pareil pour emacs.
Huh??
J'utilise Emacs comme éditeur de texte et cc-mode n'a pas de mal à retrouver ses petits.
[...]
| C'est une économie de lignes, mais perso, je trouve pas ça joli. Enfin
Quand j'étais jeune, je trouvais cela très moche (surtout la première fois que je l'ai vu dans TC++PL2). Et puis, le style de codage a tendance à varier avec le temps, l'expérience, et l'environnement. Ce n'est pas vraiment par économie de ligne que je pratique cela. Je vois "struct", "enum", "namespace" comme des types et le machin entre accolades qui suit comme expression d'initialisation. Pareil pour "int abs(int x)". De même pour "while (cond)", "switch (tag)", "try" ou "catch(Exception e)", que je conceptualise comme typant un graphe de calcul. Comme, tu vois, ce n'est pas que je suis à court de ligne :-)
-- Gaby
Gabriel Dos Reis
James Kanze writes:
| BlueR writes: | | |> Je suis aussi cette disposition, et éventuellement s'il y a plus de | |> 3-4 blocs imbriqués et que je commence à y voir moins clair je | |> rajoute un commentaire sur l'accolade fermante. | | S'il y a 3 ou 4 blocs imbriqués, la fonction est trop compliquée.
Je suppose que tu as laissé tomber l'utilisation des classes locales ? ;-)
-- Gaby
James Kanze <kanze@gabi-soft.fr> writes:
| BlueR <blueremi@free.fr_supprimer_> writes:
|
| |> Je suis aussi cette disposition, et éventuellement s'il y a plus de
| |> 3-4 blocs imbriqués et que je commence à y voir moins clair je
| |> rajoute un commentaire sur l'accolade fermante.
|
| S'il y a 3 ou 4 blocs imbriqués, la fonction est trop compliquée.
Je suppose que tu as laissé tomber l'utilisation des classes locales ?
;-)
| BlueR writes: | | |> Je suis aussi cette disposition, et éventuellement s'il y a plus de | |> 3-4 blocs imbriqués et que je commence à y voir moins clair je | |> rajoute un commentaire sur l'accolade fermante. | | S'il y a 3 ou 4 blocs imbriqués, la fonction est trop compliquée.
Je suppose que tu as laissé tomber l'utilisation des classes locales ? ;-)
-- Gaby
Fabien LE LEZ
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 ?
-- ;-) FLL, Epagneul Breton
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 ?
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 ?
-- ;-) FLL, Epagneul Breton
Michel Michaud
Dans news:40c8bb3a$0$26903$, Jean-Noël
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à
Je crois que ce n'est pas une bonne idée de changer ça à la main, surtout qu'il est difficile de revenir en arrière. L'emploi d'outils (genre Artistic Style http://astyle.sourceforge.net/) me paraît vraiment plus judicieux, s'il faut vraiment passer par là...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:40c8bb3a$0$26903$626a14ce@news.free.fr, Jean-Noël
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à
Je crois que ce n'est pas une bonne idée de changer ça à la
main, surtout qu'il est difficile de revenir en arrière. L'emploi
d'outils (genre Artistic Style http://astyle.sourceforge.net/)
me paraît vraiment plus judicieux, s'il faut vraiment passer
par là...
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
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à
Je crois que ce n'est pas une bonne idée de changer ça à la main, surtout qu'il est difficile de revenir en arrière. L'emploi d'outils (genre Artistic Style http://astyle.sourceforge.net/) me paraît vraiment plus judicieux, s'il faut vraiment passer par là...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Michel Michaud
Dans news:, Fabien LE
"Michel Michaud" :
if (cond) { action; }
(dans le dernier cas, le point important est que les accolades sont alignées sur le bloc de code et non pas sur l'instruction de contrôle, ni décalées par rapport au bloc de code).
Pour moi, les accolades ont pour rôle principale de montrer les début et fin d'un bloc. Il faut donc qu'elles soient très visibles, c'est pourquoi je les décale, même si ça revient à favoriser la lisibilité aux dépens de la logique :
if (condition) { action; }
Je ne vois pas en quoi ça rend les accolades plus visibles, surtout si tu décales d'un espace seulement ! Ça ajoute surtout un niveau d'indentation que tu ne verrais pas dans les langages sans délimiteur comme Ada ou VB, et c'est ce qui est reproché à ce style dans « Code Complete ». 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.
Par contre, tu aimeras ce qui est dit aussi spécifiquement sur ce style dans Code Complete: « Avoid double indentation [...] One study showed no difference in comprehension between programs that are singly indented and programs that are doubly indented (Miara et al. 1983), but [j'imagine que tu ne veux pas en savoir plus :-)]... »
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:meihc01fe54c05c8li46oi8hqlk934nngu@4ax.com, Fabien LE
"Michel Michaud" <mm@gdzid.com> :
if (cond)
{
action;
}
(dans le dernier cas, le point important est que les accolades
sont alignées sur le bloc de code et non pas sur l'instruction
de contrôle, ni décalées par rapport au bloc de code).
Pour moi, les accolades ont pour rôle principale de montrer les
début et fin d'un bloc. Il faut donc qu'elles soient très
visibles, c'est pourquoi je les décale, même si ça revient à
favoriser la lisibilité aux dépens de la logique :
if (condition)
{
action;
}
Je ne vois pas en quoi ça rend les accolades plus visibles,
surtout si tu décales d'un espace seulement ! Ça ajoute surtout
un niveau d'indentation que tu ne verrais pas dans les langages
sans délimiteur comme Ada ou VB, et c'est ce qui est reproché à
ce style dans « Code Complete ». 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.
Par contre, tu aimeras ce qui est dit aussi spécifiquement sur
ce style dans Code Complete: « Avoid double indentation [...]
One study showed no difference in comprehension between programs
that are singly indented and programs that are doubly indented
(Miara et al. 1983), but [j'imagine que tu ne veux pas en savoir
plus :-)]... »
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
(dans le dernier cas, le point important est que les accolades sont alignées sur le bloc de code et non pas sur l'instruction de contrôle, ni décalées par rapport au bloc de code).
Pour moi, les accolades ont pour rôle principale de montrer les début et fin d'un bloc. Il faut donc qu'elles soient très visibles, c'est pourquoi je les décale, même si ça revient à favoriser la lisibilité aux dépens de la logique :
if (condition) { action; }
Je ne vois pas en quoi ça rend les accolades plus visibles, surtout si tu décales d'un espace seulement ! Ça ajoute surtout un niveau d'indentation que tu ne verrais pas dans les langages sans délimiteur comme Ada ou VB, et c'est ce qui est reproché à ce style dans « Code Complete ». 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.
Par contre, tu aimeras ce qui est dit aussi spécifiquement sur ce style dans Code Complete: « Avoid double indentation [...] One study showed no difference in comprehension between programs that are singly indented and programs that are doubly indented (Miara et al. 1983), but [j'imagine que tu ne veux pas en savoir plus :-)]... »
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Michel Michaud
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).
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
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).
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
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).
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Fabien LE LEZ
On Fri, 11 Jun 2004 00:38:43 -0400, "Michel Michaud" wrote:
Un bloc de 27 lignes EST TROP LONG
Même quand la moitié des lignes sont soit des lignes entièrement blanches, soit ne contiennent qu'une accolade ?
Evidemment, en écrivant le code comme ça :
for (int i=0; i<10; ++i) { int j= f(i); if (j>i) --j; else ++j; cout << j; }
27 lignes, ça fait beaucoup. Mais quand je tape :
for (int i=0; i<10; ++i) { int j= f(i);
if (j>i) { --j; } else { ++j; }
cout << j; }
il suffit que la boucle soit un tantinet plus compliquée, et on arrive vite à une bonne vingtaine de lignes...
-- ;-) FLL, Epagneul Breton
On Fri, 11 Jun 2004 00:38:43 -0400, "Michel Michaud" <mm@gdzid.com>
wrote:
Un bloc de 27 lignes EST TROP LONG
Même quand la moitié des lignes sont soit des lignes entièrement
blanches, soit ne contiennent qu'une accolade ?
Evidemment, en écrivant le code comme ça :
for (int i=0; i<10; ++i) {
int j= f(i);
if (j>i)
--j;
else
++j;
cout << j;
}
27 lignes, ça fait beaucoup. Mais quand je tape :
for (int i=0; i<10; ++i)
{
int j= f(i);
if (j>i)
{
--j;
}
else
{
++j;
}
cout << j;
}
il suffit que la boucle soit un tantinet plus compliquée, et on arrive
vite à une bonne vingtaine de lignes...
