Accolades : conventions d'ecriture

Dans news:wkwu2eoc77.fsf@fgeorges.org,

"Michel Michaud" <mm@gdzid.com> writes:

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 ?

Même là, oui, probablement, en tout cas, pour plusieurs personnes.
Mais je parlais vraiment de blocs de code dans une structure de
contrôle. Personnellement, je n'ai pas de problèmes avec des
fonctions de 50 lignes, même si je n'en fais pas souvent.

--
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 news:cabmrr$l1t$1@news-reader1.wanadoo.fr,

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

Tu as décalé de 6, est-ce un hasard. D'après les études citées
dans Code Complete, un décalage de 6 est initialement jugé
« élégant », mais s'avère presque aussi mauvais pour la réelle
lisibilité que pas de décalage du tout !

Apparement, personne ne fait comme cela mais je trouve qu'on

Non, plusieurs font comme toi. Le problème c'est que ce que tu
considères est « faux », les accolades ne font pas partie du if
en C++. Disons qu'en C/C++/Java/etc. c'est moins pire qu'en
Pascal car les accolades sont moins lourdes que les BEGIN-END :

IF (condition) THEN
BEGIN
action
END

Là vraiment, on perd la clarté du IF...

[...]

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

La beauté est une question d'habitude :-)

--
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 news:cabnpf$og3$1@aphrodite.grec.isp.9tel.net, Mickael

Au final, ce qui compte c'est que le style soit consistant au
niveau du projet, le reste ca n'est que du détail.

Il faut quand même utiliser un style qui ne nuit pas inutilement
à la lisibilité. « Aucun décalage » par exemple est un style
réellement inacceptable.

--
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> writes:

Dans news:wkwu2eoc77.fsf@fgeorges.org,

"Michel Michaud" <mm@gdzid.com> writes:

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 ?

Même là, oui, probablement, en tout cas, pour plusieurs personnes.
Mais je parlais vraiment de blocs de code dans une structure de
contrôle. Personnellement, je n'ai pas de problèmes avec des
fonctions de 50 lignes, même si je n'en fais pas souvent.

OK. Nous sommes d'accord, alors. Il est rare que j'écrive des
fonctions qui ne tiennent pas en entier sur ma console. Mais il y a
tout de même des cas ou cela est justifié.

--drkm

Gabriel Dos Reis <gdr@cs.tamu.edu> writes:

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

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

Je me demande si tu as bien compris. Je repondais a la question
"que faire quand on utilise

if (...) {
}

et que la condition devient trop longue pour mettre tout sur une
ligne?"

C'est intéressant.

Ma propre pratique dans mon propre code (cad pour moi ou bien dans les
projets n'ayant pas de conventions clairement etablies) est trop
dependante des conventions utilisees par le projet sur lequel je suis
en train de travailler (et donc varie, ... trop a mon gout). Si j'ai
une tendance c'est plutot de mettre les accolades ouvrantes a la fin
des lignes plutot que seules sur une ligne sauf quand il y a trop pour
tout mettre sur la ligne auquel cas la premiere etape est de mettre
l'accolade toute seule puis de decouper logiquement sans jamais
remettre l'accolade a la fin. Cad j'utilise

if (...
....)
{

de preference a

if (...
....) {

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

Tu as décalé de 6, est-ce un hasard. D'après les études citées
dans Code Complete, un décalage de 6 est initialement jugé
« élégant », mais s'avère presque aussi mauvais pour la réelle
lisibilité que pas de décalage du tout !

Non j'ai mis autant d'espaces pour retrouver l'espace d'un tab-4 avec ma
police de développement
Moi aussi je trouve qu'une tabulation de 4 est un bon compromis.

Non, plusieurs font comme toi. Le problème c'est que ce que tu
considères est « faux », les accolades ne font pas partie du if

peut-etre mais alors dans les bouquins, quand on explique les structures de
controle, on dit souvent :

if (cond)
{
//code
}

si les accolades font parties du code et non pas du if, il faut dire :

if (cond) bloc_de_code

où bloc de code peut-etre :
-une instruction simple
-plusieurs instruction encadrées d'accolades

en C++. Disons qu'en C/C++/Java/etc. c'est moins pire qu'en
Pascal car les accolades sont moins lourdes que les BEGIN-END :

IF (condition) THEN
BEGIN
action
END

Là vraiment, on perd la clarté du IF...

Je suis d'accord.
Mais j'ai quand meme vu des gens faire dans un programme C :
#define BEGIN {
#define END }

et faire :

if (condition)
BEGIN
action
END

:)

La beauté est une question d'habitude :-)

C'est vrai que tout est question d'habitude.
Le plus important, je pense, c'est d'etre constant dans ses conventions,
combien de programmes je vois avec :

un coup if( cond ), un coup if (cond)
un coup mafonc(param1, param2) ou mafonc(param1,param2) ou encore
mafonc(param1 , param2)

Ca par contre, ca m'enerve :)

PurL

Gabriel Dos Reis <gdr@cs.tamu.edu> writes:

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

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.

--
James Kanze
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

"Alain Naigeon" <anaigeon@free.fr> writes:

|> "Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message
|> news: bd4ic09ojv926592l3fo9rjqlg34323s38@4ax.com...
|> > 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 ?

|> Une condition longuette, c'est du bon style ? On peut la raccourcir
|> avec des appels de fonctions, des typedef, etc.

Ça dépend de la condition. J'évite des expressions booléennes
embriquées, du genre (a && b) || (c && d), mais je ne trouve rien à
rédire à une série même étendue des conditions liées par le même
opérateur :

if ( someCondition
|| anotherCondition
|| somethingElse
|| whatever ) {
gagné() ;
}

--
James Kanze
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

"PurL" <purl-nospam@chez.com> writes:

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

C'est quand même ce que j'ai le plus vu. (C'est le style que j'utilise
au travail actuellement.)

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

Jamais. Le type va sur une ligne seule. De façon à ce que :

grep ^mafonc *.cc

trouve la définition de la fonction, et que sa définition.

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

En plus, vi (ni vim, ni viper) ne sait le reconnaître comme début d'une
fonction.

--
James Kanze
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

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.

--
James Kanze
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