Accolades : conventions d'ecriture

Fabien LE LEZ <gramster@gramster.com> writes:

J'écris systématiquement l'accolade ouvrante et l'accolade fermante
sur une même colonne :

if (condition)
{
action;
}

Je faisais cela aussi.

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;
}

Je fais cela, maintenant. Je ne sais pourquoi, je suis passé de
l'une à l'autre. Je suis pourtant plutôt intégriste sur mes standards
de codage personnels.

Je suppose qu'il s'agit d'une histoire de compacité du code. Ma
console est en 35x80, c'est parfois un peu étroit, lorsque tu
décomptes le minibuffer et la modeline sous Emacs.

J'aimerais savoir si les gens qui ont l'habitude des deux conventions,
arrivent à lire aussi facilement la deuxième que la première.

J'avais extrêmement de mal. Puis on s'y fait. C'est une question
d'habitude. Si tu poses la question parce que tu arrives sur un
nouveau projet utilisant des standards de codage différents, je pense
pouvoir dire : « T'inquiètes, ça vient vite ».

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.

Emacs. Et AMHA beaucoup d'autres, mais c'est le seul que je
connaisse.

--drkm

Fabien LE LEZ <gramster@gramster.com> wrote in
news:v5eec0ddtobbguos0vp0b972diupp2gs66@4ax.com:

[...]
J'aimerais savoir si les gens qui ont l'habitude des deux conventions,
arrivent à lire aussi facilement la deuxième que la première.

Sur les forums et dans certains codes, il m'arrive de ne pas sauter à la
ligne avant une accolade. C'est surtout valable quand le code à exécuter
ne contient que quelques lignes. Après avec le foldind (repli
intelligent du code), je ne me rends plus trop compte de ce genre de
choses.

Autrement, je déteste et ai un mal fou avec ton premier style. Pour moi
les accolades s'alignent sans décalage sur ce qui les précèdent => if
(...)
{
code;
}

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.

Je pense que les vrais éditeurs n'ont que faire de ce détail -- quand un
plugin qui donne des couleurs différentes aux blocs est utilisé.

--
Luc Hermitte <hermitte at free.fr>
FAQ de <news:fr.comp.lang.c++> :
<http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/>
Dejanews : <http://groups.google.com/advanced_group_search>

Fabien LE LEZ wrote:

Bonjour,

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.

Merci d'avance...

j'utilise les deux assez frequemeent et je trouve que la lisibilité du
bloc de la premiere solution n'est valide que lorsque le bloque tiend
sur un ecran, quand il faut scrollé, ca devient plus dur.
par contre un avantage de la premiere et le "commentage" rapide du test
// if|while ()
{
}
au lieu de /* if (...) */ {
mais bon, ca ne faire gagner que qq pression de touches

Twxs

Fabien LE LEZ <gramster@gramster.com> wrote in message
news:<v5eec0ddtobbguos0vp0b972diupp2gs66@4ax.com>...

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.

C'est surtout l'indentation qui me permet de voir la structure en blocs.

Tu me dirais que l'indentation peut mentir. C'est vrai, mais mes
éditeurs à moi (vim et emacs) ont des commandes pour la rétablir, de
façon à ce qu'elle ne ment plus.

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.

Tout dépend. J'utilise la seconde actuellement, après beaucoup d'années
avec le premier. AMHA, pour que la seconde marche, il faut qu'on ait
*toujours* les accolades. Je suis d'accord avec toi que quelque chose
comme :

if ( condition )
action ;
else {
autre_action ;
}

prête à confusion. En fait, je vois deux alternatifs acceptable :

if ( condition )
{
action ;
}
else
{
autre_action ;
}

et

if ( condition ) {
action ;
} else {
autre_action ;
}

Dans la première, on peut aussi ôter les {...} s'il s'agit d'une seule
instruction. Dans la seconde, du fait que les {...} ne sont pas
particulièrement visibles, il les faut systèmatiquement ; il ne faut pas
avoir à poser la question, chercher la fin de la ligne pour voir, etc.
Si, en revanche, on impose cette condition, et le code est indenté
correctement, je trouve la deuxième forme même légèrement (mais très
légèrement) plus lisible.

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.

Les éditeurs que j'utilise ne change pas la couleur selon les niveaux.
En revanche, ils savent bien prendre en compte les { et les } où qu'ils
se trouvent, pour l'indentation, et aussi pour le folding.

Mais dans la pratique, je ne trouve pas qu'il y a un problème. Après
tout, s'il y plus d'un, ou à la rigueur deux niveaux d'imprication, ou
deux ou trois éléments qui suivent, c'est déjà que la fonction est trop
grande.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Jean-Marc Bourguet <jm@bourguet.org> writes:

| J'ai tendance (*) a passer de
|
| if (...) {
| }
|
| a
|
| if (...)
| {
| }

C'est intéressant. Dans mes propres codes, j'ai longtemps pratiqué

if (...)
{
}

(corrompu en partie par GNU, en partie par Pascal et dérivés lorsque
j'étais jeune). Maintenant je passe à

if (...) {
}

en même temps que je passe de

namespace N
{
}

à

namespace N {
}

Je pratique déjà

struct S : T, U, private V {
};

-- Gaby

Dans news:v5eec0ddtobbguos0vp0b972diupp2gs66@4ax.com, Fabien LE

Bonjour,

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.

Oui. On y arrive... si tu fais la deuxième comme j'indique plus
loin :-)

Il est intéressant de lire « Code Complete » de McConnell. Les
deux styles qui sont acceptables, qui représentent deux visions
différentes des choses qu'il nomme « pure-block emulation »
et « begin-end block boundaries », seraient

if (cond) {
action;
}

et

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

Des études démontreraient qu'il n'y a pas de différence
significative de compréhension entre les deux. Le pure-block
est ce qu'on a en Ada et VB qui n'ont pas de délimiteur initial,
alors en C/C++/Pascal/etc. on doit l'émuler en « cachant » le
délimiteur initial sur la ligne de l'instruction de contrôle.

Ceci dit, mon expérience m'a démontré que les bogues sont plus
rares et plus faciles à trouver (particulièrement pour des
débutants) avec le deuxième style. On peut aussi plus facilement
recopier du code, etc. Et on ne fait pas de l'émulation d'un
autre langage !

Je persiste cependant à croire que le style à deux délimiteurs de
n'est pas le meilleur, en particulier parce qu'il laisse trop de
choix. Les délimiteurs d'instructions comme dans Ada et VB me
semblent plus simples et clairs, mais j'aime bien aussi la simple
indentation (comme dans Python m'a-t-on dit).

Oh ! Et tiens, j'ajoute que l'indentation idéale (d'après les
études) est de 2 à 4 espaces. Mais lorsqu'on écrit du code à
la main (ou sur un tableau noir), il est plus clair d'être autour
de 4...

--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

"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à !

Bonsoir Fabien,

En ce qui me concerne je privilégie la compacité et la vision du bloc en un
coup d'oeil.
J'utilise donc
if( ...) {
....
}
Voire : if(..) {...} // lorsque c'est court

Les lignes blanches me montrent immédiatement les pavés logiques et la
maintenance en est plus facile à mon goût.
Yves

Je me permets de répondre à deux posts en même temps...

"Yalbrieux" <yalbrieux@wanadoo.fr> :

J'utilise donc
if( ...) {
....
}
Voire : if(..) {...} // lorsque c'est court

Les lignes blanches me montrent immédiatement les pavés logiques et la
maintenance en est plus facile à mon goût.

Justement, pour moi le "if (condition)" ne fait pas vraiment partie du
bloc d'instructions.
En gros, je pars de :

if (condition)
f();
else
g();

Comme appeler systématiquement une fonction n'est pas forcément une
bonne idée, je remplace la fonction qui serait appelée par son
contenu, à savoir, un bloc :

if (condition)
{
++i;
++j;
}
else
{
++k;
--l;
}

"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;
}


--
;-)
FLL, Epagneul Breton

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 :-)
--
;-)
FLL, Epagneul Breton