Bonnes manières de rédiger du code ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

02/11/2006, 23h15
dj.motte

Bonjour,

Luc Hermitte écrit :

Citation:

Le C++ demande quantité d'autres règles plus ... axées sur la qualité du code, sur le fond en somme.

C' est évident.

Salut.
02/11/2006, 23h18
Matthieu Brucher

Citation:

Envoyé par koala01

Si les traducteurs ont commencé à compter à 0, ils ont sans doute suivi, à tord, cette habitude propre au C et au C++, et ont sans doute oublié que la regle 0 était en fait la premiere, et que donc, si la dernière avait le numéro 100, elle était en fait la 101eme ;)

Dans l'original, ils commencent à 0, ce n'est pas une erreur de traduction, faut pas oublier qui sont les auteurs. C'est un livre sur le C++, il s'agit d'une pointe d'humour qui, à mon sens, est tout à fait justifiée.
02/11/2006, 23h37
koala01

Citation:

Envoyé par Miles

Dans l'original, ils commencent à 0, ce n'est pas une erreur de traduction, faut pas oublier qui sont les auteurs. C'est un livre sur le C++, il s'agit d'une pointe d'humour qui, à mon sens, est tout à fait justifiée.

Ce n'est pas sur les auteurs originaux que je tire à boulet rouge...

Ils font "de l'humour" en numérotant les règles à partir de 0, mais restent cohérents (la dernière, numérotée 100 est la 101eme)...Soit...

Ceux sur qui je tire à boulet rouge, ce sont les traducteurs, dont on remarque qu'ils ne sont pas (suffisemment) attentifs à ce qu'il traduisent:

Ils s'arretent à la numérotation de la dernière cent (heu... sans) se rendre compte que la regle 0 est... la première, et qu'il y en a donc bien 101... et modifient le titre...Sans meme avoir pris la peine de réfléchir un tout petit peu...

C'est, typiquement, ce qui fait qu'il est si difficile de trouver une traduction correcte des (bonnes) publications de langue anglaise, et c'est vraiment malheureux...

Personnellement, je connais suffisement l'anglais pour arriver à lire un livre, mais, à l'instar de beaucoup, je préfèrerais, tant qu'à faire lire un livre dans ma langue maternelle...

Comme les (bons) auteurs francophones ne sont pas légion dans ce domaine, si on décide d'utiliser une traduction, on risque malheureusement d'avoir une "interprétation" de ce que le traducteur aura compris, et non, la traduction réelle de ce que l'auteur a écrit...
02/11/2006, 23h43
Luc Hermitte

Et de là à ce que le "one-o-one" (*) soit à interpréter comme les "bases à connaitre" ... (J'avais déjà croisé cette expression à quelques reprises)

(*) les cours commencent là bas par le 101 (premier cours première année) si j'ai bien suivi.
03/11/2006, 09h13
Médinoc

Bonjour,
Déjà, un reproche à l'auteur du guide du style, c'est sa position sur les tabulations.
[TROLL]Il est préférable[/TROLL] d'indenter avec les tabulations, car non seulement c'est moins ch***t à modifier, mais en plus, les tabulations sont réglables sur tout bon éditeur, permettant d'adapter aux préférences du codeur.
Par contre, il ne faut pas utiliser de tabulations à l'intérieur d'une ligne (pour faire de "jolis" alignements par exemple), pour les mêmes raisons.
Une fonction très utile peut être la "Convert leading spaces to tabs" de nombreux éditeurs de textes, notamment UltraEdit, fonction dont Visual Studio est bizarrement dépourvue.

Quant aux 101 règles, elles me rappellent ceci. ;)
03/11/2006, 10h19
Luc Hermitte
Perso je ne supporte pas le code indenté à la tabulation. En théorie, c'est bien ce que tu dis, mais en pratique ....
* Tout d'abord une tabulation doit toujours être de 8 en ce qui me concerne.
* Ensuite, même si tu n'utilises pas une tabulation après du texte sur une ligne, cette approche introduira automatiquement des décalages sur les textes alignés
Code:

1 2 3 for (...) // pour tous les toto { store(i); // stocke un copie du toto
Avec les indentations flottantes, tu oublies tout de suite un quelconque alignement.
* un code indenté à la tabulation ne peut pas être copié-collé pour les balises {code} des forums de developpez, il sera également illisible par mail/usenet, sur une page web, imprimé avec a2ps, ...
03/11/2006, 10h25
Médinoc

Citation:

Envoyé par Luc Hermitte

* un code indenté à la tabulation ne peut pas être copié-collé pour les balises {code} des forums de developpez,

Euh... Je fais ça tous les jours...
Naturellement, on n'a rien pour empêcher un affichage foireux avec des tabs de 8. Mais hop, un petit copié-collé vers ton éditeur préféré (même putty+vi) et ça marche...

Citation:

imprimé avec a2ps, ...

J'ai déjà fait ça aussi... Il y a même un paramètre disponible pour indiquer de combien doivent être les tabs (comme dans tout bon programme traitant du texte)...
03/11/2006, 10h54
boromir73

Citation:

Envoyé par Luc Hermitte

Tout d'abord une tabulation doit toujours être de 8 en ce qui me concerne

Curieusement, le même argument permet d'arriver à une conclusion opposée sur l'usage de la tabulation pour indenter :
Linux kernel coding style (Linus Torvalds)

Du livre cité précédemment je retiendrai :

Citation:

Envoyé par Herb Sutter and Andrei Alexandrescu

Issues that are really just personal taste and don't affect correctness or readability don't belong in a coding standard

Citation:

Envoyé par Herb Sutter and Andrei Alexandrescu

Don't specify how much to indent, but do indent to show structure: Use any number of spaces you like to indent, but be consistent within at least each file
03/11/2006, 11h34
Jean-Marc.Bourguet

Citation:

Envoyé par boromir73

Du livre cité précédemment je retiendrai :

Citation:

Envoyé par Herb Sutter and Andrei Alexandrescu

Issues that are really just personal taste and don't affect correctness or readability don't belong in a coding standard

Citation:

Envoyé par Herb Sutter and Andrei Alexandrescu

Don't specify how much to indent, but do indent to show structure: Use any number of spaces you like to indent, but be consistent within at least each file]

Donc on change toute l'indentation a chaque fois que quelqu'un édite le fichier, ruinant ainsi la possibilité de faire des diffs et de voir ce qui a réellement changé?

Dès qu'il y a plus d'une personne sur un projet, il faut spécifier ce genre de choses ou alors on arrive a des incohérences. Une alternative qui serait aussi gérable, ce serait d'avoir des outils qui réindenterait le code correctement... mais il y a toujours une part de manuel et des choix qui dépendent de la sémantique.
03/11/2006, 13h45
loufoque

Au contraire, avec les tabulations, tu peux choisir de les traiter comme des séquences de 4 ou 8 espaces sans changer le fichier.
La tabulation est une indentation sémantique, c'est bien plus pratique que les espaces qui ne sont que mise en forme.
03/11/2006, 14h09
Jean-Marc.Bourguet

Citation:

Envoyé par loufoque

Au contraire, avec les tabulations, tu peux choisir de les traiter comme des séquences de 4 ou 8 espaces sans changer le fichier.

En perdant de l'alignement...

En théorie, il y a moyen de s'en sortir en utilisant les tabulations pour l'indentation et des espaces pour l'alignement, et donc en utilisant parfois des tabulations suivies d'espaces mais le seul fichier que j'ai jamais vu supporter un changement de taille de tabulation sans perte de qualité du formatage (du moins, tant qu'on ne considère pas que la taille des lignes fait partie de cette qualité) est un que j'ai écrit pour vérifier que j'avais bien compris cette technique. Le pire étant probablement un fichier où trois tailles de tabulations différentes avaient été utilisées...
03/11/2006, 14h37
Médinoc

Citation:

Envoyé par Jean-Marc.Bourguet

En perdant de l'alignement...

Il faut savoir aussi ce qu'on aligne.
Le seul exemple de perte d'alignement que j'ai vu ici était dans une tentative de conserver un alignement sur des zones d'indentation différente. C'est normal que ça ne marche pas dans de telles circonstances...
03/11/2006, 15h10
Jean-Marc.Bourguet
Citation:

Envoyé par Médinoc

Il faut savoir aussi ce qu'on aligne.
Le seul exemple de perte d'alignement que j'ai vu ici était dans une tentative de conserver un alignement sur des zones d'indentation différente. C'est normal que ça ne marche pas dans de telles circonstances...
Code:

1 2 fonction(parametre1, parametre2);
Pour qu'un changement de taille de tabulation fonctionne correctement, il faut utiliser des tabulations sur la deuxième ligne jusqu'à être sous le f de fonction et ensuite des espaces. Il est quasiment impossible de faire ça automatiquement. C'est extrêmement rarement fait par ceux qui utilisent des tabulations, et je n'ai jamais vu de fichiers où c'était fait de manière constante.
03/11/2006, 16h15
Médinoc
Je résous ce problème de manière simple: Je ne mets qu'un seul espace :)
Code:

1 2 fonction(parametre1, parametre2);
Et souvent:
Code:

1 2 3 fonction(parametre1, parametre2 );
Voire même:
Code:

1 2 3 4 fonction( parametre1, parametre2 );
03/11/2006, 16h15
Matthieu Brucher

Mouais, pas très lisible, ça.

Et ça, c'est plus lisible sans doute?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
			{
				pResultEntity = new CSwResultEntity( row.GetIdMark(),
				                                     FIGURATIVE_HIT,
				                                     row.GetApplicationNumber(),
				                                     rowMarkType,
				                                     row.GetFilingDate(),
				                                     row.GetPriorityDate(),
				                                     prioclash,
				                                     class_match,
				                                     row.GetMarkName(),
				                                     row.GetIddeno(),
				                                     -1,
				                                     0,
				                                     0,
				                                     -1,
				                                     0,
				                                     -1,
				                                     -1,
				                                     m_verbalQuestion.GetIdQuestion(),
				                                     row.GetIdPicture(),
				                                     row.GetClasses(),
				                                     row.GetVersionNice(),
				                                     row.GetOdMarkNR(), 
				                                     row.GetLgstMark(),
				                                     row.GetRegistrationNumber());
			}

Bonne chance pour retrouver le niveau d'indentation avec un truc pareil...
(Surtout qu'avant que j'ajoute les accolades, il y avait juste un if devant...)

Avec une indentation moins barbare, on se repère tout de suite plus facilement, sauf peut-être si on utilise des tabs de 2...

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
			{
				pResultEntity = new CSwResultEntity(
				 row.GetIdMark(),
				 FIGURATIVE_HIT,
				 row.GetApplicationNumber(),
				 rowMarkType,
				 row.GetFilingDate(),
				 row.GetPriorityDate(),
				 prioclash,
				 class_match,
				 row.GetMarkName(),
				 row.GetIddeno(),
				 -1,
				 0,
				 0,
				 -1,
				 0,
				 -1,
				 -1,
				 m_verbalQuestion.GetIdQuestion(),
				 row.GetIdPicture(),
				 row.GetClasses(),
				 row.GetVersionNice(),
				 row.GetOdMarkNR(), 
				 row.GetLgstMark(),
				 row.GetRegistrationNumber()
				 );
			}

03/11/2006, 16h35
spidermario

Citation:

Envoyé par Jean-Marc.Bourguet

Attention quand on mets plusieurs variables sur une ligne:

Code:

int* p, i;

définit un pointeur et un int.

Faux,

Code:

int* a,b;

définit deux pointeurs, c'est

Code:

int *a,b;

qui définit un pointeur et un int.
03/11/2006, 16h42
Eusebe

Citation:

Envoyé par spidermario

Faux,

Code:

int* a,b;

définit deux pointeurs, c'est

Code:

int *a,b;

qui définit un pointeur et un int.

:lol:
Tu as vérifié avant de dire une bêtise, spidermario ?

Je me permets de contester cette énormité scientifiquement.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
einstein:/users/anc0306/fbenoit/C$>cat testPtr.c
int main(void)
{
int* a,b;

int *pa = a;
int *pb = b;
int bb = b;
return 0;
}

einstein:/users/anc0306/fbenoit/C$>gcc -Wall -Wextra -Wwrite-strings -O2 -c testPtr.c
testPtr.c: In function `main':
testPtr.c:6: attention : initialisation transforme un entier en pointeur sans transtypage
testPtr.c:5: attention : variable inutilis?e << pa >>
testPtr.c:6: attention : variable inutilis?e << pb >>
testPtr.c:7: attention : variable inutilis?e << bb >>

einstein:/users/anc0306/fbenoit/C$>mv testPtr.c TestPtr.cpp

einstein:/users/anc0306/fbenoit/C$>gcc -Wall -Wextra -Wwrite-strings -O2 -c TestPtr.cpp
TestPtr.cpp: In function `int main()':
TestPtr.cpp:6: erreur: conversion invalide de << int >> vers << int* >>
TestPtr.cpp:5: attention : variable << pa >> inutilis?e
TestPtr.cpp:6: attention : variable << pb >> inutilis?e
TestPtr.cpp:7: attention : variable << bb >> inutilis?e

En C comme en C++, b est un entier.
(Désolé pour le gcc en Français, c'est un des serveurs de mon université, je n'ai pas compris pourquoi ils nous ont servi une VF...)

Edit: Merci, j'ai mis un export LC_MESSAGES=C dans mon .profile et ça marche à merveille :)

03/11/2006, 16h50
spidermario

Dans ce cas, mon livre de C++ comporte une erreur :roll:

Enfin, si tu le dis... :D

Edit : je viens de revérifier dans mon livre et je ne retrouve même plus où j'avais vu ça :oops:

Je me demande bien ce qui m'était passé par la tête lorsque j'ai posté tout-à-l'heure :roll:

Voir 40 message(s) de cette discussion en une page

Fuseau horaire GMT +2. Il est actuellement 00h51.