Reprise du message précédent :
ni plus lisible... i, on sait tous ce que c'est.

ok alors, je redis la meme chose avec "warningMessageIfNotExisting" au lieu de "s", ptain

En fait, faut définir ce qu'on veut dire par "plus court". "plus court" = "moins de caractères", c'est clairement pas bon, perl le prouve tous les jours. Par contre "plus court" = "moins de token" est une valeur beaucoup plus intéressante de "plus court".
 
Quand au "nommage explicite", il n'est pas toujours plus intéressant, suffit de voir certains messages Objective-C, pour être explicites ils sont explicites mais franchement... par exemple pour récupérer un substring, en Python:

my_str[start:end]

en Objective-C

[myStr substringWithRange:NSMakeRange(start, len)]

Y'a surement pas de règle générale. Si ta méthode porte un nom qui décrit ce qu'elle fait, t'as pas besoin de la commenter. De toute façon t'es censé commenter ce qui est obscur ou inhabituel, ça evite les setDate // Set the Date.

Pour ma part je n'utilise le this que quand c'est nécessaire; je préfère passer une variable "id" à stocker dans un champ "id" que commencer à nommer différemment mes variables. C'est nettement plus facile en maintenance.

Ouais en fait je voulais plutot parler de l'appel de methode

(en java) pour l'accès direct aux attributs de l'objet oui, pour l'appel de méthodes jamais (vu qu'il n'y a quasiment aucune ambiguïté possible, la seule qui peut arriver c'est si on fait des imports statiques)

Oui mais parfois au lieu d'avoir i, j, k ou x, y, z si on a iCol et iRow c'est plus parlant meme si plus long...

Ca sert à quoi le "i" dans "iCol"?

ben pour différencier de jCol bien sûr

Que c'est un int...
Ou que c'est une variable d'itération au choix...

Putain mais le pire c'est qu'ils l'avaient écrit dans la spec du langage
 

C'est une blague?

Quoi on a plus le droit d'avoir de convention de nommage ?
 
Ca evite de confondre l'index de la colonne et l'objet qui la represente (par exemple...)

Non mais vas te noyer franchement

Si, mais si elles pouvaient ne pas être stupides et sans intérêt ça serait un plus

Explique moi en quoi ça sert a rien ?
 
C'est pas mieux qu'aucune convention... J'suis sur que si on met un _ pour une variable privé tu t'insurges aussi...

Ou et quand?

Parce que si tu veux être clair tu mets "cellIndex":

• C'est clairement un index
• À l'autocomplétion, cell et cellIndex se retrouvent au même endroit, plus simple à utiliser
• Ca ressemble à quelque chose
• Ca augmente réellement la clarté du truc

Je ne vois pas l'intérêt en java (entre autres parce que mes membres d'instances ne sont à peu près jamais publics) mais c'est loin d'être aussi stupide que l'autre (ce qui ne veut pas dire que c'est une idée que je cautionne).

Pareil, mais c'est le seul endroit où j'utilise this. Après, le seul usage de this, ce serait éventuellement pour d'obscurs algorithmes de gestion de pools d'objets, le genre de trucs qu'on n'écrit pas tous les jours.

En gros, on pourrait résumer à: ce qui a un sens fonctionnel dans ton appli, il faut lui mettre un nom clair. Ce qui est purement de la tambouille technique, plus c'est court, mieux ça vaut.

oops, sorry.
 
jamais dans ce cas...

Hungarian notation and scope identification are not allowed.

Je serais pas aussi radical pour la partie technique, mais ça me parait censé oui.

T'a essayé de refoutre ta  classe recompilé directement dans le jar (avec winRar par exemple) , technique porcasse mais je sais que nous on le faisait parfois pour des fichiers de config quand on voulait pas se retaper tout un build ...

le nommage, ça devient relou dans les parties spécifiques, genre quad tu écris un automate à la main, certains états son hyper tordu comme description (genre "j'ai bouffé tel truc mais je sais pas encore si je vais avoir machin ou bidule", et l'état d'après j''ai bouffé le truc, mais j'ai backtracké sur machin don j'attends bidule" ).  
Mais en dehors de ces cas souvent liés à des algos complexes (transformation de graphes par ex.), c'est quand même assez lisible.

 
Ton link c'est clairement de la merde :

 
Tout le monde en C++/Java ecrit comme le NO!, meme les generateur de code NetBeans ...
 
Je ne vois pas en quoi prefixer le type "broke" l'abstraction objet puisque c'est un attribut privé et pas une propriété publique (qui elle bien sur a jamais de prefixe).
 
Si c'est prefixé tu sais de suite où et quand convertir le type, si t'ecris pas n'importe quoi en affectant un string a un int, etc...
Meme si les gros IDE comme NetBeans font la meme chose en coloration syntaxe c'est clairement pas moins lisible...

Parce que sans ça t'es pas foutu de le savoir  

Franchement?
 
Si

moi je trouve pas, j'économise un max de lignes et je lis l'indentation, et pas les accolades.
 
Mais j'ai un formateur automatique.

Quand t'as des classe a 100-120 attribut, au bout d'un moment oui y'a des doutes... Surtout quand y'a 500-600 classes...

Quand t'as des classe a 100-120 attribut c'est que t'as un probleme de conception ...

Quand bien même (et ce n'est meme pas sur, car au final meme si t'as moins d'attribut par classe tu augmente le nombre de classe donc c'est tjrs aussi dur de tout connaitre par coeur), une fois que c'est fait, c'est là ça existe.
 
Après t'es peut etre pas consicient dans certains domaine des informations necessaires...

Kamoulox ?

perso, quand ça devient nombreux, je passe par d'autres formes de stockage, soit en généralisant un peu sous forme de map (ou enum à l'heure actuelle) soit en découpant les infos en paquets "par ordre d'idée". Mais l'idée c'est d'éviter d'avoir des trop grands fichiers. (ceux qui ont vu mon code : chuuut, faite ce que je dis, pas ce que je fait )

Le "si" c'était pour les préfixes, pas pour les accolades (j'utilise le premier style pas le second pour les accolades, et je lis également l'indentation)

Quand t'as des classes avec 100-120 attributs, tu devrais te poser des questions à laquelle les réponses ne contiennent sûrement pas "tiens j'vais ajouter des préfixes"

Ou alors tu n'es pas conscient de ce qu'est un design correct.

T'as peut etre jamais bossé sur un produit qui evolue et qui a un passif de plus de 0 jours...

Ou peut-être que mes collègues sont plus capables que les tiens, malgré toutes leurs fautes et tous leurs problèmes

Pour rappel les prefixes ne concernent que les types... C'est juste plus pratique...

 
Je dois maintenir une appli qui tourne sur la JVM 1.3. C'est une grosse bouse. Et bien meme la dedans, y a pas toutes les conneries que tu debites a longueure de post.

longueur