CoffeeScript une r�ponse possible au champ min� qu�est JavaScript ?

CoffeeScript une r�ponse possible au champ min� qu�est JavaScript ?
Un blogueur explique pourquoi ce n�est pas le cas

� Pourquoi CoffeeScript n�est pas la r�ponse ? � telle est la question pos�e dans le billet de blog de Jeff Walker, un d�veloppeur avec plusieurs ann�es d�exp�riences qui revient sur les plus et les moins de CoffeeScript.

Tout d�abord, CoffeeScript est un projet open source qui introduit une nouvelle syntaxe au langage JavaScript et qui apporte son lot de concepts nouveaux. L�autre m�rite de ce projet est d�crit dans ce qui suit : � La r�gle d�or de CoffeeScript se r�sume � : C�est juste du JavaScript. Cela veut dire qu�il y a �quivalent strict � chaque ligne de CoffeeScript. Par cons�quent, il n�y a pas autant de probl�mes d�interop�rabilit� du JavaScript qu�avec d�autres comme Dart �.

Forts de ces arguments, Jeff Walker a d�cid� d�utiliser cette variante de JS dans un nouveau projet, n�anmoins il semble que l�exp�rience n�a pas �t� concluante : � Cette exp�rience m�a amen� � ne pas utiliser CoffeeScript sur mon projet actuel �. Pourquoi donc ? Le blogueur s�explique sur la base de quelques points essentiels :

- Un code ambigu :
Sous CoffeeScript, les parenth�ses, les accolades et les virgules sont optionnels, remplac�s par des espaces blancs et de l�indentation, toutefois cela am�ne � certaines situations ambigus, en voici un exemple :

• Le code suivant ne peut �tre compil� :

Citation:

---

func 5, {

event: (e) ->

if e.something

36

else

45,

val: 10}

---

Il est n�cessaire de supprimer la virgule ou de la placer sur la ligne suivante devant val.

• A + B revient � additionner A et B, alors que A +B est �quivalent � un appel de A avec comme argument +B

- Lisibilit� du code :
Sous CoffeeScript, tout est expression logique (une valeur de retour existe), or selon notre blogueur : � Le cerveau humain comprend facilement la logique sous forme de symboles �. Ainsi �valu� l�exemple ci-dessous reste complexe (tir� du tutoriel officiel sur les boucles):

Citation:

---

foods = ['broccoli', 'spinach', 'chocolate']
eat food for food in foods when food isnt 'chocolate'

---

• En premier lieu la d�claration de foods qui est effectu�e au milieu de cette expression n�apparait pas clairement comme une d�claration de variable.
• De plus il n�est pas clair quelle est la valeur retourn�e � eat.
• Enfin l�existence d�une condition n�est r�v�l�e qu�en dernier lieu.

- L�illusion de l�existence des classes :
Malgr� les demandes des d�veloppeurs, la notion de classe n�a pas vu le jour sous JavaScript. Sous CoffeeScript le pas a �t� franchi, mais les classes ne sont qu�une simple �mulation du concept, (cela est d� � la r�gle d�or de CoffeeScript). Cette situation m�ne � une plus grande confusion pour certains concepts de JS, en particulier le mot cl� This qui n�a pas la m�me signification que sous les langages OO.

Pour finir, il est important de noter que � CoffeeScript a commenc� � partir d�une position forte et une bonne approche philosophique vis-�-vis du champ min� qu�est Javascript �. De plus le blogueur signale qu�au quotidien cela diff�re : � En r�alit�, les questions que j'ai soulev�es en ce qui concerne CoffeeScript ne se rencontrent pas tous les jours �, m�me si � En fin de compte, elles sont suffisantes pour dire que nous avons besoin de quelque chose de mieux �.

Source : Blog de Jeff Walker
Et vous ?

:fleche: Qu�en pensez-vous ?

:fleche: Utilisez-vous CoffeeScript ou bien une autre variante de JS ? Avez-vous rencontr�s ces m�mes difficult�s ?

Ce n'est que mon avis, mais je trouve que donner un sens logique � des espaces est une h�r�sie (en CoffeeScript l'indentation remplace les accolades pour d�terminer le scope). Pour la m�me raison, je n'ai jamais utilis� Jade ou SASS.

Les �diteurs sont incapables d'auto-indenter ce genre de code, puisqu'ils ne peuvent pas deviner � quel scope on souhaite placer une instruction. Et si jamais ils r�indentent tout de m�me le fichier (ce qui est loin d'�tre rare, surtout dans les �quipes o� chacun a son propre IDE), le fonctionnel du code peut changer ! Un bogue � cause d'une mauvaise indentation, il fallait l'inventer.

Comme l'a dit mon VDD, donner un sens � l'indentation du code est certainement une mauvaise id�e.

Tr�s peu de d�veloppeurs, selon moi, sont pr�ts � faire preuve d'apostasie.

On remarque parfois que l'indentation du code est la "signature" de celui qui l'a �crit.

Le meilleur exemple que j'ai en t�te est, qu'� l'�poque o� je faisais du C++, chaque d�veloppeur mettait ses accolades / sauts de ligne o� il l'entendait :

Code:

---

1 2 3 4 5

if( toto == 1) { toto+=1; } else { toto-=1; }

---

Code:

---

1 2 3 4 5 6 7

if( toto == 1) { toto+=1; }else { toto-=1; }

---

Je reprend la merveilleuse phrase de mon VDD : "Un bogue � cause d'une mauvaise indentation, il fallait l'inventer."

Javascript un champs min� ?
Je dois avoir de la chance parce que �a fait un bail que je me prom�ne dans ce champs et je n'ai pas encore saut� :mouarf:

Citation:

---

Envoy� par Arsene Newman

Ainsi �valu� l�exemple ci-dessous reste complexe (tir� du tutoriel officiel sur les boucles):

Code:

---

1 2	foods = ['broccoli', 'spinach', 'chocolate'] eat food for food in foods when food isnt 'chocolate'

---

• En premier lieu la d�claration de foods qui est effectu�e au milieu de cette expression n�apparait pas clairement comme une d�claration de variable.
• De plus il n�est pas clair quelle est la valeur retourn�e � eat.
• Enfin l�existence d�une condition n�est r�v�l�e qu�en dernier lieu.

---

:calim2:

Code:

---

1 2 3

# Health conscious meal. foods = ['broccoli', 'spinach', 'chocolate'] eat food for food in foods when food isnt 'chocolate'

---

Avec la couleur �a me parait plut�t clair...

Citation:

---

Envoy� par SylvainPV

Ce n'est que mon avis, mais je trouve que donner un sens logique � des espaces est une h�r�sie (en CoffeeScript l'indentation remplace les accolades pour d�terminer le scope). Pour la m�me raison, je n'ai jamais utilis� Jade ou SASS.

---

Je suis partiellement d'accord. En python �a passe nickel par exemple, mais ils sont beaucoup plus stricts. Notamment, les lambda ne peuvent pas d�passer une ligne. Et l� tout change.

Quand je vois �a :

Code:

---

1 2 3

setTimeout -> doSomethind() , 1000

---

ou �a

Code:

---

1 2 3 4 5

myFunc hello: 'world' , -> doSomething()

---

(�quivalent JS pour ceux qui veulent pas chopper une migraine : )

Code:

---

1 2 3 4 5

myFunc({ hello: 'world' }, function() { return doSomething(); });

---

j'ai envie de vomir (ou presque)...
CF est bien trop permissif et ambigu � mon gout. Ou plut�t il permet de produire trop facilement du code permissif et ambigu.
Apr�s je pense qu'on peut faire un code �l�gant avec, en �tablissant des r�gles et des conventions strictes, mais c'est rarement le cas.

Citation:

---

champ min� qu�est JavaScript

---

Si tous ceux qui utilisent JavaScript prenaient le temps de l'apprendre et de comprendre le pourquoi de ce qu'ils consid�rent �tre des incoh�rences, ils se rendraient compte que le champs de mines n'est qu'une illusion.

Citation:

---

Envoy� par Enerian

Je suis partiellement d'accord. En python �a passe nickel par exemple

---

Moi je suis moyennement d'accord avec �a :aie:
J'aime bien le fait que l'indentation soit codante dans le principe, parce que �a oblige � indenter et force donc un style d'�criture commun � tout le monde, ce qui augmente la lisibilit� in fine.
Mais dans la pratique c'est en r�alit� trop rigide. On ne peut plus indenter volontairement pour aligner des choses afin de rendre plus lisible.

L'id�al, a mon sens, serait que l'�diteur applique un style � l'ouverture (indentation par tabulation ou espace, accolage en fin de ligne ou sur nouvelle ligne, limite a 80 caract�res par ligne, etc...) et qu'on puisse sp�cifiquement forcer un style sur des bloc pr�cis quand le d�veloppeur veut imposer le style pour une question d'alignement (genre un pose un mini diagramme en ascii-art).
Mais �a suppose que tous les �diteurs supportent la fonctionnalit�, y compris les logiciels de comparaisons histoire que les fichiers ne soient pas en permanence en diff�rence. Ca impose �galement que le langage contienne ce qu'il faut pour r�ellement appliquer un profile (c'est donc foutu pour le python et les langages dont l'indentation est codante).

Bref, les histoires de styles c'est une �ternelle question qui ne sera jamais r�ellement r�solue parce que chacun ses gouts et que les gouts et les couleurs �a se discute pas...

Une horreur les morceaux de code qu'il montre en effet.

Le probl�me avec le JS c'est pas sa syntaxe, elle est tr�s bien, c'est son typage faible et son syst�me de classes trop limit� (le fait qu'on ait trois mani�res de faire des classes, mais aucune n'est aussi bien que n'importe quel langage � succ�s (c#, java, c++...)).

Le fait d'avoir des espaces/tabulations qui signifient quelque chose me fait penser � Jade, c'est une �norme connerie, qui rend les programmes super chiant � d�bugger et qui n'apportent rien.

les indentations codantes ne sont pas tellement le probl�me car sur python les IDE te le disent direct si tu merde
mais sur CoffeeScript le fait que tout est expression �a c'est une connerie pour moi, il y a pas mieux pour avoir du code ilisible

Ayant test� pas mal de langages diff�rents, y'a des choses r�currentes que j'ai du mal � comprendre : les accolades ouvrantes/fermantes.
Python a fait ce pari "de g�nie" de donner du sens � l'indentation : la courbe d'apprentissage est sans doute un peu plus ardu mais derri�re �a veut dire un gain en lisibilit� et de maintenance et �a, �a n'a pas de prix.
Dans la plupart des projets un minimum s�rieux dans d'autres langages, l'indentation est obligatoire et peux �tre un frein pour des nouvelles contributions : se faire refuser un pull request pour de l'indentation, c'est balo quand m�me.

L'histoire des go�ts et des couleurs : oui et non...
D'une part : peu de dev choisissent r�ellement leur langage et par cons�quent leur mani�re de coder (elles sont donc conditionn�s et souvent irrationnels).
De plus, il serait bon de pr�ter attention � des �tudes s�rieuses sur le fonctionnement de cerveaux vierges face des usages.
N'importe quel dev c'est contraint � de la gymnastique souvent

La raison de l'ascii art est irrecevable � mon sens : si tu as de l'ascii art, c'est forc�ment soit dans des commentaires soit dans un fichier statique externe.

Coffeescript est une surcouche d'une part (donc forc�ment bancal) et assume � moiti� ces choix d'autres part. Leur r�gle d'or d'�tre du javascript c'est du pur commercial : on pr�f�re �tre d�mago plut�t que d'assumer pleinement des choix radicaux tel que l'indentation!
Je dirais que coffeescript/livescript (� moindre mesure Dart) peuvent donner des bonnes id�es pour des nouvelles standardisation de l'ECMA ou autre mais reste peu utilisable en prod et vou� � dispara�tre t�t ou tard.

Euh... bon la discussion sur l'indentation c'est comme les go�ts et les couleurs. Pour ma part je trouve qu'une indentation stricte �vite 15 styles de codages diff�rents (si le codeur veut signer son code, il met un commentaire "#Mangobango waz ayre"). Par contre gaffe � ce que l'�diteur indente de mani�re coh�rente (m�lange tabulations vs espaces). Mais c'est vrai qu'il y a des couacs avec cette foutue indentation dans Coffeescript. Moi je m'impose de garder les parenth�ses pour les appels de fonctions, et pour les lambdas de plusieurs lignes je les emprisonne dans des parenth�ses aussi... hop!

Il y a un tantinet de mauvaise foi sur l'exemple des "list comprehensions" qui se lit quasi comme une phrase anglaise (un peu lourde certes). Et avec la coloration syntaxique, �a passe tr�s bien. Les "compr�hensions de listes" ne sont pas propres � Coffeescript, Python les a, Haskell aussi, la sytax est souvent tr�s similaire et d�rive des "set-builder notations" (http://learnyouahaskell.com/starting-out). Dit autrement, c'est peut-�tre pas digeste au premier regard, mais on l'apprend une fois pour toutes.

Bon, sinon il parle des avantages? Le mod�le objet plus classique? Les supers-pouvoirs du "=>"? Je trouve qu'au final c'est plus facile � suivre que du Javascript, moins de "bruit" visuel et logique.

:)

Daniel

L'indentation codante, un gain en lisibilit� et de maintenance ??? Pour toi, en donnant la possibilit� de p�ter un code juste en rajoutant/retirant des espaces, �a rend le langage plus facile � maintenir ?

On a pas besoin de retirer les accolades pour convaincre les d�veloppeurs d'indenter leur code. C'est comme si on for�ait quelqu'un � longer le bord d'une falaise pour lui apprendre � marcher droit...

Citation:

---

Envoy� par Enerian

Si tous ceux qui utilisent JavaScript prenaient le temps de l'apprendre et de comprendre le pourquoi de ce qu'ils consid�rent �tre des incoh�rences, ils se rendraient compte que le champs de mines n'est qu'une illusion.

---

+1000

CoffeeScript c'est supercool, j'expliquais pas plus tard que la semaine derniere comment il peut �tre utilis� pour g�n�rer des m�tas objets, par le principe de classes et d'appelles de fonctions (et l'utilisation de @ � la place de this)

Par exemple, � l'usage il devient ais� de d�velopper une ecriture fluide pour un ORM (notamment pour nodejs)

Code:

---

1 2 3 4 5 6 7 8

class DbTable @table = -> ... #Code pour aller chercher la table par exemple et recuperer tout les champs @validatesPresenceOf = (fields...) -> #On check à la sauvegarde les champs etc...   class Post extends DbTable @table 'posts' @validatesPresenceOf 'id', 'content' #Ruby style :)

---

Par contre effectivement il faut �tre disciplin� pour avoir un code propre. Et eviter quelques pi�ges. Le pire �tant celui-ci (c'est du v�cue!)

Code:

---

1 2 3

['apple', 'peach', 'banana'].sort (a,b) -> a > b ? -1 : 1

---

Sortira ce code (WTF?!):

Code:

---

1 2 3 4 5 6 7

['apple', 'peach', 'banana'].sort(function(a, b) { var _ref; return (_ref = a > b) != null ? _ref : -{ 1: 1 }; });

---

En fait l'operateur ternaire n'existe pas, il faut utiliser "if a > b then -1 else 1"... Mais c'est quand meme fou qu'il compile. Et du coup le code plante pas et fait n'importe quoi...



EDIT:

Je tiens a pr�ciser que je code en cofeescript d�s que je peux, je trouve le langage plus fluide que le javascript. J'ai un gain de productivit� d'au moins 30%. Le probl�me des indentation ou autre joyeuset� n'est qu'un faux probl�me. C'est une question d'habitude, que tu prend en moins de 48 heures.

Les probl�mes graves, sont selon moi:

- Les erreurs de syntaxes ne sont pas toujours claires, alors il ne faut pas h�siter � utiliser l'outil coffeelint si �a plante, afin d'avoir une meilleur comprehension sur le pourquoi
- Le code qui semble correcte mais qui compile compl�tement � cot� de la plaque (il y a des cas d'�cole je pourrais les lister ici si vous le souhaitez...)
- L'inf�rence de type est moins bien g�r� sous coffeescript, donc le code est moins performant. Car toute fonction retourne la derniere instruction (comme en ruby). Du coup faut forcer un "return" en fin de fonction pour profiter des derni�res optimisations de libv8

Mais meme ainsi, j'ai peu de chose � reprocher � coffescript. Ah, si, il me fait raler lorsque je doit (re)faire du javascript :D.

Et c'est � comparer avec des probl�mes graves de javascript "natif":

- L'oublie d'un "var" = variable globale... Le plus grave des probl�mes � mon sens
- Les milles fa�on de faire une classe, qui rend le code difficile � lire, notamment lorsque plusieurs d�veloppeurs travaillent dessus, � coup de prototype, de $.extend et autre mani�res... Si on peut le faire aussi avec CS, l'usage du mot cl� "class" mets tout le monde d'accord sur le but final de ton code: "JE FAIS DE L'OBJET LA ICI MAINTENANT!".
- L'usage de "proxy" type "var self = this;" dans des callbacks imbriqu�s ne favorise vraiment pas la comprehension, � comparer avec l'op�rateur "=>"
- La difficult� a d�couvrir un probl�me au niveau des operations, type "1" == 1 renvoie true, mais "1" === 1 renvoie faux.
Coffeescript n'utilise que l'operateur ===, ce qui force le d�veloppeur � caster ses types pour les comparer, rendant le code plus robuste � mes yeux.


Sinon, �a c'est cool c'est bien lisible:

Code:

---

1 2 3 4 5

#EX: Renvoyer un table de 10 fonctions differentes qui seront evaluées plus tard. func = [] for x in [0..10] do(x) -> func.push -> x*x

---

Code:

---

1 2 3 4 5 6 7 8 9

var x; var func = [];   for (x = 0; x <= 10; x++) { func.push((function(x) { return function(){return x * x}; })(x)); }

---

:ptdr:

J'aime bien comment certains d�veloppeurs reste bloqu�s � la surface du concept du style "Les indentations c'est pas bien" ou autre... Je ne pense pas que l'on puisse juger un langage juste sur ce genre de "choix" � mon avis... Mais bon c'est que mon avis ;)

Citation:

---

Envoy� par SylvainPV

L'indentation codante, un gain en lisibilit� et de maintenance ??? Pour toi, en donnant la possibilit� de p�ter un code juste en rajoutant/retirant des espaces, �a rend le langage plus facile � maintenir ?

---

et �a t'a jamais choqu� qu'on puisse "casser" un code juste en enlevant un point-virgule en C, c# ou Java?
en python par exemple, si y a une coquille dans l'indentation l'erreur sera remont�e tout de suite et tu corrigera ton code; un peu comme si ton code compile pas en C, tu le corriges. je vois vraiment pas ou est le probl�me.

et sinon, quand le code du d�veloppeur A ressemble au code du d�veloppeur B et au code des d�veloppeurs C, D, E, F, etc... oui �a rend le code plus facile � maintenir. pour la simple raison que n'importe quel d�veloppeur Python n'aura pas � s'adapter au "style" d'un autre d�veloppeur.

Citation:

---

Envoy� par SylvainPV

On a pas besoin de retirer les accolades pour convaincre les d�veloppeurs d'indenter leur code.

---

bah tu peux t'estimer chanceux si t'as jamais crois� un gars qui, m�me au bout de plusieurs d'ann�es de metier, n'est toujours pas foutu de faire une indentation correcte.
t'es encore plus chaceux si t'es jamais tomb� sur un bout de code copi�/coll� dont le colleur a n�glig� de refaire l'indentation.
et t'es encore plus chanceux si t'as jamais eu � faire au conflit tabulation/espace dans l'indentation.

autant de probl�mes qui n'existent pas en Python (je connais pas CoffeeScript alors je parle de ce que je connais) car l'interpr�teur gueule direct si l'indentation n'est pas faite correctement.

Pour ma part j'utilise Coffeescript d�s que je peux, c'est un gain de temps et de confort tr�s appr�ciable! Je trouve que le blogueur s'est arr�t� sur des trucs vraiment pas tr�s graves, pas de quoi � mes yeux revenir � du JS natif qui est bien plus p�nible � �crire et � lire.

Les histoires d'indentation forc�e, pour moi c'est un faux d�bat. Je code aussi en Ruby et c'est juste tr�s tr�s confortable de pas avoir taper des accolades et des points virgules � toutes les lignes. C'est quand je dois refaire du code en PHP, Java ou JS natif que je trouve stupide de ne pas faire compiler un code � cause d'accolades oubli�es. Et tous les pr�processeurs qui font foin des accolades et points virgules sont bons � prendre (SASS, HAML, Jade, que du bon) car en plus �a vous force � bien indenter le code. Et je peux dire en connaissance de cause que passer derri�re un code mal indent� c'est une vraie plaie.

Citation:

---

Envoy� par Tryph

et �a t'a jamais choqu� qu'on puisse "casser" un code juste en enlevant un point-virgule en C, c# ou Java?

---

Le point virgule s�pare les instructions. Python est diff�rent ? Non, tu as juste � remplacer le point virgule par le retour chariot.

Citation:

---

Envoy� par Tryph

en python par exemple, si y a une coquille dans l'indentation l'erreur sera remont�e tout de suite et tu corrigera ton code; un peu comme si ton code compile pas en C, tu le corriges. je vois vraiment pas ou est le probl�me.

---

Python est beaucoup plus strict au niveau syntaxique que CoffeeScript, �a a d�j� �t� dit. Le probl�me avec CoffeeScript c'est qu'un d�faut d'indentation ne g�n�re pas forc�ment d'erreur car deux indentations diff�rentes peuvent �tre valides et avoir un sens diff�rent ; par exemple pour d�terminer si une instruction est en dedans ou en dehors d'une condition. Il est l� le probl�me, une erreur d'indentation peut passer inaper�u et foutre en l'air la logique du code !

Citation:

---

Envoy� par Tryph

bah tu peux t'estimer chanceux si t'as jamais crois� un gars qui, m�me au bout de plusieurs d'ann�es de metier, n'est toujours pas foutu de faire une indentation correcte.
t'es encore plus chaceux si t'es jamais tomb� sur un bout de code copi�/coll� dont le colleur a n�glig� de refaire l'indentation.
et t'es encore plus chanceux si t'as jamais eu � faire au conflit tabulation/espace dans l'indentation.

autant de probl�mes qui n'existent pas en Python (je connais pas CoffeeScript alors je parle de ce que je connais) car l'interpr�teur gueule direct si l'indentation n'est pas faite correctement.

---

Comme si c'�tait un probl�me ! Un raccourci clavier et hop ton code est auto-indent� avec tes pr�f�rences ou celles �tablies pour ton �quipe. Est-ce que tu peux faire la m�me chose avec CoffeeScript ? Non, car l'indentation change la logique du code...

C'est quoi cette fixette sur une erreur d'indentation ? C'est pas plus dur a d�tecter ni plus facile � faire ni et plus dur � corriger qu'une erreur de parenth�se ! Et puis si une mauvaise indentation devrait pouvoir passer parce qu'il ne casse pas la � logique du code �, je pr�f�re pas lire le code, m�me s'il est auto-indent� plus tard.

PS: En haskell une mauvaise indentation ne compile pas, donc le probl�me, s'il existe, est plus profond que �*donner du sens � l'indentation*�

Citation:

---

Envoy� par SylvainPV

Le point virgule s�pare les instructions. Python est diff�rent ? Non, tu as juste � remplacer le point virgule par le retour chariot.

---

dans les 2 cas (un point virgule manquant en C, ou une indentation mal faite en Python), si on respecte pas la syntaxe du langage, on a une erreur. c'est le cas pour tous les langages, y a pas � d�cider que l'un est plus juste que l'autre.
d'ailleurs on peut tr�s bien, en Python, mettre plusieurs instructions sur une m�me ligne et les s�parer par un point-virgule, c'est pas recommand�, mais c'est possible. et tu peux bien finir toutes tes instructions par un point-virgule si �a te chante, sans que �a perturbe l'interpr�teur.
du coup on pourrait trouver que c'est ridicule qu'un compilateur puisse s'offusquer d'un oubli de point-virgule... non?

Citation:

---

Envoy� par SylvainPV

Python est beaucoup plus strict au niveau syntaxique que CoffeeScript, �a a d�j� �t� dit. Le probl�me avec CoffeeScript c'est qu'un d�faut d'indentation ne g�n�re pas forc�ment d'erreur car deux indentations diff�rentes peuvent �tre valides et avoir un sens diff�rent

---

c'est pas ce que j'ai lu dans l'article... j'ai lu que les blocs pouvaient �tre d�finis par l'indentation du code et que la pr�sence d'un espace (ou non) apr�s un op�rateur avait un sens. si cet espace est apr�s un op�rateur, c'est pas de l'indentation.
hors comme tu parlais uniquement d'indentation dans ton message, je n'ai r�pondu que sur l'indentation.
si tu parles du fait l'espace manquant dans "A +B" puisse avoir un comportement diff�rent de celui auquel on s'attend, je suis d'accord pour dire que c'est d�j� plus g�nant. mais encore une fois, on fait avec les sp�cificit�s du langage qu'on utilise.
en C on veille � bien mettre le point-virgule, en Python, on veille � bien faire l'indentation de son code... j'imagine qu'en CoffeeScript, on veille � mettre des espaces l� ou il en faut.
du moment que l'appel d'une variable non appelable (entier, flottant, etc...) ou l'addition de 2 fonctions provoque une erreur, alors c'est pas bien m�chant: on voit l'erreur, on corrige et c'est bon.
(apr�s je connais pas CoffeeScript alors je peux rien affirmer, si un utilisateur peut nous en dire un peu plus...)

Citation:

---

Envoy� par SylvainPV

par exemple pour d�terminer si une instruction est en dedans ou en dehors d'une condition. Il est l� le probl�me, une erreur d'indentation peut passer inaper�u et foutre en l'air la logique du code !

---

bah c'est exactement la m�me chose en Python. et j'ai envie de te dire que si ton accolade est une ligne trop loin dans un code en C, c'est pareil: la logique de ton code en est affect�e et �a peut passer inaper�u... d'autant plus si l'indentation est mal faite.

Citation:

---

Envoy� par SylvainPV

Comme si c'�tait un probl�me ! Un raccourci clavier et hop ton code est auto-indent� avec tes pr�f�rences ou celles �tablies pour ton �quipe. Est-ce que tu peux faire la m�me chose avec CoffeeScript ? Non, car l'indentation change la logique du code...

---

on peut pas faire �a non plus en python. en fait c'est le d�veloppeur qui indente son code correctement, pas la machine.

Citation:

---

Envoy� par laerne

je pr�f�re pas lire le code, m�me s'il est auto-indent� plus tard.

---

Et c'est nous qui faisons une fixette :roll: Un raccourci clavier c'est encore de trop ?

L'indentation, en programmation et plus g�n�ralement en typographie, a pour seul but de mettre en �vidence l'organisation hi�rarchique d'un texte : pas de changer le sens du texte ! J'estime qu'il n'est pas normal que ces deux codes renvoient un r�sultat diff�rent:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

n=0 for i in [1..5] n++ n+=2 if n%2 n+=3     console.log n         n=0 for i in [1..5] n++ n+=2 if n%2 n+=3   console.log n

---

Un espace en plus ou en moins, c'est tout ce qu'il faut pour fausser le r�sultat d'un code CoffeeScript. Qu'on ne vienne pas dire que retirer les accolades et les points virgules rend le code plus lisible et facile � maintenir : c'est l'exact oppos�. S'il suffisait de retours chariots et d'espaces ins�cables pour donner du sens, on aurait pas invent� la ponctuation. En voulant toujours plus "�purer" et "simplifier" la syntaxe, on vire au minimalisme et on am�ne tout un lot de probl�mes de compr�hension et de lisibilit� juste pour satisfaire des caprices insens�s : "c'est plus beau comme �a" ; "�a fait moins de code � taper".

Apr�s, je ne crache pas sur tout ce qu'apporte CoffeeScript. Il pr�sente de nombreux aspects tr�s int�ressants, sur la d�claration de variables, les keywords plus descriptifs, la d�claration d'Array... C'est juste ce principe d'indentation codante qui me fait tourner bourrique. Enfin, � chacun son avis et ses choix.