Discussion :

[mavina]

coucou,

Pour conclure, je vais citer un de mes anciens profs d'algo :

De toutes façons, il existe une loi universelle dans la programmation qui s'appelle "Loi de Conservation des Emmerdements (LCE)" qui dit que quel que soit le langage choisi, les merdes que tu n'as pas dans l'un, tu les auras dans l'autre, et vice versa

.
Je vous laisse méditer sur ca, ca me rappelle que ce prof était vraiment terrible

mavina

[Rincevent76]

Décidément il me semble que personne ne fait vraiment la différence entre les conventions et le fait d'être case sensitive c'est fou quand même.

Comme java est case sensitive , les classes et méthodes du JDK "te donne" la convention de nommage, donc naturellement, avec le temps tu le fais aussi.

c'est pas "Comme Java est case sensitive" j'utilise un language case insensitive, il est accompagné d'un framework officiel où par ex toutes les constantes sont écrites en Majuscules, donc naturellement avec le temps tu le fais aussi, rien à voir avec le case sensitive.
Sauf que l'avantage de mon language case insensitive c'est que le jour où je vais essayer de créer une variable du même nom qu'une constante il ne me laissera pas faire, je ne risque donc pas d'avoir 2 variables / constantes de meme nom (NBRCLIENTS et nbrclients) donc forcément il y a moins de risques de confusion et d'utilisation de la mauvaise variable que dans le cas d'un language case sensitive qui te permets cette abérration qui n'est en rien nécessaire.




ohnerom => j'ai bien dit que je ne parle pas de comparaisons entre chaines de caractères mais de noms de variables / fonctions... ( voir mes msg précédents )

[mavina]

Sauf que l'avantage de mon language case insensitive c'est que le jour où je vais essayer de créer une variable du même nom qu'une constante il ne me laissera pas faire, je ne risque donc pas d'avoir 2 variables / constantes de meme nom (NBRCLIENTS et nbrclients) donc forcément il y a moins de risques de confusion et d'utilisation de la mauvaise variable que dans le cas d'un language case sensitive qui te permets cette abérration qui n'est en rien nécessaire.

Il est utile de préciser que dans ton langage case insensitive tu peux acceder à une variable nommée NBRCLIENTS en accedant a nbrclient, ce qui est déroutant et source de confusion à mes yeux, le cerveau humain a une mémoire visuelle, il voit une variable définie en majuscule il la retient comme telle. Pour débugger ton programme tu vas t'ammuser si tu change toujours les majuscules/minuscules de tes variables en te disant

De toutes facons jmen fous, c'est autorisé et toc

, et c'est encore pire si c'est quelqu'un d'autre qui doit reprendre ton code...

j'ai bien dit que je ne parle pas de comparaisons entre chaines de caractères mais de noms de variables / fonctions... ( voir mes msg précédents )

Et tu crois que ton compilateur il fait quoi ?
bien à toi

mavina

[viena]

Décidément il me semble que personne ne fait vraiment la différence entre les conventions et le fait d'être case sensitive c'est fou quand même.

Si tout le monde à part toi y voit un lien, c'est peut être qu'il y en a un

[Rincevent76]

Il est utile de préciser que dans ton langage case insensitive tu peux acceder à une variable nommée NBRCLIENTS en accedant a nbrclient, ce qui est déroutant et source de confusion à mes yeux, le cerveau humain a une mémoire visuelle, il voit une variable définie en majuscule il la retient comme telle. Pour débugger ton programme tu vas t'ammuser si tu change toujours les majuscules/minuscules de tes variables en te disant
, et c'est encore pire si c'est quelqu'un d'autre qui doit reprendre ton code...

Euh... vous lisez pas ce que j'écrit ?

JE NE POURRAIS PAS CREER 2 VARIABLES AVEC LE MEME NOM.

donc aucune possibilité de confusion....

[ohnerom]

Décidément il me semble que personne ne fait vraiment la différence entre les conventions et le fait d'être case sensitive c'est fou quand même.


c'est pas "Comme Java est case sensitive" j'utilise un language case insensitive, il est accompagné d'un framework officiel où par ex toutes les constantes sont écrites en Majuscules, donc naturellement avec le temps tu le fais aussi, rien à voir avec le case sensitive.
Sauf que l'avantage de mon language case insensitive c'est que le jour où je vais essayer de créer une variable du même nom qu'une constante il ne me laissera pas faire, je ne risque donc pas d'avoir 2 variables / constantes de meme nom (NBRCLIENTS et nbrclients) donc forcément il y a moins de risques de confusion et d'utilisation de la mauvaise variable que dans le cas d'un language case sensitive qui te permets cette abérration qui n'est en rien nécessaire.




ohnerom => j'ai bien dit que je ne parle pas de comparaisons entre chaines de caractères mais de noms de variables / fonctions... ( voir mes msg précédents )

Ben oui. , j'ai bien compris ton argumentation,mais a force d'utiliser le JDK , tu peux pas confondre de constante , elle n'existe pas en minuscule, donc par la suite , dans tes classes tu auras l'habitude d'utiliser.
Tu différencies tout ce que tu peux faire dans tes classes et je te parle des classes du JDK, tu peux pas confondre avec minuscule/ majuscule puisqu'une solution.

POur terminer, oui c'est different ,case sensitive et convention de nommage. mais c'est lié aussi puisque le JDK est selon cette convention, le comp. etant case sensitive , tu es obligé d'utlisé ces conventions de facon strict . Donc par la suite, avec le temps, il y a des chances que tu adhères a ces conventions de facon naturel.

Oui , j'ai aussi compris ce que tu compares, mais le compilateur ( et le runtime en java ) , il faut bien qu'il compare les methodes , variables avec qqc , si c'est pas case sensive, ben c'est plus compliqué.

[Deadpool]

Rincevent76, bien que tu ais rejeté l'argument d'adiGuba c'est pourtant le plus pertinent selon moi.

Est-tu au courant que Java utilise l'unicode? Oui je suppose.

Il l'utilise dans les chaînes bien sur mais il est également possible d'utiliser l'unicode dans les noms des variables. Si si je t'assure même s'il est plutôt conseillé d'utiliser les caractère ASCII.

Par exemple rien ne t'empêche de déclarer une variable nommé tête,
Écrire, ou même N'IMPORTE QUEL caractère étant une lettre dans n'importe quelle langue. Tu vois le tableau, je ne sais pas si tu as idée du nombre de caractère étant des lettres dans l'unicode mais ça fait un bon paquet.

Maintenant essaie de me dire comment tu fais pour définir un mode case insensitive sur tous ces caractères (je ne sais pas combien il y en a en tout, disons 30 000 au bas mot).

J'espère que tu comprendras pourquoi Java est case sensitive.

[Deadpool]

Rincevent76 repartons sur de bonnes bases, que pense-tu de mon argument?

Rincevent76, bien que tu ais rejeté l'argument d'adiGuba c'est pourtant le plus pertinent selon moi.

Est-tu au courant que Java utilise l'unicode? Oui je suppose.

Il l'utilise dans les chaînes bien sur mais il est également possible d'utiliser l'unicode dans les noms des variables. Si si je t'assure même s'il est plutôt conseillé d'utiliser les caractère ASCII.

Par exemple rien ne t'empêche de déclarer une variable nommé tête,
Écrire, ou même N'IMPORTE QUEL caractère étant une lettre dans n'importe quelle langue. Tu vois le tableau, je ne sais pas si tu as idée du nombre de caractère étant des lettres dans l'unicode mais ça fait un bon paquet.

Maintenant essaie de me dire comment tu fais pour définir un mode case insensitive sur tous ces caractères (je ne sais pas combien il y en a en tout, disons 30 000 au bas mot).

J'espère que tu comprendras pourquoi Java est case sensitive.

[piro]

Ben pour moi la réponse de Descent me parait tout à fait logique et répondant parfaitement à la question, apres chacun en pense ce qu'il veut.
Pourquoi en Angleterre on roule à gauche et en France à droite, ca aussi c'est une question interessante...

[Rincevent76]

Rincevent76, bien que tu ais rejeté l'argument d'adiGuba c'est pourtant le plus pertinent selon moi.

Est-tu au courant que Java utilise l'unicode? Oui je suppose.

Il l'utilise dans les chaînes bien sur mais il est également possible d'utiliser l'unicode dans les noms des variables. Si si je t'assure même s'il est plutôt conseillé d'utiliser les caractère ASCII.

Par exemple rien ne t'empêche de déclarer une variable nommé tête,
Écrire, ou même N'IMPORTE QUEL caractère étant une lettre dans n'importe quelle langue. Tu vois le tableau, je ne sais pas si tu as idée du nombre de caractère étant des lettres dans l'unicode mais ça fait un bon paquet.

Maintenant essaie de me dire comment tu fais pour définir un mode case insensitive sur tous ces caractères (je ne sais pas combien il y en a en tout, disons 30 000 au bas mot).

J'espère que tu comprendras pourquoi Java est case sensitive.

je pourrais accepter cet argument si dans tous les tutorials sur Java on ne disait pas "Vous pouvez utiliser les caractères accentués mais c'est déconseillé." (nottament dans le pdf dévelloper en Java pris sur ce site si je ne m'abuse qui dit p. 781 "il faut éviter d'utiliser des caractères accentués qui ne sont pas toujours utilisables par tous les systèmes d'exploitation" )
si c'est déconseillé pourquoi le permettre ?

pourquoi vouloir utiliser 300.000 carcatères là ou 26 lettres + 10 chiffres et un underscore suffisent toujours ?

[Gfx]

pourquoi vouloir utiliser 300.000 carcatères là ou 26 lettres + 10 chiffres et un underscore suffisent toujours ?

Pourquoi forcer le reste du monde à utiliser 36 signes quand on peut très facilement proposer une grande partie des alphabets utilisés dans le monde ? Peux-tu me donner une bonne raison pour imposer cela ? Je râle quand je tombe sur un logiciel qui ne gère pas les accents (car oui, des logiciels anglophones non prévus pour interpréter ne serait-ce que l'ASCII étendu c'est encore assez courant), devrais-je donc forcer les utilisateurs du chinois ou de l'arabe à se plier à MA culture ?

[@ldehan]

Je suis d'accord avec le coup de la pollution de code, si tu sais programmer, la déclaration de variable te suffit à connaître sa portée. Ca reste de la flemme plus qu'autre chose, de vouloir avoir cette info à chaque fois que tu utilises la variable.

C'est sûr si tu préfère devoir remonter à la déclaration de chaque variable chaque fois que tu veux connaitre sa portée et son type tu peux le faire, tu peux aussi taper ton code avec seulement le petit doigt ou programmer en assembleur des applis Windows, ça dépends si tu veux être performant et efficace ou bien te la péter genre "moi j'suis un vrai un dur, je sais programmer, MOI et j'ai pas la flemme de faire des recherches dans mon code pour trouver le type d'une variable, par contre j'ai la flemme de la préfixer de 2 lettres, c'est de la pollltion de code"

bien sûr que je préfère remonter à la déclaration de la variable plutôt que de polluer le nom de la variable avec de s méta-information sur elle-même. C'est de la pure redondance d'information ce qui est par définition inutile...

de plus, n'importe quel environnement correct te permet facilement soit de remonter a la déclaration soit d'afficher le type ce qui du coup est beaucoup plus perfomant et efficace

j'ai bien dit que je ne parle pas de comparaisons entre chaines de caractères mais de noms de variables / fonctions... ( voir mes msg précédents )

Et tu crois que ton compilateur il fait quoi ?

c'est exactement dans ce sens que je l'entendais.


Ce qui m'etonnes c'est que de toute façon tu auras tendance à ecrire tes variables toujours de la même façon même si le compilateur ne t'y forcait pas donc je ne comprends pas en quoi ca peut représenter une contrainte.

Je suis d'accord que le pendant de ceci c'est de pouvoir déclarer dans le même bloc Aze, aze, aZe, ... mais ce serait complétement idiot ! c'est vrai que le langage le permet mais personne ne le fait. A l'inverse, un langage insensitif permet d'utiliser la meme variable sous les noms cités précédement mais personnes ne le fait non plus... on en revient à des conventions qui relèvent tout simplement du bon sens.

[Rincevent76]

dans tous les tutorials sur Java on ne disait pas "Vous pouvez utiliser les caractères accentués mais c'est déconseillé." (nottament dans le pdf dévelloper en Java pris sur ce site si je ne m'abuse qui dit p. 781 "il faut éviter d'utiliser des caractères accentués qui ne sont pas toujours utilisables par tous les systèmes d'exploitation" )
si c'est déconseillé pourquoi le permettre ?

P.S. oui j'a une très bonne raison, l'informatique a des origines Anglos saxonnes qui ont un language de 26 lettres sans acent et j'ai jamais vu de clavier avec 30.000 symboles dessus comme un clavier chinois.

L'alphabet latin est plus performant et productif qu'un "alphabet" de signes comme ont les chinois. (plus facile à apprendre et à écrire / taper sur un matériel possible à fabriquer (ex un clavier 102 touches))

[Rincevent76]

bien sûr que je préfère remonter à la déclaration de la variable plutôt que de polluer le nom de la variable avec de s méta-information sur elle-même. C'est de la pure redondance d'information ce qui est par définition inutile...

Tu apprendras pourtant que le redondance d'information est parfois très utile , pour économiser du temps de calcul de prix par exemple il est commun de les calculer et les stocker en DB même si pourtant l'info est déductible d'autres infos, calculable et donc redondante.

pareil pour les noms de variable, oui c'est redondant mais ça permets de gagner du temps, si tu préfère scroller ou appeller une fonction de ton IDE pendant que moi au simple nom de variable lu j'ai déjà les infos c'est que tu as une drôle d'idée de la productivité.

[Gfx]

On le permet pour les raisons que je viens de citer : une diversité culturelle qui demande une liberté plus importante au niveau des jeux de caractères. On le déconseille car il y a peu de chances qu'un code source rédigé en hébreu soit affichable sur la machine d'un développeur vivant aux États-Unis.

Néanmoins, comme toute approche déconseillée elle est valable si tu sais exactement pourquoi tu le fais. Par exemple si tu peux garantir que ton code source ne sera utilisé que par des français, pourquoi ne pas utiliser les accents ? Après tout il y a de grandes chances que cela soit le cas dans les commentaires, donc pourquoi pas dans le code ?

Doit-on interdire cette possibilité ? Non, il n'y a aucune raison pour cela. Doit-on le permettre ? Oui, cent fois oui mais en demandant de procéder avec précaution, car cela peut poser des problèmes.

Le cas général doit être facile à mettre en place (ASCII 7bits) et le cas particulier (Unicode) doit être possible.

[mavina]

allez, je m'autocite une derniere fois, moi mavina :

Pour conclure, je vais citer un de mes anciens profs d'algo :
Citation:
M. Roussel a écrit :
De toutes façons, il existe une loi universelle dans la programmation qui s'appelle "Loi de Conservation des Emmerdements (LCE)" qui dit que quel que soit le langage choisi, les merdes que tu n'as pas dans l'un, tu les auras dans l'autre, et vice versa

.
Je vous laisse méditer sur ca, ca me rappelle que ce prof était vraiment terrible

on défend pas notre langage a tous prix, la loi de conservation des emmerdements est là et bien là, un emmerdement que tu trouves dans java, à savoir pour toi le case sensitive n'est pas là dans un autre langage, mais un emmerdement que tu trouves en C/C++ (risques d'acces memoire dangereux), tu ne le trouve pas en java... C'est comme ça...

Pour les accents, tu l'as dit toi même, quand on n'en a pas besoin, on ne les utilise pas. Ce n'est pas un element (mot que tu as réussi à lire sans accent ) nécessaire à la compréhension du mot, contrairement au ñ en espagnol par exemple : peña est différent de pena
bien à toi

mavina

[ohnerom]

Il me semble qu'il y a eu une réponse technique à ta quetsion, soit tu y réponds avec des arguments techniques , tentative avec les 25 + 10 caractères , mais la aussi une réponse, soit je sais pas, continue à ne pas apprécier le case sentitive de java et voilà. Aucun argument te conviendrait.

A plus, ailleurs

[Gfx]

pareil pour les noms de variable, oui c'est redondant mais ça permets de gagner du temps, si tu préfère scroller ou appeller une fonction de ton IDE pendant que moi au simple nom de variable lu j'ai déjà les infos c'est que tu as une drôle d'idée de la productivité.

C'est ta méthode de travail, qui n'a pas*été prouvée plus efficace qu'une autre pour tout le monde. Encore une fois, cela fait fort longtemps que je développe sans utiliser de préfixes et je n'ai jamais confondu mes variables. Je peux en outre donner des arguments qui vont contre ton idée de la productivité. J'utilise par exemple beaucoup de refactoring. Donc si je déplace une variable locale dans un membre d'instance je dois, dans ton cas, penser à la renommer pour refléter sa nouvelle position. De même si je change un type de donnée (par exemple de float à double, ce qui m'arrive régulièrement). En contrepartie, la plateforme Java te propose deux mécanimes pour ne pas avoir besoin de recourir à des artifices comme les préfixes : l'utilisation de "this." et un typage fort qui intercepte les erreurs de type à la compilation (aujourd'hui, les IDE le font en temps réel).

En outre, la convention la plus répandue, car promulguée par Sun, est de ne PAS préfixer les variables. On pourrait débattre pendant des heures et mon but n'est pas de te convaincre de quoi que ce soit, mais simplement d'illustrer quelque chose de simple : nous parlons de choix artificiels et personnels. Cela ne sert à rien de partir en guerre contre tout le monde pour faire prévaloir tes propres goûts. Tu passes pour un jocrisse et on ne fait que perdre du temps. C'est à peu près aussi constructif que de débattre du pour on contre les tabulations dans le code source.

[@ldehan]

Tu apprendras pourtant que le redondance d'information est parfois très utile , pour économiser du temps de calcul de prix par exemple il est commun de les calculer et les stocker en DB même si pourtant l'info est déductible d'autres infos, calculable et donc redondante.

pareil pour les noms de variable, oui c'est redondant mais ça permets de gagner du temps, si tu préfère scroller ou appeller une fonction de ton IDE pendant que moi au simple nom de variable lu j'ai déjà les infos c'est que tu as une drôle d'idée de la productivité.

Ok pour la redondance utile, je veux bien te l'accorder. mais je ne suis pas sur ici que ce soit un gain de productivité.

Quand tu codes, tu connais normalement le type de toutes les variables que tu es en train d'utiliser. je me demande donc si tu perds plus de temps a faire cette vérification occasionnellement ou a ecrire systématique 3 caractères de plus à chaque fois que tu tapes une variable. je pense que c'est discutable.

[Rincevent76]

Ok pour la redondance utile, je veux bien te l'accorder. mais je ne suis pas sur ici que ce soit un gain de productivité.

merci

Quand tu codes, tu connais normalement le type de toutes les variables que tu es en train d'utiliser. je me demande donc si tu perds plus de temps a faire cette vérification occasionnellement ou a ecrire systématique 3 caractères de plus à chaque fois que tu tapes une variable. je pense que c'est discutable.

Quand tu va maintenir, corriger ou dévelloper le code de quun d'autre, qui s'étale peut être sur 4 pages et que tu n'as jamais vu tu sais "normalement" le type des variables utilisées ?

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...