OVH Cloud OVH Cloud

Accolades : conventions d'ecriture

113 réponses
Avatar
Fabien LE LEZ
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...

3 réponses

8 9 10 11 12
Avatar
Jean-Noël Mégoz
"Jean-Marc Bourguet" a écrit dans le message de
news:
"Mickael Pointier" writes:

Si tu veux utiliser les fins de ligne comme marque de fin
d'instruction, il faut penser alors a un mecanisme qui permet de
mettre une instruction sur plusieurs lignes. Je vois trois
possibilites:
- a la fin de la ligne comme le preprocesseur C
- en tete de ligne comme FORTRAN
- heuristique plus ou moins savante (utilisant l'indentation,
utilisant le fait qu'il y a des parentheses ouvertes, utilisant
le dernier caractere de la ligne qui indique que quelque chose suit).
[...]
Il est possible qu'on puisse trouver une heuristique a la fois
explicable simplement, pas trop contraignante et ne genant pas la
lisibilite mais je considere que, jusqu'a preuve du contraire,
l'utilisation d'une marque de fin d'instruction (ou a la rigueur d'un
separateur d'instruction) est meilleur que les alternatives.



Sans compter que la lisibilité reste quand même un critère hautement
subjectif...
Ceci dit, il y a bcp moins de cas où l'on doit écrire sur plusieurs lignes
que de cas où on le fait sur une seule. Le choix d'un marqueur de
continuation de ligne serait donc plus "économique" en terme de saisie, que
la systématisation de la fin d'instruction par ";" ou autre.

Ce qui m'épate, moi, c'est tous ces commentaires sur les "c'est bien" /
"c'est pas bien" des différents langages... Tous les langages, quels qu'ils
soient, ont des avantages (c'est pour ça qu'ils existent) et des
inconvénients (c'est pour ça qu'il y en a d'autres). Personnellement, je ne
me pose pas toutes ces questions. La syntaxe exige un ";" en fin
d'instruction ? Je le mets et basta.
Après, chacun à le droit d'avoir des préférences. Mais à mon avis, c'est au
niveau des possibilités techniques qu'il faut porter son attention, pas au
niveau de la syntaxe ! J'ai eu un prof l'an dernier qui ne jure que par
Dylan, ZE langage d'après lui, sauf qu'il est le seul à m'en avoir parlé...
Ça ne doit donc pas être la panacée qu'il décrit...

Et si *vraiment* rien ne vous va, créez-donc votre propre langage.
Promis, on ne vous demandera pas avec quoi vous avez écrit votre compilateur
! ;)

J.No.,
informaticien pragmatique.

Avatar
Jean-Marc Bourguet
"Jean-Noël Mégoz" writes:

"Jean-Marc Bourguet" a écrit dans le message de
news:
"Mickael Pointier" writes:

Si tu veux utiliser les fins de ligne comme marque de fin
d'instruction, il faut penser alors a un mecanisme qui permet de
mettre une instruction sur plusieurs lignes. Je vois trois
possibilites:
- a la fin de la ligne comme le preprocesseur C
- en tete de ligne comme FORTRAN
- heuristique plus ou moins savante (utilisant l'indentation,
utilisant le fait qu'il y a des parentheses ouvertes, utilisant
le dernier caractere de la ligne qui indique que quelque chose suit).
[...]
Il est possible qu'on puisse trouver une heuristique a la fois
explicable simplement, pas trop contraignante et ne genant pas la
lisibilite mais je considere que, jusqu'a preuve du contraire,
l'utilisation d'une marque de fin d'instruction (ou a la rigueur d'un
separateur d'instruction) est meilleur que les alternatives.



Sans compter que la lisibilité reste quand même un critère hautement
subjectif...


Va sortir ca a des typographes et on en reparle apres.

Ceci dit, il y a bcp moins de cas où l'on doit écrire sur plusieurs
lignes que de cas où on le fait sur une seule. Le choix d'un
marqueur de continuation de ligne serait donc plus "économique" en
terme de saisie, que la systématisation de la fin d'instruction par
";" ou autre.


Je ne suis pas a un caractere pres.

Ce qui m'épate, moi, c'est tous ces commentaires sur les "c'est
bien" / "c'est pas bien" des différents langages... Tous les
langages, quels qu'ils soient, ont des avantages (c'est pour ça
qu'ils existent) et des inconvénients (c'est pour ça qu'il y en a
d'autres).


Quel rapport (mon point de vue sur les guerres de langages est que si
on n'est pas capable de faire partie de maniere sensee de chacun des
camps, on ne connait pas assez les langages en question pour
commenter) ?

On est clairement dans une optique ou on discutte de differentes
manieres de concevoir un point particulier d'un langage (et ce point
est les marqueurs de fin d'instructions vs les separateurs
d'instructions vs une instruction sur une ligne avec les differents
moyens de placer une instruction sur plusieurs lignes quand il n'y a
pas de marqueurs de fin d'instruction/separateurs d'instructions;
tiens j'ai oublie le cas ou toutes les instructions commencent par un
mot cle unique dans mon semblant d'analyse). Un autre point a
considerer dans cette discussion est la capacite a detecter des
erreurs et a repartir apres une erreur.

Personnellement, je ne me pose pas toutes ces questions. La syntaxe
exige un ";" en fin d'instruction ? Je le mets et basta. Après,
chacun à le droit d'avoir des préférences. Mais à mon avis, c'est au
niveau des possibilités techniques qu'il faut porter son attention,
pas au niveau de la syntaxe !


Un langage est un tout et la syntaxe peut etre une contrainte ou une
source de souplesse (voir les differentes variantes de lisps et
comparer a Dylan par exemple pour comprendre ce que je veux dire).

J'ai eu un prof l'an dernier qui ne jure que par Dylan, ZE langage
d'après lui, sauf qu'il est le seul à m'en avoir parlé... Ça ne
doit donc pas être la panacée qu'il décrit...


http://www.gwydiondylan.org/books/dpg/index.html

Et si *vraiment* rien ne vous va,


Rien ne me va effectivement. Mais ce n'est pas ca qui m'empeche de
dormir.

créez-donc votre propre langage.


Les jours n'ont que 24h mais c'est un de mes projets pour apres ma
retraite :-) En attendant j'essaie de rassembler des idees. Mon
probleme principal pour le moment est tres pragmatique, comment le
faire fonctionner avec les en-tetes C du systeme (y compris les
macros) tout en gardant des principes assez differents entre autres
sur la recherche des noms.

Promis, on ne vous demandera pas avec quoi vous avez écrit votre
compilateur ! ;)


Pas besoin: compilateur pour un sous-ensemble ecrit dans le langage
lui-meme et compile a la main puis boostrap. Classique quoi.
(Surtout que si je m'amusais a cela le langage cible serait
vraissemblablement le C donc la compilation a la main ne poserait pas
trop de probleme).

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


Avatar
James Kanze
"Mickael Pointier" writes:

|> >> En fait mon style c'est celui du GFA Basic adapté au C :)

|> > Du Basic ! Non ! Pas ça ! Pas du Basic !

|> > Au moins, soyons cool. Le Basic, c'est comme régarder les films
|> > porno. Tout le monde en fait, mais personne ne l'avoue. Le Basic,
|> > c'est le Canal+, une heure du mat', de l'informatique.

|> Meu non, le GFA il ne lui manque que les structures pour être
|> niquel.

Et il existe aujourd'hui des Basics avec même des classes, je crois.

Il me semblait évident que je plaisantais. Quand même !

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

|> > N'exagérons pas. Même le Modula-2 avait des ';'. Et je ne sais pas
|> > comment se passer des parenthèses dans des expressions comme (i+j)*5.

|> Les ";" n'ont d'intérêt que si tu autorises plusieurs instructions
|> par ligne, non ?

Ou plusieurs lignes par instruction.

Ils introduisent aussi une certaine rédondance qui facilite la détection
des erreurs.

|> Donc à part pour faire un concours d'obfuscation, moi ca ne me sert
|> à rien vu que je ne met pas plusieurs instructions par ligne.

|> Quand au parenthèsage, je ne parlait pas de le supprimer, je parlais
|> juste de la parenthèse externe qui englobe l'expression:

|> if (((i+j)*5)<23)

|> ca pourrait très bien s'écrire comme ca:

|> if ((i+j)*5)<23

Il faut bien savoir où termine l'expression conditionnelle, et où
commence la reste. En C++, ce sont des parenthèses supplémentaires. En
d'autres langages, le mot clé « then ». Je suppose que d'autres
alternatives sont également possible.

Personnellement, j'aime bien « then ». Mais j'ai toujours préféré
Modula-2 à C, aussi.

|> je n'ai pas l'impression qu'on perde en lisibilité.

|> > Comme en Modula-2, en Modula-3 et en Ada :

|> > if someCondition() then
|> > doTruc( 42 ) ;
|> > else
|> > doUnAutreTruc() ;
|> > end if

|> > En Modula-2 ou Modula-3, les ';' sont facultatifs en cet exemple.
|> > (Mais je crois qu'ils sont obligatoire en Ada.)

|> > Il y a des arguments des deux côtés. J'aime bien cette syntaxe
|> > aussi, mais jusqu'ici, je ne connais pas de langage qui l'utilise
|> > ET qui permet la declaration des variables à n'importe quel
|> > endroit du code (chose que j'aime aussi).

|> Je ne vois pas d'obstacle technique à ca.

Je ne sais pas. Je n'ai jamais analysé quel en serait les conséquences.
Mais ça représenterait un changement important dans cette famille de
langages.

--
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
8 9 10 11 12