Accolades : conventions d'ecriture

"Mickael Pointier" <mpointier@edengames.moc> writes:

|> > En ce qui me concerne je privilégie la compacité et la vision du bloc
|> > en un coup d'oeil.
|> > J'utilise donc
|> > if( ...) {
|> > ....
|> > }

|> Ce que je n'aime pas avec le fait que les deux accolades ne soient
|> pas sur la même colonne, c'est que ca rend inutile la fonction que
|> j'utilise dans mon éditeur, qui me montre la "matching parenthesis".
|> Je sais que si c'est sur la même colonne, c'es que je n'ai pas
|> d'inconsistance au niveau des imbrications.

Mes éditeurs (vim et emacs) font aussi l'indentation automatique. Si,
quand j'entre un fin de ligne, la nouvelle ligne ne s'y met pas où je
m'attends, ça veut dire que je me suis trompé d'un parenthèse quelque
part.

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

|> Ce que je n'aime pas avec le code conditionné sur la même ligne que
|> le if, c'est que dans la majorité des IDE que j'utilise, il n'est
|> pas possible de positionner un point d'arrêt sur le code en
|> question.

Ce que je n'aime pas, moi, c'est que quand je veux saisir en gros une
fonction, c'est la gauche des lignes que je régarde. Normalement, on
doit pouvoir saisir tout ce que fait la ligne en ne lisant que les deux
ou trois premiers tokens : « if », c'est une condition, « nom = », une
affectation, « fonc( » l'appel d'une procédure...

Pour que ça marche, il faut qu'une ligne fasse une, et seulement une
chose.

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

Jusqu'un certain point. J'ai déjà eu à réprendre du code sans la moindre
indentation, c-à-d quelque chose comme :

if ( condition ) {
quelqueChose ;
autreChose ; }
etEncore ;

Ou même une fois, une indentation aléatoire, y compris (une fois au
moins) :

if ( condition )
quelqueChose ;
autreChose ;
etEncore ;

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

"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message news:

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

Tout à fait d'accord
Yves

"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message news:

J'utilise donc
if( ...) {
....
}

Question subsidiaire : comment se présente ce genre d'écriture quand
la condition ne tient pas sur une ligne ?

Bonne remarque :

if( ........
........
........) {
etc.
}

l'oeil passe du if au } et identifie le bloc de la même façon.
Il me semble qu'il s'agit de ma part d'une manie de programmeur parmi
d'autres.
Yves

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. Ca m'étonnerait pas que :

xxx {
}

...ne soit presque jamais utilisé pour les fonctions principalement à
cause de ces 2 éditeurs.

C'est une économie de lignes, mais perso, je trouve pas ça joli. Enfin
tant qu'on omet pas les indentations à l'intérieur des blocs, ce n'est
pas gênant.


--
Tek

On Fri, 11 Jun 2004 17:05:39 +0200, "PurL" <purl-nospam@chez.com>
wrote:

Non j'ai mis autant d'espaces pour retrouver l'espace d'un tab-4 avec ma
police de développement

Tu veux dire que tu écris sur Usenet avec une police à chasse
variable ? :-o
Sur fclc++, car doit être franchement infernal :-/


--
;-)
FLL, Epagneul Breton

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

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

|> vi est programmé en FORTRAN ? ;-p

Peut-être pas, mais c'est prèsque aussi vieux:-).

En fait, j'imagine qu'il doit être possible de modifier ce « feature »
dans des versions moderne : viper et vim. Mais vu que j'ai l'habitude,
et qu'il traite *mon* style correctement, je n'ai jamais cherché si ou
comment.

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

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

|> 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
|> ? ;-)

Pas le choix. Les auteurs de la norme à décider qu'elles ne marchent pas
complètement. (Neuf fois sur dix, quand je veux une classe locale, c'est
pour instantier un template.)

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

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.

Ça m'étonnerait un peu. Emacs, c'est écrit en elisp, et tu lui fais
faire tout ce que tu veux. Mais vraiment tout.

Moi, évidemment, quand je me sers d'emacs, c'est en mode viper. Et là,
par défaut au moins, il fait ce que fait vi. Mais même là, ça
m'étonnerait de ne pas pouvoir le modifier.

|> Ca m'étonnerait pas que :

|> xxx {
|> }

|> ...ne soit presque jamais utilisé pour les fonctions principalement
|> à cause de ces 2 éditeurs.

Ce n'est prèsque jamais utilisé parce que les pères ne s'en servaient
pas. Et ni vi ni emacs ne peut en être la raison, pour la simple raison
qu'ils n'existaient ni l'un ni l'autre à l'époque (au moins sous Unix,
en ce qui concerne emacs).

|> C'est une économie de lignes, mais perso, je trouve pas ça joli.
|> Enfin tant qu'on omet pas les indentations à l'intérieur des blocs,
|> ce n'est pas gênant.

En fait, il n'y a qu'un seul style de vrai : celui des pères. Comme on
voit dans "The C Programming Language" (première édition, évidemment, de
1978). La preuve, c'est le style que j'utilise chez moi:-). (Et aussi
évidemment, il ne dit pas grand chose sur comment traiter les
namespace.)

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

On Fri, 11 Jun 2004 08:55:39 -0400, "Michel Michaud" <mm@gdzid.com>
wrote:

Trouve un vrai exemple de 27 lignes ou plus et
on pourra discuter !

namespace MonNamespaceAMoi
{
/* Ici, trois définitions de classes, vingt-deux fonctions, pour un
total de 513 lignes */
} //end namespace MonNamespaceAMoi


--
;-)
FLL, Epagneul Breton

On 11 Jun 2004 23:57:19 +0200, James Kanze <kanze@gabi-soft.fr> wrote:

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.

N'existe-t-il pas de "grep spécialisé", capable de repérer la
définition d'une fonction automatiquement, sans imposer ce style ?

Bon, évidemment, j'imagine que ça doit être beaucoup plus facile de
faire fonctionner un tel programme sur les projets sur lesquels je
travaille (quelques dizaines de milliers de lignes) que sur les
tiens... ;-)


--
;-)
FLL, Epagneul Breton