Mickaël Wolff a écrit :
> Laurent vilday a écrit :
>> Mickaël Wolff a écrit :
>>> Mais au final, c'est une question de style, pas de défaut du langage.
>> Je ne suis pas d'accord.
>>
>> Le langage autorise l'omission des accolades mais je reste persuadé que
>> c'est une erreur. Erreur induite par la présence de l'omission autorisée
>> des points-virgules ;
>
> L'absence des accolades n'est pas une omission. C'est justement le
> contraire. Le mot clé if est suivi de la condition entre parenthèse puis
> d'UNE instruction. L'usage d'accolades, c'est à dire l'introduction d'un
> bloc d'instructions, est un contournement.

Je ne suis toujours pas d'accord, et ce qui me rassure, c'est que
Douglas Crockford va dans mon sens, et comme il a largement plus de
crédibilité que moi, je me sens moins seul sur le coup

<http://javascript.crockford.com/style1.html>

<cite>Douglas Crockford</cite>
<q lang="en">
JavaScript's if statement is similar to C's: it can take statements or
blocks. The problem with using statements is that a common error is very
difficult to detect. It is better to write

if ((e = c.indexOf(';', s)) == -1)
e = c.length;

as

if ((e = c.indexOf(';', s)) == -1) {
e = c.length;
}

Always use blocks in structured statements.
</q>

> En ce qui concerne le ;, concrètement, à quoi sert-il ? Une fin de
> ligne est déjà codée, pourquoi rajouter un symbole ?

euhh, peut être pour structurer les instructions et éviter les erreurs
d'interprétation ? Et peut être aussi parce que un saut de ligne n'a pas
beaucoup plus de signification qu'un espace, sauf dans quelques cas
rares (cf [exemple A] ci dessous, exemple direct de ECMA-262 §7.9).

if ( x ) y=25 z=33

Si on met de côté le parse error, c'est pas tout à fait pareil que

if ( x ) y = 25; z = 33;

ou encore

while ( i++ > 25 )
alert(i)

est *totalement* différent de

while ( i++ > 25 ) ;
alert(i);

Le ; n'est pas obligatoire ( il devrait ) mais lorsqu'il n'est pas
présent c'est à l'interpréteur de le rajouter en fourbe sans en avertir
personne. Hors dès qu'il y a intervention automatique sur un source, il
y a une dénaturation potentielle des instructions.

cf. ECMA-262 3e édition
chapitre 7.9 : Automatic Semicolor Insertion
<http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf>

[exemple A]

Cette règle est extrêmement dangereuse parce que ça peut tout changer
lorsqu'il existe un saut de ligne (LineTerminator) Ã la place du ;
supposé être ajouté.

return
a + b

Sera transformé, par cette règle 7.9, en

return ;
a + b ;

et lÃ, baam, bug introduit par l'insertion automatique puisque à priori
l'instruction désirée c'était :

return a + b;

>> IMO c'est un des gros défauts du langage, ça devrait être soit l'un soit
>> l'autre, mais pas les deux.
>
> Le défaut, c'est surtout de ne pas être typé. C'est ce que je regrette
> dans tout les langages de scripting (ou presque).

Tiens, c'est rigolo je trouve justement au contraire que c'est une force
des langages scriptés. IMO les variables typées ça a une importance
quand on compile un source et qu'on doit donc gérer très précisément les
zones mémoires attribuées. Tandis que pour les langages scriptés, ben
c'est pas au dev de gérer toutes ces saloperies d'adressage mémoire et
par conséquent, pas besoin de typer chaque variable.

> Je crois que tu n'as pas compris ce qu'est une variable globale :p .
> Tu as commencé par quel langage de programmation à coder ?

Ohhh que t'es vilain

<http://javascript.crockford.com/style2.html>

<cite>Douglas Crockford</cite>
<q lang="en">
Global variables are evil
</q>

--
laurent