Discussion :

[Gfx]

Rincevent76 : Justement, tu comprends de travers. On t'a dit que la sensibilité à la casse est là pour l'Unicode. Je te dis ensuite pourquoi l'Unicode est important. Parce qu'on ne vit pas tous entourés de gens qui nous ressemblent ! Et tu veux me faire croire que je te fournis cette réponse car je suis un mouvement ? Je travaille chez Sun sur le JDK avec des allemands, des canadiens, des indiens, des chinois, des japonais, des corréns, des suédois, des anglais, des russes, des tchèques, des français et même, parmi tout ça, des américains. Et ça, tous les jours. Crois-moi, j'ai eu l'occasion de constater la diversité des cultures chez les programmeurs et l'internationalisation de Java, à tous les niveaux, est quelque chose d'important pour nous. Tu peux continuer à te présenter comme l'hardi défenseur de valeurs originales mais tu ne trompes que toi.

Maintenant, explique-moi pourquoi ne pas utiliser les accents si tu utilises des mots français dans ton code ? Après tout tu le destines déjà à des lecteurs francophones. Alors pourquoi ne pas leur faciliter la lecture jusqu'au bout ? (Au passage, dans ib_est_autorise, tu dis deux fois que la variable est booléenne, c'est là la grande magie d'une langue qui peut te donner une idée sur la nature des choses que tu désignes avec ses mots)

[lunatix]

Bon, je viens de passer un certain temps (Beaucoup trop a mon gout) a moderer ce debat. En conséquence : certains messages sont modifiés, tronqués supprimés.

Je réouvre ce debat, mais au prochain derapage, c'est terminé. Merci de rester corrects, polis et cools.

Lunatix

[@ldehan]

de plus les 3 caractères je les tapes qu'une fois après c'est du copy/paste. et franchement toi qui me traitait de flemmard je pense, si c'est pas flemmard de pas pouvoir taper 3 lettres...

Ca ne me gêne pas de le faire pour un réel gain de productivité mais comme je te disais je n'en suis pas persuadé.

Je pose la question inverse :

Le préfixage, quel intéret ?

tu indiques 2 choses avec ta méthode de préfixage, le type et la portée.

• le type
  ton systeme marche pour les type de base, mais comment fait-tu pour les autres ? Je ne me vois pas appeler mes listes 'list_quelquechose' ou les map map_maclasse....
• concernant la portée, la réflexion est la même.
  d'accord pour tes variables de classe ou d'instance mais dans le cas de tes variables "locales" ca devient subjectif.
  la visibilité des variables se limite au bloc où elles sont déclarées, donc pour connaitre leur portée tu est obligé de revenir au début du bloc (et tu risques fortement alors de retombé sur la déclaration de la variable donc de connaitre son type )

et je ne pense pas être un sectaire qui défends son langage... j'ai fait beaucoup de delphi et je suis loin d'avoir été convaincu par l'insensitive bien au contraire.

[bidi]

Les langages info sont des langages formels. Donc identifier un élément de manière 'insensitive' demande beaucoup plus de travail et est beaucoup
moins naturel. un 'a' n'est pas un 'A'. En français peut-être est-ce le cas mais même en langage naturel il existe des mots qui s'écrivent de la même
façon parfois avec une majuscule, parfois sans et qui représentent des choses différentes (en allemand par exemple)...

De plus, cher rINcEveNt76 tu as la citique facile il me semble... tu trouve un tas d'"arguments" contre mais peux-tu nous donner des arguments pour l'insensibilité à la casse?

Bon voilà...
Perso j'en ai pas grd chose à f... mais j'avais envie de donner mon avis :-)

[Invité]

effectivement pour un premier post, tu fais fort.

Il serait intéressant de voter sur le case in/sensitive. A mon avis, une grande majorité ira au sensitive.
C'est pour ma part aussi le cas.
Pourquoi restreindre les possibilités d'écritures d' un programme. Bien que ceux-ci soient interprètés par des machines, nous n'en sommes pas encore là ! Pourquoi ne pas faire part de notre côté artistique, d'écrire du code lisible, et faire en sorte que calculateVAT ait une signification plus visuelle.
C'est déjà ce que les IDE font avec les couleurs ou la mise en page Tous les utilitaires de programation tentent d'éclaircir et de rendre un peu plus attrayant le simple fait de taper sur un bête clavier.

Le case sensitive en fait partie. Mais au moins c'est NOTRE responsabilité de le gérer.

[Deadpool]

Il faut que j'avoue quelque chose. Il m'arrive souvent de faire des déclarations de ce style surtout quand je code vite :

Code :

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

1
2
3
4
 
ArrayList arraylist;
Iterator iterator;
JPanel jpanel;

Donc voilà, moi j'ai besoin de la sensibilité à la casse.

[lunatix]

Code :

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

Iterator iterator;

celui-la, je le fais meme quand je code bien

[Pill_S]

Code :

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

Iterator iterator;

celui-la, je le fais meme quand je code bien

moi j'en ai tout plein des comme ça!

Code :

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

1
2
3
4
5
 
Statement statement;
String string;
Object object;
...

ça marche aussi pour les méthodes:

Code :

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

1
2
 
int age = personne.age();

Mais plus la portée de la variable est limitée, et plus j'ai tendance à raccourcir les identifiants: int i, String s, Object o, ...

[fabszn]

Hello,

Est ce que cette notion de case sensitive ne sera pas imposée par java pour permettre la surcharge de méthode comme dans l'exemple ci-dessous: :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
 
 
 
public class MaClasse {
 
 
    public void toto(){
 
    }
 
 
     public void Toto(){
 
    }
 
    public void toto(int toto){
 
    }
}

Cela permet d'avoir plusieurs méthodes ayant la même signature avec les paramètres différents. Sans le case sensitive serait bcp moins rigoureuse!
Dans mon exemple on sait que l'on parle bien de la meme methode (toto() ) mais avec un nb (ou un type )d'arguments différent.
Qu'en pensez vous?


ne taper pas trop fort!

[viena]

Hello,

Est ce que cette notion de case sensitive ne sera pas imposée par java pour permettre la surcharge de méthode comme dans l'exemple ci-dessous: :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
 
 
 
public class MaClasse {
 
 
    public void toto(){
 
    }
 
 
     public void Toto(){
 
    }
 
    public void toto(int toto){
 
    }
}

Cela permet d'avoir plusieurs méthodes ayant la même signature avec les paramètres différents. Sans le case sensitive serait bcp moins rigoureuse!
Dans mon exemple on sait que l'on parle bien de la meme methode (toto() ) mais avec un nb (ou un type )d'arguments différent.
Qu'en pensez vous?


ne taper pas trop fort!

Ah bah si, taper !
Sérieusement, je suis sure que la case sensitive n'est pas là pour cela. Ton exemple est totalement contre les conventions de nomage existantes et je pense que pour faire cela, il vaut mieux opter pour :
toto1 et toto2, meme si c'est pas beaucoup mieux.

[fabszn]

Hello,

Oki oki...

J'avoue que j'ai écrit cette exemple un peu vite, et je conviens que l'erreur est enorme concernant la déclaration de la deuxième méthode...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
public class MaClasse {
 
 
    public void toto(){
 
    }
 
 
     public void toTo(){
 
    }
 
    public void toto(int var1){
 
    }
}

En ayant apporté les corrections ci-dessus, je ne vois pas ou tu placerais toto1 et toto2?
Par contre je ne suis pas d'accord avec toi! Pour quelle raison la case Sensitive ne serait pas lié à cette problèmatique?
Cette possibilité de pouvoir avoir des methodes portant le même nom avec des parametres différents est reconnue sous java. Par ce biais on sait que l'on parle bien du même traitement mais avec un point de vu fonctionnel différent.
Le fait que le langage soit case sensitive rend vraiment rigoureux cet aspect.
Dans mon exemple la méthode toTo() est bien différente de la méthode toto().

Merci pour tes eclairements ..

[trolldom]

Salut,

J'ajoute mon grain de sel, juste pour dire que j'aimerai bien ne pas avoir à me soucier de la casse parce que en effet je suis fainéant.
Mait comme Descent l'a répéter ce n'ai pas logique que java soit pas sensible à la casse.
Donc la situation est (attention grafique

• un faineant (moi) peu sensible À la casse - un langage très sensible

La solution?: rajouter une couche d'indirection qui me permet d'être insensible à la case si je le désire:

• un faineant (moi) peu sensible À la casse - EDI - un langage très sensible

Et tout le monde est content
Mais Pour l'instant je survis et j'utilise des majuscules quand il faut
Dom

[mavina]

mouais, moi chuis chiant j'aime pas les references, mais j'aime bien java, alors faudrait me faire un truc spécial rien que pour moi ou ya pas de références... (ceci est un exemple fictif)
On s'en sort plus si on doit satisfaire les caprices de chacun

[Invité]

On a souligné précédemment que le case sensitive était source d'erreur...
Je ne suis pas tout a fait d'accord car beau nombre d'éditeurs sont pourvus d'autoComplete. Il suffit de savoir les utiliser. Sauf le petit malin qui s'amuse encore à coder sous note pad pour la frime.

2eme chose, si vous désirez des personalisations au niveau de java, je pense que la encore c'est au niveau des EDI qu'il faut jouer. Ceux-ci pourraient permettrent (ou plutôt interdire) des noms de variables similaires 'case-sensitivements'. Mais laissons la plus grande flexibilité au coeur de java. Si vous voulez des restrictions, faites-les ailleurs, a commencer par votre tête ...