Reprise du message précédent :
accessoirement, un code lisible n'emploiera pas de noms kilométriques
perso mes variables ne dépassent jamais les 15 caractères

le not logique n'est ni plus ni moins qu'un not binaire sur un booléen, donc c'est bien le même oppérateur. Pour moi c'est pas dérangeant du tout.

Ouais ben quand dans un même programme tu gères le nombre de dents de ton hamster et la coleur des sous-vêtements de la secrétaire, bah c'est assez chaud de pas utiliser des noms long pour faire la différence entre la couleur du pellage du chien et le nombre de cafés que t'as pris depuis ce matin

 
C'est pas dérangeant pour un langage qui fait bien la distinction des types En C comme en VB tu peux affecter un Int dans un Boolean. Mais en C, comme on fait la difference entre les operateurs binaires et les operateurs booléens, les formules écrites sont plus faciles à comprendre. En VB, tu dois vraiment faire gaffe au type des variables que tu manipules sinon tu fais des erreurs comme celle indiquée sur les checkbox.
 
C'est pour ça que je n'aime pas les langages faiblement typés, pratiquement n'importe quelle opération sur les types de base est valide et donc le langage ne fait pratiquement aucune vérification. Il ne manquerait plus qu'il soit possible de faire 3+"4" et qu'on obtienne 7

bin non
j'utilise un dictionnaire de données pour raccourcir les mots ou expressions en trigrammes, combiné à la notation hongroise et ça roule
bon pour les noms de fonctions on fait encore un peu ce qu'on veut

fait moi un trigramme hogrois à la sauce orientale de "nombreDeDentsDuHamster"
 
Et je te défends de me répondre :
 
Hamster.Dents.Count

De toute façon, la notation hongroise ça pue le paté
 
Si vous voulez, j'ai un lien sur lequel ils fustigent cette même notation sur un ton humoristique
 
Allez hop : http://mindprod.com/unmain.html Section naming, point 29 et 30

sauce orientale?
 
lHamDenNbr
 
et voilà
 
tout est codé comme ça chez nous et il faut un peu l'habitude avant que ça devienne super lisible. Il faut au passage préciser que le dico de données est le même pour toutes les applis, mais ça reste du même domaine: les assurances.
 
Pour info, on ne change que rarement le type d'une variable (on réfléchit avant ) et toute valeur numérique entière est déclarée Long plutôt qu'Integer ou Byte, donc toujours le même préfixe (l'exception étant les indexes d'arrays de contrôles ou autres paramètres à un event)

Ah ouais, je comprends mieu l'article qu'à cité Kristoph :
 

franchement le mec c'est mauvaise foi inside, obfuscation mon cul

 
Donc c'est de l'obfuscation pour les gens exterieurs au projet. Je te rappelle que l'article est écrit du point de vue du gars qui va maintenir ton code plus tard.
 

Lit l'article entier
 
M'enfin je trouve cette notation géniale, surtout quand on mélange les langues, qu'on fait des inversions, et qu'on change de façon d'écrire...
 
Avec des noms entiers, certes c'est plus chiant à lire, mais y'a pas de surprise.

bin le mec qui va venir maintenir mon code, il va d'abord se farcir toute la doc technique, les standards de développement et le dictionnaire de données. Le dernier qui a subi ce lavage de cerveau traitement entrait dans le code comme dans du beurre en deux semaines.
 
edit: au fait, toute la db subit ce même genre de traitements avec trigrammes

 
       
 
 
 
 
 
 
 
J'ai bien fait de poster ce lien moi.

drasche > le souci, c'est que parfois, quand c'est une appli de prod qui se met à planter d'un coup sans raison alors qu'elle marche bien depuis 2 ans (ça peut bêtement être un int pour un indice qui ne suffit plus quelquepart), si ça bloque l'activité du client, il va pas attendre les 2 semaines que tu lises la doc.
Il va plutôt te dire "dans les 4 heures je veux un patch, sinon je vous fait payer des pénalités de 50 000$ par heure de retard"
 
Bah dans ce cas, la doc elle est bien où elle est, et t'as intérêt à ce que le code soit lisible et facilement appréhendable en plus d'être normé.
 
PS: et je sais de quoi je parle, ça m'arrive régulièrement ce genre de couilles. Et mine de rien, j'ai remarqué que plus le code est kosovar et plus il est maintenable. Chiant à lire, mais clair. Les abréviations dans les variable, y'a rien qui m'énerve plus, surtout quand le gars qui les a pondu à un anglais approximatif et qu'il jongle avec du français...
 
CODPAY, sur certaines pages c'est un code pays, et sur d'autres it's a payment code Je ne parle pas non plus des fautes. Quand on a le mot entier, on comprends mieu que lorsqu'il y a une faute d'orthographe dans une abréviation
 
Bah tu t'amuses bien, surtout quand tu es censé désactiver le paiment par carte bleu pour l'angleterre (truc que j'ai eu à faire sur un site web en urgence le mois dernier)
 
Alors que des variables de merde "codeDuPaysDuClient" ben certes, c'est plus long à lire, et plus lourd, mais ça a au moins l'avantage de ne pas pouvoir être confondu avec autrechose.
 
Du coup, je suis assez partisan non pas des noms à ralonge, mais au moins avec un ou deux mots entiers dans le nom de ma variable, histoire qu'on sâche à coup sûr ce que c'est.
 
Sinon, lorsque la modèle de la BDD est terminé, je réutilise au maximum de noms des champs, et ça a plusieurs avantages :
-> Le même nom pour traîter la même info d'un bout à l'autre de l'appli
-> Si on veux connaître son sens et son type, il suffit de consulter le MPD, ce qui est généralement bien plus lisible qu'un dictionnaire des données de 60 pages.

ça dépend, l'application étant en perpétuelle évolution, il y a toujours quelqu'un sur le projet qui le connaît à fond