Discussion :

[Alfred12]

Le pire que j'ai rencontré : A, B et C. En variables globale dans un code de 30 000 lignes.

[timoth]

Mon collègue est un gigantesque fan du "toto", "totobis", "tototer"

[isozv]

Tiens je pensais que la nomenclature de Leszinsky-Reddick était devenue enfin un norme après plus de 20 ans...

[GrandFather]

Tiens je pensais que la nomenclature de Leszinsky-Reddick était devenue enfin un norme après plus de 20 ans...

Si les langages de développement et l'ingénierie logicielle étaient restés figés depuis le début des années 90, ça aurait pu être le cas, oui...

[souviron34]

Si les langages de développement et l'ingénierie logicielle étaient restés figés depuis le début des années 90, ça aurait pu être le cas, oui...

Sans même parler d'évolution, juste un bilan de ce que ça donne...

Leszynski naming convention

Disadvantages

Since the Leszynski naming convention is a special form of Hungarian notation the same general disadvantages also apply to the Leszynski convention.

• Changes in database design may require wholesale renaming. For example, replacing a table with a query would involve either retaining the tbl name for the query, or going through the entire database replacing the tbl name with a qry name.
• When transferring the database to a different DBMS, problems will arise if the target DBMS does not support CamelCase names.
• As every object of the same type starts with the same letter, it is not possible to navigate through the objects in a List box by typing the beginning letter.

Hungarian notation

Disadvantages

Most arguments against Hungarian notation are against System Hungarian notation, not Applications Hungarian notation. Some potential issues are:

• The Hungarian notation is redundant when type-checking is done by the compiler. Compilers for languages providing type-checking ensure the usage of a variable is consistent with its type automatically; checks by eye are redundant and subject to human error.
• All modern integrated development environments display variable types on demand, and automatically flag operations which use incompatible types, making the notation largely obsolete.
• Hungarian Notation becomes confusing when it is used to represent several properties, as in a_crszkvc30LastNameCol: a constant reference argument, holding the contents of a database column LastName of type varchar(30) which is part of the table's primary key.
• It may lead to inconsistency when code is modified or ported. If a variable's type is changed, either the decoration on the name of the variable will be inconsistent with the new type, or the variable's name must be changed. A particularly well known example is the standard WPARAM type, and the accompanying wParam formal parameter in many Windows system function declarations. The 'w' stands for 'word', where 'word' is the native word size of the platform's hardware architecture. It was originally a 16 bit type on 16-bit word architectures, but was changed to a 32-bit on 32-bit word architectures, or 64-bit type on 64-bit word architectures in later versions of the operating system while retaining its original name (its true underlying type is UINT_PTR, that is, an unsigned integer large enough to hold a pointer). The semantic impedance, and hence programmer confusion and inconsistency from platform-to-platform, is on the assumption that 'w' stands for 16-bit in those different environments.
• Most of the time, knowing the use of a variable implies knowing its type. Furthermore, if the usage of a variable is not known, it cannot be deduced from its type.
• Hungarian notation strongly reduces the benefits of using feature-rich code editors that support completion on variable names, for the programmer has to input the whole type specifier first.
• It makes code less readable, by obfuscating the purpose of the variable with needless type and scoping prefixes.

Personellement, je trouve que le nom a_crszkvc30LastNameCol est bien pire que toto ou A ...

[sboyer]

Dans le genre affreux, j'ai vu aujourd'hui même ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

var $this = $(this).parent();

[denispir]

Je pense que l'article part d'une bonne intention, mais qu'il manque le but, notamment avec ses exemples. Un identifiant doit indique le sens du symbole --comme il dit sans avoir à chercher la définition. Point.

1. Cas de data : J'utilise couramment 'datum' (ou 'element' qui n'en dit pas plus) en programmation générique. Par exemple les cellules d'une liste chaînée peuvent contenir n'importe quoi. Donc, un terme générique comme 'datum' dénote précisément le sens correct.
('value' serait faux car ce ne sont pas nécessairement des valeurs)

2. Cas de numérotation : J'utilise souvent pos1 pos2 comme bornes d'intervalle (fermé) dans une chaîne. Il y a 2 bornes dont l'une (1) vient avant l'autre (2) : le nommage est donc parlant et correct.
(pour de vraies séquences, j'utilise i,j ; mais une chaîne n'héberge pas une séquence d'éléments --ici caractères-- sauf pour de l'ASCII de base)

Voilà, denis

[bulbo]

Juste une petite réaction la dessus:

avec toutefois quelques exceptions acceptables, comme i, j, k, ... pour les indices de boucle

L'inconvénient d'un i en variable de boucle, c'est qu'il devient impossible en cas de maintenance/debug de faire une recherche sur le nom de la variable .. enfin si on peut, mais des i, tu vas en trouver un paquet.

Moi j'utilise index, et en cas de boucle imbriquée je préfixe les index pour les spécifier un peu et savoir sur quoi c'est un index.

Mes 2 cents

Bulbo

[Bluedeep]

l'article part d'une bonne intention

Comment dit on déjà ? le chemin de l'enfer est pavé de bonnes intentions

[GrandFather]

L'inconvénient d'un i en variable de boucle, c'est qu'il devient impossible en cas de maintenance/debug de faire une recherche sur le nom de la variable .. enfin si on peut, mais des i, tu vas en trouver un paquet.

En principe la portée de i est limitée à la boucle dont cette variable est l'indice, je ne vois pas trop de scénarios de debug pour lesquels il serait nécessaire de la rechercher (si tu as isolé la boucle comme source du problème, tu tombes forcément sur i, si tu ne l'as pas identifiée, tu n'as pas de raison de la rechercher)...

Par contre, tu as raison sur un point, utiliser i comme nom d'une variable avec une portée plus importance que celle d'un bloc et/ou d'une boucle, est une très mauvaise idée.

[liljack]

Pour ma part, j'ai vu "value" et "valueplus" :-)

[nouknouk]

int kangourou = 1000;
sleep(kangourou);

[Bluedeep]

L'inconvénient d'un i en variable de boucle, c'est qu'il devient impossible en cas de maintenance/debug de faire une recherche sur le nom de la variable .. enfin si on peut, mais des i, tu vas en trouver un paquet.

Je ne vois pas bien le rapport avec le debug et par ailleurs quel éditeur n'est pas capable de faire une rechercher limitée à un bloc ????

Moi j'utilise index, et en cas de boucle imbriquée je préfixe les index pour les spécifier un peu et savoir sur quoi c'est un index.

J'ai vraiment du mal à te suivre : en quoi rechercher une variable du nom de index est pus commode que de rechercher une variable du nom de i ? (à moins d'utiliser l'ancien edlin du DOS à la rigueur ).

[bulbo]

Tu n'as pas forcément un éditeur évolué sous la main .. et index aura au moins le mérite de correspondre beaucoup plus à ta variable que i que tu retrouveras dans le moindre mot clé if en ne parlant que de ça .. sans parler que dans du code, index se détache mieux qu'un simple i, facilité de relecture etc..

Et je suis tellement mariole qu'à l'époque j'avais pioché ça dans un document assez sérieux parlant justement des conventions d'écritures a adopter pour éviter des problèmes triviaux.

Pour revenir sur la phrase que j'avais initialement cité: i, j et k pour des variables de boucles...

Recherche évoluée ou pas, il est plus facile par exemple de repérer une utilisation de userIndex au lieu de groupIndex comparé à i à la place de j.

[shenron666]

un peu de linq ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
var query4 = from pcgmpgmvpc in query3
                         select new { pcgmpgmvpc.Value };

j'ai tronqué la requête, complète elle fait une dizaine de lignes

[souviron34]

Recherche évoluée ou pas, il est plus facile par exemple de repérer une utilisation de userIndex au lieu de groupIndex comparé à i à la place de j.

mouais...

Si tu traites une matrice, une moyenne, une variance, en général en maths les notations sont bien i,j,k..

Pourquoi alors changer les notations plutôt que celles communément acceptées (et comprises quand on compare à un papier) ??

[Bluedeep]

Tu n'as pas forcément un éditeur évolué sous la main ..

Mouais ....

En général on travaille sur un poste de travail, pas sur un smartphone, non ?

[props]

Le pire du pire que j'aie vu, un collègue explique à un stagiaire comment coder sa fonction : "tu déclares une variable toto, tu fais ta boucle etc...".
Le stagiaire l'a pris au mot.
Une semaine plus tard, mon collègue relit le code et... compte les toto1, toto2, toto3... jusqu'à 73 !!!

[bulbo]

Mouais ....

En général on travaille sur un poste de travail, pas sur un smartphone, non ?

Hier encore j'ai ouvert une classe avec VI pour jeter vite fait un oeil à ce qui se passait dans un bout de code qui posait problème.
Il n'y a que ça de dispo sur la machine unix ou on compile...

Pour souviron34: on ne debug pas une feuille de papier avec une équation mathématique dessus, quand tu dois trouver pourquoi une double boucle ne tourne pas rond avec des index i et j .. vous faites ce que vous voulez mais moi je préfère des noms de variables un poil plus long et lisible.

Bulbo

[el_slapper]

J'ai vu quelques horreurs, mais au final, je laisse la parole à mon père, qui a 2 exemples particulièrement délicats(des années 80, le problème n'est pas nouveau) :

-des noms de variables en slovaque(alors que la boite est allemande)
-"pomme_de_terre", "kilo_de_pommes_de_terre", "carotte"; dans un programme comptable.