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.

L'histoire des espaces autour des opérateurs ça me fait penser au C++ (2003) où

Code:

---

vector<vector<int>>

---

était une erreur. Parfois les grammaires sont boguées, et C++ 2003 devait interpréter ">>" comme l'opérateur et non comme "fin de template, fin de template".

Il y a pas mal de points valides dans tout ce qui a été dit. Finalement l'indentation codante n'est pas un problème si et seulement si le parser (et par conséquent la grammaire) est suffisamment strict*. Je pense que c'est là ZE faiblesse de coffeescript. Le compilateur laisse passer des ambiguïtés et les messages d'erreurs sont parfois... satellisants. En fait, en resserrant un peu la grammaire et améliorant les retours du compilo, ça serait le top (mais ça foutrait la pagaille dans les programmes déjà existants :mouarf:).

Alors on peut peut-être espérer une évolution du compilo? Ou alors Coffeelint** comble-t-il les manques?

Mais déjà, pratiquant beaucoup Python, je me retrouve mieux dans (un certain dialecte strict de :roll:) Coffeescript que dans Javascript. Bref... question d'horizons sans doute.

Daniel

* et qu'on ne tient pas aux accolades/points-virgules/deux-points/... comme à un talisman ;)
** je ne connaissais pas, je devrais prendre l'habitude de chercher "{nom_du_langage}lint"

Coffeelint corrige bien ce genre de probleme, à utiliser absolument si tu fais du coffee :)

Il est très stricte et il relève même des trucs correctes :

Code:

---

1 2 3 4

$("#selector") .on 'click', -> something() .attachTo($('body'))

---

(En fait il faut ecrire)

Code:

---

1 2 3 4

$("#selector") .on 'click', -> something() .attachTo($('body'))

---

Mais je trouve l'indentation dans ce cas intéressant ;-)

Citation:

---

Envoyé par ctxnop

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.

---

en fait ce que je ne comprend pas dans ce débat sur l'indentation c'est en quoi il est opposé à une syntaxe claire...qu'est-ce qui empêcherais un compilateur C++ "strict" de refuser ce code mal indenté ?

Code:

---

1 2 3 4 5 6 7 8

void test( int i) { return i *i; }

---

il est syntaxiquement correct, mais le compilateur pourrait le refuser pour manque de lisibilité, on aurait le meilleur des deux mondes....d'autant qu'un IDE digne de ce nom sera en mesure de corriger sans erreur l'indentation de ce code.

J'ai installé coffeelint et ai activé flymake-coffee dans mon emacs. Ah bah oui, il repère pas mal de trucs. Il faut le configurer un peu aussi pour limiter les faux positifs (j'indente avec 4 espaces par ex., pas deux - je suis myope, j'aime bien avoir un beau décalage bien repérable) mais il fait déjà un bon boulot!

Daniel