Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Nom de tableau au pluriel ?

41 réponses
Avatar
Fabien LE LEZ
Bonjour,

Si j'ai un tableau, du style

int largeur_colonne[]= { 23, 21, 52, 13 };

vaut-il mieux l'appeler :
"largeurs_colonnes" (car c'est un tableau de plusieurs valeurs)
ou "largeur_colonne" (car, à l'utilisation, largeur_colonne[i] est
_la_ i-ème valeur) ?

Je sais bien que c'est assez subjectif, mais la question me turlupine
depuis longtemps, donc j'aimerais bien avoir vos avis ;-)

Merci d'avance...

--
;-)

10 réponses

1 2 3 4 5
Avatar
Alain Naigeon
a écrit dans le message news:

"Michel Michaud" wrote in message
news:<VQocc.17000$...
Dans news:, Franck
"Michel Michaud" écrivait:
Curieusement, il y a quelques jours, j'ai eu une discussion avec
mes élèves, où je leur expliquais que mettre les noms de vecteurs
au pluriel était plus simple que l'emploi d'un préfixe


Pour quelle mesure de la complexité ?


Humaine. Ma mère comprend que « clients » signifie plusieurs clients.
Elle ne comprend rien à tabClients :-)


Mais ta mère n'est pas informaticienne, ou ?

En fait, s'il s'agit simplement d'une collection de clients, sans plus,
j'utiliserais « clients » aussi. Mais en général, ces collections ont
une structure, et un minimum de connaissances de cette structure en sont
nécessaire à l'utilisation. Du coup, j'ai tendance à utiliser un nom qui
indique cette structure : « tableClients », « listeClients » (accès
séquentiel), « ensembleClients », etc.



C'est pas un défaut d'abstraction, ça ? Si tu hésites au début,
tu peux avoir à changer une liste en tableau, ou l'inverse, et
alors, tu vas changer le nom partout ? Je trouve que clients,
ou LesClients, ou DesClients, etc, ça évoque un container sans
préjuger de sa structure, ce qui pour moi un avantage et non
un inconvénient.



--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - - Strasbourg, France




Avatar
Fabien LE LEZ
On 6 Apr 2004 04:50:54 -0700, wrote:

Ce qui me paraît bien drôle, dire d'en
choisir plusieurs parmi les client_order.


On écrit bien "un de ces CD-ROM", ou "un de ces Durand"...

--
;-)

Avatar
kanze
"Michel Michaud" wrote in message
news:<cZzcc.19026$...
Dans news:,
En fait, s'il s'agit simplement d'une collection de clients, sans
plus, j'utiliserais « clients » aussi. Mais en général, ces
collections ont une structure, et un minimum de connaissances de
cette structure en sont nécessaire à l'utilisation. Du coup, j'ai
tendance à utiliser un nom qui indique cette structure : «
tableClients », « listeClients » (accès séquentiel), «
ensembleClients », etc.


Eh bien ! Tu me surprends. Un pas de plus et tu entres tout à fait
dans la notation hongroise ! Un préfixe pour indiquer le type, ce
n'est pas un peu anti-OO ? ;-)


Ce n'est pas pour indiquer le type, en tant que tel, mais pour bien
indiquer ce que c'est, ce qu'on peut en faire. Un « ListOfCustomers »
supporte d'autres opérations qu'un « SetOfCustomers » ; ce n'est pas la
même bête.

Mais surtout, c'est une question de contexte. Ce n'est pas une règle, si
c'est un std::list, le nom commencera par ListOf. C'est plutôt que le
nom doit être signifiant. Si « Customers » suffit, si c'est juste une
collection, sans autres opérations, j'utilise « Customers ». S'il ne
suffit pas, s'il y a d'autres opérations qui pourrait être importantes,
j'utilise quelque chose de plus précis. Les règles absolues concernent
le format des noms. Il y a une règle qui exige que les noms soient
parlant, et sémantiquement clairs, mais je ne sais pas formuler d'une
façon plus précise ce que signifie « sémantiquement clair ».

Grosso modo, si un type s'appelle « Customers », à peu près tout ce que
tu sais, c'est que tu peux itérer sur les éléments. S'il s'appelle
«@SetOfCustomers », tu sais que l'ordre n'est pas signifiant, et n'est
pas défini, tandis que « ListOfCustomers » a un ordre défini par des
évenements externes (l'ordre d'insertion, etc.). Et « CustomerTable »
permet l'accès indicé. J'utilise le nom le plus simple donc quand je
veux reduire les garanties au minimum. Note la différence entre la
fonction GB_CommandLine::filenameArguments (qui renvoie en fait une
référence à un std::vector< std::string >, mais tout ce que je garantis,
c'est que ce soit un « reversible container ». (En fait, c'est un peu
plus flou que ça, pour des raisons historiques.) Tandis que j'ai
GB_FieldArray, dont l'interface garantit toutes les opérations d'un
tableau non-modifiable (en fait, std::vector aujourd'hui).

Aussi, que ce soit préfixe ou suffixe dépend de l'utilisation habituelle
en anglais. C'est donc FieldArray, mais si les champs n'étaient pas
ordonné, ce serait SetOfFields. Ce n'est pas logique, mais c'est comme
ça en anglais ; c'est donc comme ça dans mes symboles.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


Avatar
kanze
"Alain Naigeon" wrote in message
news:<407328a5$0$502$...
a écrit dans le message news:

"Michel Michaud" wrote in message
news:<VQocc.17000$...
Dans news:, Franck
"Michel Michaud" écrivait:
Curieusement, il y a quelques jours, j'ai eu une discussion
avec mes élèves, où je leur expliquais que mettre les noms de
vecteurs au pluriel était plus simple que l'emploi d'un préfixe


Pour quelle mesure de la complexité ?


Humaine. Ma mère comprend que « clients » signifie plusieurs
clients. Elle ne comprend rien à tabClients :-)


Mais ta mère n'est pas informaticienne, ou ?

En fait, s'il s'agit simplement d'une collection de clients, sans
plus, j'utiliserais « clients » aussi. Mais en général, ces
collections ont une structure, et un minimum de connaissances de
cette structure en sont nécessaire à l'utilisation. Du coup, j'ai
tendance à utiliser un nom qui indique cette structure : «
tableClients », « listeClients » (accès séquentiel), «
ensembleClients », etc.


C'est pas un défaut d'abstraction, ça ? Si tu hésites au début, tu
peux avoir à changer une liste en tableau, ou l'inverse, et alors, tu
vas changer le nom partout ?


Il vaut mieux, parce que tu as changé l'interface, et il faut de toute
façon vérifier tout le code utilisateur. Le type de collection a une
importance sémantique et contractuelle, et tu ne peux pas le changer
comme ça.

Mais voir ma réponse à Michel. Avec les catégories de la STL, Il arrive
que je ne garantis que « container » ou « reversible container », même
si c'est en fait un typedef à std::vector. Dans ce cas-là, c'est
simplement « Clients ». Si l'absense de l'ordre est significatif, ou
pourrait l'être, c'est « SetOfClients » ; sans doute lors que je me
serais complètement converti à la STL, « SetOfClients » garantirait
plutôt un ordre sur un critère interne, de même que « ListOfClients »
garantit un ordre sur des critères externes (ordre d'insertion, etc.),
et « ClientArray » garantit supporte pour l'accès aléatoire.

L'importance dans le nom, ici, ce n'est pas l'implémentation, mais ce
que je garantis. Le contrat. Appeler quelque chose « ClientArray »
garantit contractuellement un accès aléatoire ; je n'ai plus le droit de
revenir en arrière par la suite. Appeler quelque chose simplement
« Clients » ne garantit que « begin() » et « end() » ; si rien d'autre
n'est dit, il ne garantit que un « ForwardIterator » (mais souvent, je
garantit en fait un itérateur bi-directionnel, ainsi que front() et
back(), explicitement, parce que je ne connais pas de bonne façon à
spécifier ces garanties dans le nom du type).

Je trouve que clients, ou LesClients, ou DesClients, etc, ça évoque un
container sans préjuger de sa structure, ce qui pour moi un avantage
et non un inconvénient.


C'est un avantage, si les utilisateurs n'ont pas besoin de plus. C'est
un désavantage autrement:-).

Il n'y a pas de règle absolue. J'ai des cas où je garantis l'accès
aléatoire, voire même l'interface complète de std::vector (sans la
contigüité -- j'ai écrit GB_FieldArray avant la modification de la norme
qui la garantit). J'ai d'autres cas où tout ce que je garantis est un
« container » ou un « reversible container » (plus ou moins, parce que
beaucoup de ces classes prédatent la STL, au moins dans leurs formes
initiales, et les garanties n'ont pas été pensées en termes de la STL).

Le nom doit refléter le contrat.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34





Avatar
kanze
"Michel Michaud" wrote in message
news:<XSocc.17004$...
Dans news:40715508$0$12802$, Arnaud
Je suis partisan du pluriel.


Bien. On se sent moins seul :-)

En revanche, je n'aime guère les préfixes qui, je trouve,
alourdissent plus qu'ils n'aident la lecture du code.


On s'y habitue... Mais ils doivent légers. Par contre, je crois bien
que je ne m'habituerai jamais au _ terminal préféré par certains (int
donnee_;)...


Surtout qu'il y a certaines polices, ou certains contextes, où le _
apparaît comme un espace. À l'intérieur d'un symbole, on peut en général
le déviner, ne serait-ce que parce que le programme serait illégal
autrement, mais à la fin.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


Avatar
Jean-Noël Mégoz
"Fabien LE LEZ" a écrit dans le message de
news:
Perso, je l'utilise quand la valeur d'une variable membre est passée
comme argument du constructeur :

class Machin
{
private:
int temperature;
public:
Machin (int temperature_) : temperature (temperature_) {}
};

En gros, ça me sert d'"identifiant temporaire", et comme je n'utilise
le _ final que pour ça, je sais qu'il n'y aura pas de conflit avec une
éventuelle autre variable "temperature_"...

T'aurais pas fait du prolog dans ta jeunesse, toi ?

"_" sert justement à identifier une variable muette, qu'on situe dans une
liste d'arguments mais dont ignore délibérément la valeur...

À propos de cet "underscore", on peut aussi lancer un autre débat qui, à ma
connaissance, a opposé essentiellement les programmeurs sur PC et sur Mac :
le composition des noms.
Préférez-vous "list_of_clients" ou "listOfClients" ?

Le choix de l'anglais ou du français aussi peut se poser (ok, pour "client",
c'est vite vu). Dans un TP de synthèse d'image, j'ai eu à nommer un ensemble
contenant les sommets d'objets 3D.
Choisir le français pouvait mener à des horreurs comme "setOfSommets". Mais
le tout français n'est guère mieux : "ensembleDeSommets" est terriblement
long à taper (bonjour les fautes de frappe).
Du côté du tout anglais, il n'est pas toujours évident de connaître le mot
en anglais pour tout ce qu'on manipule dans son programme, et encore plus
avec certains pluriels irréguliers. Ici, il faut savoir que "sommet" se dit
"vertex". Mais que "setOfVertex" n'est pas bon puisque son pluriel est
"vertices"...
J'avoue ne pas avoir poussé le vice jusqu'à envisager "EnsembleDeVertices".
Au final, j'ai opté pour la solution redondante mais si pratique :
pluriel+préfixe, en l'appelant "sVertices".

Je sais, c'est bcp parler pour ne rien dire. Mais bon, j'avais envie de
m'épancher moi aussi, et pas à la télé si possible ! ;)
J.No.

Avatar
Fabien LE LEZ
On Wed, 7 Apr 2004 17:20:19 +0200, "Jean-Noël Mégoz"
wrote:

T'aurais pas fait du prolog dans ta jeunesse, toi ?


Non.

À propos de cet "underscore", on peut aussi lancer un autre débat qui, à ma
connaissance, a opposé essentiellement les programmeurs sur PC et sur Mac :
le composition des noms.
Préférez-vous "list_of_clients" ou "listOfClients" ?


list_of_clients pour une variable ; ListOfClients() pour une fonction.
L'écriture "listOfClients" est plutôt commune en Java, non ?

[En passant, j'écrirais plutôt "clients_list"...]

--
;-)

Avatar
Loïc Joly
Fabien LE LEZ wrote:

On Wed, 7 Apr 2004 17:20:19 +0200, "Jean-Noël Mégoz"
wrote:

À propos de cet "underscore", on peut aussi lancer un autre débat qui, à ma
connaissance, a opposé essentiellement les programmeurs sur PC et sur Mac :
le composition des noms.
Préférez-vous "list_of_clients" ou "listOfClients" ?



list_of_clients pour une variable ; ListOfClients() pour une fonction.
L'écriture "listOfClients" est plutôt commune en Java, non ?


Moi, j'écrit plutôt listOfClients pour une variable ou une fonction (et
j'ai vu ça sur du code pré-java), ListOfClients pour un type. Et j'ai vu
écrit tout dans tous les sens...

Le fait que le standard utilise des _ ne me gêne pas. Après tout, même
dans le standard, ce n'est pas toujours cohérent... Un petit quizz :
Lequel est le bon :
c_out cout
o_stream ostream
w_string::c_str wstring::cstr
output_iterator_tag outputiteratortag
basic_string<T>::get_line basicstring<T>::getline
lowerbound lower_bound


--
Loïc


Avatar
kanze
"Jean-Noël Mégoz" wrote in message
news:<40741ac1$0$20167$...
"Fabien LE LEZ" a écrit dans le message de
news:
Perso, je l'utilise quand la valeur d'une variable membre est passée
comme argument du constructeur :

class Machin
{
private:
int temperature;
public:
Machin (int temperature_) : temperature (temperature_) {}
};

En gros, ça me sert d'"identifiant temporaire", et comme je
n'utilise le _ final que pour ça, je sais qu'il n'y aura pas de
conflit avec une éventuelle autre variable "temperature_"...


T'aurais pas fait du prolog dans ta jeunesse, toi ? "_" sert justement
à identifier une variable muette, qu'on situe dans une liste
d'arguments mais dont ignore délibérément la valeur...

À propos de cet "underscore", on peut aussi lancer un autre débat qui,
à ma connaissance, a opposé essentiellement les programmeurs sur PC et
sur Mac : le composition des noms.
Préférez-vous "list_of_clients" ou "listOfClients" ?


Celui qu'utilise le client:-).

Sérieusement, j'aurais eu une légère préférence pour list_of_clients.
Sauf que j'ai beaucoup travaillé dans la téléphonie. Et là, la CCITT
utilisait toujours listOfClients dans ces normes. Du coup, dans ce
milieu, c'est prèsque toujours listOfClients que j'ai été amené à
utiliser, jusqu'au point que c'est la forme qui me semble plus naturelle.

Il y a aussi ceux qui écrirait listofclients, voire lstclients. À éviter
(AMHA, évidemment).

Le choix de l'anglais ou du français aussi peut se poser (ok, pour
"client", c'est vite vu).


L'anglais a l'avantage de ne pas avoir besoin d'accents:-). Le français,
en revanche, pose moins de risque de conflit avec des mots-clés ou des
fonctions de la bibliothèque standard -- je me rappelle que quand je me
suis converti en C++, j'avais une ou deux variables avec le nom
« class » ; si je les avais appelé « classe », je n'aurais pas eu de
problème (mais si elles s'appelaient « productClass », etc., il n'y
aurait pas eu de problème non plus).

Dans un TP de synthèse d'image, j'ai eu à nommer un ensemble contenant
les sommets d'objets 3D. Choisir le français pouvait mener à des
horreurs comme "setOfSommets". Mais le tout français n'est guère
mieux : "ensembleDeSommets" est terriblement long à taper (bonjour les
fautes de frappe).


Tu veux dire que ton éditeur ne fait pas ça pour toi ? Je tappe
habituellement les deux ou trois premiers lettres, puis ^P ou ^N pour
avoir le nom complet.

En revanche, parler des ensembles pour std::set revient à utiliser deux
mots différents pour la même chose. Quand j'étais à la Dresdner Bank,
ils avaient opté pour la solution : termes techniques en anglais, termes
de métier en allemand. Pour la simple raison que la plupart des termes
techniques, on les lisait dans la documentation Java, en anglais, tandis
que les termes de metier, on les avait des discussions avec les gens du
metier et des documentation interne, tous les deux en allemand. Et qu'on
avait la flegme de chercher des bonnes traductions, et dans un cas, et
dans l'autre.

Dans ton cas, ça donnerait setOfSommets. Ou setDeSommets -- en fait, la
règle était plus facile à appliquer en allemand, ou on se sert des mots
composés, sans des prépositions (ce qui est en général aussi acceptable
en anglais, bien que ça resonne un peu gauche).

Du côté du tout anglais, il n'est pas toujours évident de connaître le
mot en anglais pour tout ce qu'on manipule dans son programme, et
encore plus avec certains pluriels irréguliers. Ici, il faut savoir
que "sommet" se dit "vertex". Mais que "setOfVertex" n'est pas bon
puisque son pluriel est "vertices"...


Attention : l'anglais est une langue vivante. « The American Heritage
Dictionary » donne et vertices et vertexes. Étant assez vieux, je me
servirais de vertices, mais je ne suis pas sûr que ce soit la règle
parmi des informaticiens d'aujourd'hui:-).

J'avoue ne pas avoir poussé le vice jusqu'à envisager
"EnsembleDeVertices". Au final, j'ai opté pour la solution redondante
mais si pratique : pluriel+préfixe, en l'appelant "sVertices".


Que c'est laid. Si tu veux utiliser l'anglais, « setOfVertices », voire
« vertexSet ».

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


Avatar
kanze
Fabien LE LEZ wrote in message
news:...
On Wed, 7 Apr 2004 17:20:19 +0200, "Jean-Noël Mégoz"
wrote:

T'aurais pas fait du prolog dans ta jeunesse, toi ?


Non.

À propos de cet "underscore", on peut aussi lancer un autre débat qui, à ma
connaissance, a opposé essentiellement les programmeurs sur PC et sur Mac :
le composition des noms.
Préférez-vous "list_of_clients" ou "listOfClients" ?


list_of_clients pour une variable ; ListOfClients() pour une fonction.
L'écriture "listOfClients" est plutôt commune en Java, non ?


Non. C'est la forme courante dans la téléphonie. Dans d'autres milieux,
je crois que ce n'est pas rare non plus -- les Javaistes l'ont bien pris
de quelque part.

[En passant, j'écrirais plutôt "clients_list"...]


Pas en anglais, en tout cas. En anglais, les adjectives sont
invariables. Y compris quand il sont des noms. Ça serait donc
client_list.

En fait, on ne peut rendre pluriel que l'objet dont on parle (ici, la
liste). Et on le fait toujours sur le mot à la fin. Donc, « mother in
laws » (et non « mothers in law », ce qui serait plus logique, mais qui
est un archaïcisme), pour les belles-mères.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


1 2 3 4 5