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.
Ou même une fois, une indentation aléatoire, y compris (une fois au moins) :
if ( condition ) quelqueChose ; autreChose ; etEncore ;
En-dehors de l'IOCCC ?
Dans du code de production chez un client. Un autre bon que j'ai vu :
while ( uneConditionBienCompliquee ); instructionSuivant;
(Note bien le ';' derrière le while, sur la même ligne.)
Mais celui-là, ce n'est pas la faute du programmeur. C'était en sortie de cb. Une moulinnette pour « corriger » l'indentation.
-- 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
James Kanze writes:
Ou même une fois, une indentation aléatoire, y compris (une fois au moins) :
if ( condition ) quelqueChose ; autreChose ; etEncore ;
Les seuls cas d'indentation apparemment aleatoire (par opposition a inhomogene ou suivant la fonction ou la section de la fonction qu'on regarde on a une indentation differente) que j'ai vus en dehors de travaux remis par des etudiants etaient dus a l'utilisation des TAB. Qqun avait edite le fichier avec des TAB a 4 et qq d'autre a 8... Le resultat etait « amusant » quel que soit la taille utilisee.
A+
-- Jean-Marc, qui n'utilise pas de TAB, ca regle le probleme 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
James Kanze <kanze@gabi-soft.fr> writes:
Ou même une fois, une indentation aléatoire, y compris (une fois au
moins) :
if ( condition )
quelqueChose ;
autreChose ;
etEncore ;
Les seuls cas d'indentation apparemment aleatoire (par opposition a
inhomogene ou suivant la fonction ou la section de la fonction qu'on
regarde on a une indentation differente) que j'ai vus en dehors de
travaux remis par des etudiants etaient dus a l'utilisation des TAB.
Qqun avait edite le fichier avec des TAB a 4 et qq d'autre a 8... Le
resultat etait « amusant » quel que soit la taille utilisee.
A+
--
Jean-Marc, qui n'utilise pas de TAB, ca regle le probleme
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
Ou même une fois, une indentation aléatoire, y compris (une fois au moins) :
if ( condition ) quelqueChose ; autreChose ; etEncore ;
Les seuls cas d'indentation apparemment aleatoire (par opposition a inhomogene ou suivant la fonction ou la section de la fonction qu'on regarde on a une indentation differente) que j'ai vus en dehors de travaux remis par des etudiants etaient dus a l'utilisation des TAB. Qqun avait edite le fichier avec des TAB a 4 et qq d'autre a 8... Le resultat etait « amusant » quel que soit la taille utilisee.
A+
-- Jean-Marc, qui n'utilise pas de TAB, ca regle le probleme 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
Gabriel Dos Reis
Fabien LE LEZ writes:
| On 13 Jun 2004 15:27:29 -0500, Gabriel Dos Reis : | | >Lorsque C++ a introduit les « namespaces » -- que nombre de | >programmeurs décrivent comme complexes -- les « ; » n'étaient pas | >nécessaires pour marquer la fin de définition d'un namespace -- | >contrairement aux structs de C. | | C'est logique : on peut instancier une classe, pas un namespace.
On peut aussi instancier une fonction ; et pourtant on n'a pas besoin de « ; » pour marquer la fin de definition.
(On peut très bien aussi concevoir instantier un namespace.)
| Quant à savoir si instancier une classe dans la même instruction que | sa définition est une bonne idée...
Exatement.
-- Gaby
Fabien LE LEZ <gramster@gramster.com> writes:
| On 13 Jun 2004 15:27:29 -0500, Gabriel Dos Reis <gdr@cs.tamu.edu>:
|
| >Lorsque C++ a introduit les « namespaces » -- que nombre de
| >programmeurs décrivent comme complexes -- les « ; » n'étaient pas
| >nécessaires pour marquer la fin de définition d'un namespace --
| >contrairement aux structs de C.
|
| C'est logique : on peut instancier une classe, pas un namespace.
On peut aussi instancier une fonction ; et pourtant on n'a pas besoin de
« ; » pour marquer la fin de definition.
(On peut très bien aussi concevoir instantier un namespace.)
| Quant à savoir si instancier une classe dans la même instruction que
| sa définition est une bonne idée...
| On 13 Jun 2004 15:27:29 -0500, Gabriel Dos Reis : | | >Lorsque C++ a introduit les « namespaces » -- que nombre de | >programmeurs décrivent comme complexes -- les « ; » n'étaient pas | >nécessaires pour marquer la fin de définition d'un namespace -- | >contrairement aux structs de C. | | C'est logique : on peut instancier une classe, pas un namespace.
On peut aussi instancier une fonction ; et pourtant on n'a pas besoin de « ; » pour marquer la fin de definition.
(On peut très bien aussi concevoir instantier un namespace.)
| Quant à savoir si instancier une classe dans la même instruction que | sa définition est une bonne idée...
Exatement.
-- Gaby
Fabien LE LEZ
On 14 Jun 2004 10:30:01 +0200, Jean-Marc Bourguet :
Qqun avait edite le fichier avec des TAB a 4 et qq d'autre a 8...
M'étant fait avoir une ou deux fois, j'ai réglé tous mes éditeurs pour ne pas utiliser le caractère "TAB", et insérer les espaces qui vont bien à la place, quand je tape TAB ou quand ça indente automatiquement.
-- schtroumpf schtroumpf
On 14 Jun 2004 10:30:01 +0200, Jean-Marc Bourguet <jm@bourguet.org>:
Qqun avait edite le fichier avec des TAB a 4 et qq d'autre a 8...
M'étant fait avoir une ou deux fois, j'ai réglé tous mes éditeurs pour
ne pas utiliser le caractère "TAB", et insérer les espaces qui vont
bien à la place, quand je tape TAB ou quand ça indente
automatiquement.
On 14 Jun 2004 10:30:01 +0200, Jean-Marc Bourguet :
Qqun avait edite le fichier avec des TAB a 4 et qq d'autre a 8...
M'étant fait avoir une ou deux fois, j'ai réglé tous mes éditeurs pour ne pas utiliser le caractère "TAB", et insérer les espaces qui vont bien à la place, quand je tape TAB ou quand ça indente automatiquement.
-- schtroumpf schtroumpf
Mickael Pointier
Moi aussi ! Evidemment on a tous oublié un jour d'ajouter les accolades lorsqu'il a fallu écrire une deuxième instruction.
(pour la même raison, je mets toujours un break théoriquement superflu à la fin de mes case).
Pareil :)
C'est comme le fait de systématiquement mettre un "nop" dans les delay slot quad on fait de l'assembleur mips :) Ca fait partit des bugs à la con qui prennent parfois des heures à trouver parce qu'on a beau relire 10 fois le code on ne vois pas le problème (pour ca que j'aime bien tracer le code même quand il donne l'impression de bien fonctionner, ca me confirme qu'il fait ce que je pense qu'il devait faire)
Mike
Moi aussi ! Evidemment on a tous oublié un jour d'ajouter les
accolades lorsqu'il a fallu écrire une deuxième instruction.
(pour la même raison, je mets toujours un break théoriquement
superflu à la fin de mes case).
Pareil :)
C'est comme le fait de systématiquement mettre un "nop" dans les delay slot
quad on fait de l'assembleur mips :)
Ca fait partit des bugs à la con qui prennent parfois des heures à trouver
parce qu'on a beau relire 10 fois le code on ne vois pas le problème (pour
ca que j'aime bien tracer le code même quand il donne l'impression de bien
fonctionner, ca me confirme qu'il fait ce que je pense qu'il devait faire)
Moi aussi ! Evidemment on a tous oublié un jour d'ajouter les accolades lorsqu'il a fallu écrire une deuxième instruction.
(pour la même raison, je mets toujours un break théoriquement superflu à la fin de mes case).
Pareil :)
C'est comme le fait de systématiquement mettre un "nop" dans les delay slot quad on fait de l'assembleur mips :) Ca fait partit des bugs à la con qui prennent parfois des heures à trouver parce qu'on a beau relire 10 fois le code on ne vois pas le problème (pour ca que j'aime bien tracer le code même quand il donne l'impression de bien fonctionner, ca me confirme qu'il fait ce que je pense qu'il devait faire)
Mike
Mickael Pointier
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.)
En fait mon style c'est celui du GFA Basic adapté au C :)
Franchement, je déteste le C et le C++ au niveau syntaxique, je ne supporte pas les ";", le fait de devoir parenthèser les expressions n'a pour moi absolument aucun intéret, c'est juste du verbiage inutile :)
Mais bon, après effectivement on peut faire tout ce qu'on veut avec ces langages là, donc je m'en sert.
Je serais très content de pouvoir remplacer:
if (expression) { do_truc(42); }
par
if expression do_truc(42) endif
parce que franchement, le "}" n'importe pas beaucoup d'information sur le type du scope.
A la place de
for ( { while ( { if ( { } } }
est-ce que ca serait si terrible que ca d'avoir:
for ( while ( if ( endif endwhile endfor
C'est verbeux, clairement, mais moi ca m'aurait été parfaitement :)
Vala, si ca c'est pas du total HS !
Mike (qui arrête le thread avec ca)
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.)
En fait mon style c'est celui du GFA Basic adapté au C :)
Franchement, je déteste le C et le C++ au niveau syntaxique, je ne supporte
pas les ";", le fait de devoir parenthèser les expressions n'a pour moi
absolument aucun intéret, c'est juste du verbiage inutile :)
Mais bon, après effectivement on peut faire tout ce qu'on veut avec ces
langages là, donc je m'en sert.
Je serais très content de pouvoir remplacer:
if (expression)
{
do_truc(42);
}
par
if expression
do_truc(42)
endif
parce que franchement, le "}" n'importe pas beaucoup d'information sur le
type du scope.
A la place de
for (
{
while (
{
if (
{
}
}
}
est-ce que ca serait si terrible que ca d'avoir:
for (
while (
if (
endif
endwhile
endfor
C'est verbeux, clairement, mais moi ca m'aurait été parfaitement :)
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.)
En fait mon style c'est celui du GFA Basic adapté au C :)
Franchement, je déteste le C et le C++ au niveau syntaxique, je ne supporte pas les ";", le fait de devoir parenthèser les expressions n'a pour moi absolument aucun intéret, c'est juste du verbiage inutile :)
Mais bon, après effectivement on peut faire tout ce qu'on veut avec ces langages là, donc je m'en sert.
Je serais très content de pouvoir remplacer:
if (expression) { do_truc(42); }
par
if expression do_truc(42) endif
parce que franchement, le "}" n'importe pas beaucoup d'information sur le type du scope.
A la place de
for ( { while ( { if ( { } } }
est-ce que ca serait si terrible que ca d'avoir:
for ( while ( if ( endif endwhile endfor
C'est verbeux, clairement, mais moi ca m'aurait été parfaitement :)
Vala, si ca c'est pas du total HS !
Mike (qui arrête le thread avec ca)
drkm
"Mickael Pointier" writes:
A la place de
for ( { while ( { if ( { } } }
est-ce que ca serait si terrible que ca d'avoir:
for ( while ( if ( endif endwhile endfor
C'est verbeux, clairement, mais moi ca m'aurait été parfaitement :)
#define for( x ) for ( x ) { #define endfor } #define if( x ) if ( x ) { #define endif } #define while( x ) while ( x ) { #define endwhile }
C'est verbeux, clairement, mais moi ca m'aurait été parfaitement :)
#define for( x ) for ( x ) { #define endfor } #define if( x ) if ( x ) { #define endif } #define while( x ) while ( x ) { #define endwhile }
;-)
--drkm
drkm
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 ?
--drkm
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 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 ?
--drkm
kanze
Jean-Marc Bourguet wrote in message news:...
James Kanze writes:
Ou même une fois, une indentation aléatoire, y compris (une fois au moins) :
if ( condition ) quelqueChose ; autreChose ; etEncore ;
Les seuls cas d'indentation apparemment aleatoire (par opposition a inhomogene ou suivant la fonction ou la section de la fonction qu'on regarde on a une indentation differente) que j'ai vus en dehors de travaux remis par des etudiants etaient dus a l'utilisation des TAB. Qqun avait edite le fichier avec des TAB a 4 et qq d'autre a 8... Le resultat etait « amusant » quel que soit la taille utilisee.
Mais tu es peut-être plus jeune que moi. Aujourd'hui, l'importance d'une indentation cohérente est plus ou moins universellement reconnue, et je crois que les étudiants l'apprenent à l'école. Ce n'était pas toujours le cas. Les deux cas que j'ai vu date d'il y a au moins 15 ans, et ils se trouvent dans du code qui était déjà assez ancien.
-- 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> wrote in message
news:<pxbhdte35km.fsf@news.bourguet.org>...
James Kanze <kanze@gabi-soft.fr> writes:
Ou même une fois, une indentation aléatoire, y compris (une fois au
moins) :
if ( condition )
quelqueChose ;
autreChose ;
etEncore ;
Les seuls cas d'indentation apparemment aleatoire (par opposition a
inhomogene ou suivant la fonction ou la section de la fonction qu'on
regarde on a une indentation differente) que j'ai vus en dehors de
travaux remis par des etudiants etaient dus a l'utilisation des TAB.
Qqun avait edite le fichier avec des TAB a 4 et qq d'autre a 8... Le
resultat etait « amusant » quel que soit la taille utilisee.
Mais tu es peut-être plus jeune que moi. Aujourd'hui, l'importance d'une
indentation cohérente est plus ou moins universellement reconnue, et je
crois que les étudiants l'apprenent à l'école. Ce n'était pas toujours
le cas. Les deux cas que j'ai vu date d'il y a au moins 15 ans, et ils
se trouvent dans du code qui était déjà assez ancien.
--
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
Ou même une fois, une indentation aléatoire, y compris (une fois au moins) :
if ( condition ) quelqueChose ; autreChose ; etEncore ;
Les seuls cas d'indentation apparemment aleatoire (par opposition a inhomogene ou suivant la fonction ou la section de la fonction qu'on regarde on a une indentation differente) que j'ai vus en dehors de travaux remis par des etudiants etaient dus a l'utilisation des TAB. Qqun avait edite le fichier avec des TAB a 4 et qq d'autre a 8... Le resultat etait « amusant » quel que soit la taille utilisee.
Mais tu es peut-être plus jeune que moi. Aujourd'hui, l'importance d'une indentation cohérente est plus ou moins universellement reconnue, et je crois que les étudiants l'apprenent à l'école. Ce n'était pas toujours le cas. Les deux cas que j'ai vu date d'il y a au moins 15 ans, et ils se trouvent dans du code qui était déjà assez ancien.
-- 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
Fabien LE LEZ
On Mon, 14 Jun 2004 15:41:23 +0200, "Mickael Pointier" :
c'est juste du verbiage inutile :) [...]
C'est verbeux, clairement, mais moi ca m'aurait été parfaitement :)
Faudrait savoir...
-- schtroumpf schtroumpf
On Mon, 14 Jun 2004 15:41:23 +0200, "Mickael Pointier"
<mpointier@edengames.moc>:
c'est juste du verbiage inutile :)
[...]
C'est verbeux, clairement, mais moi ca m'aurait été parfaitement :)
