CrEv a écrit 4577 commentaires

Pour ma part, je suis dans le 3ème camp : faites du CoffeeScript !

Sur le principe je serais plutôt ok.
Mais

la syntaxe basée sur l'indentation avec peu de parenthèses et d'accolades donne un style assez bizarre et difficile à relire

n'est-ce pas un sérieux problème si on veut avoir un code maintenable et pérenne ?

Et quelques questions bonus :

• utilises-tu des choses comme http://jashkenas.github.com/docco/ pour commenter ? Si oui, c'est pas un problème pour commenter les classes (j'ai toujours trouvé que le literate programming avait des problèmes avec la programmation objet)
• utilises-tu des frameworks avec coffee (voir des frameworks non écrit en coffee) ? Si oui, comment gérer les multiples solutions d'héritages et de création d'objets ? Je pense par exemple à http://bolinfest.com/coffee/)

Par contre, c'est vrai que unless ? et ?. c'est quand même vraiment sympa.

Oui il y a des choses étranges, mais l'histoire de == === est loin d'être complexe

C'est quand même loin d'être simple. Il y a même un cas où a === a renvoie false.

Oui, c'est sur. Mais en général, on ne tombe pas bien souvent dessus.
Et la compréhension de == et === n'est pas si compliquée dans 99% des cas. C'est surtout que les gens ne sont pas habitués à cela, tout comme ils essaient de faire de la programmation par classe en javascript, alors que c'est un langage à prototype.

D'ailleurs, le code en question était valide, c'était le minificateur de Douglas Crockford qui était en faute.

Ok, j'avais initialement lu le contraire, d'où ma réponse.
Il semble que tu ais raison :
https://github.com/douglascrockford/JSMin/commit/5ca277ea452beae1c25db3bc0ef5c81309a3daf4#jsmin.c

Il est vrai que, lorsque j'utilisais jsmin, la règle était :

• toujours ;
• toujours {}

Après, c'est sur qu'avoir le créateur de javascript en faveur du ; a un certain point. Mais c'est à ce demander pourquoi ils ne sont pas obligatoire finalement.

Comme indiqué, uniquement pour pouvoir récupérer la source et faire un log propre.

Si j'ai cet usage d'une méthode assert :

assert(null == undefined);

ma méthode assert est appelée avec comme paramètre le résultat de l'opération null == undefined, ici true. Je ne peux donc pas écrire un log correct ici, je peux juste dire si c'est true ou false.

Si j'ai

assert(function() { return null == undefined; });

ma méthode assert est appelée avec une fonction en paramètre. Je peux exécuter cette fonction (qui me renverra true ou false) mais aussi accéder à la définition de cette méthode, sous forme de string. Je peux donc logger la source qui a été exécutée.

J'espère que c'est un peu plus clair, si non pointe ce qui ne l'est pas et je continuerai à détailler.

histoire de donner un peu de grain à moudre à mon précédent message : pensez à self

CoffeeScript c'est sympa, y'a des choses intéressantes, mais : comment on debug ce truc ? Un langage dans lequel on ne peut pas mettre un point d'arrêt ça n'a que peut d'intérêt malheureusement.
Si je ne me trompe les sourcesmap sont arrivée que récemment (pas encore testé) mais on est simplement au même niveau du debug d'un code compilé javascript - javascript (comme avec closure compiler par exemple).
J'ai beaucoup de mal à comprendre comment on peut espérer attirer des développeurs, pour faire des applis conséquentes (et non juste deux bricoles) sans debugguer. Et les "console" ou log ne sont pas une solution au problème.
Dommage car c'est ma plus grande critique au langage.

tant qu'à faire il aurait peut-être aussi fallu améliorer un peu le modèle objet de python dans ce cas. C'est quand même pas terrible.

(oué moi j'aime bien Dart au final…)

ce qui m'a séduit est le fait que du serveur au client en passant par la base de données (couchdb, mangodb,…) : ON UTILISE PLUS QU'UN SEUL LANGAGE !

oui mais CE N'EST PAS LA PEINE DE CRIER ;-)

On est obligé de rien.
J'aurais aussi pu écrire

var assert = function assert(test) {
};

ou

function assert(test) {
}

Mais les trois écritures ne sont pas tout à fait similaires. Pour ma part je commence toujours pas var ça permet de bien mieux mettre en évidence la portée de ma fonction.

Heu, quel est le problème de la deuxième ligne ?

En gros, ce que je voulais, c'est afficher la valeur "source" du return (d'ailleurs le fait de passer par une fonction anonyme dans le assert est là uniquement pour accéder à la source.
Donc :

test -> String source de la fonction passée en paramètre.

/return ([^;]+);/

est une bête expression régulière, je cherche tout ce qui est entre return et ; (et en fait je match sur [^;] donc tout caractère différent de ;.

Comme l'expression régulière est un objet, je peux exécuter une méthode dessus. Ici .test qui me permet de savoir si la chaîne passée en paramètre (ici test.toString() bien que le toString soit implicite) correspond à la regexp.

En réalité je n'utilise absolument pas le retour (true ou false, ici systématiquement true). Mais lorsqu'on utilise une regexp, l'objet RegExp est peuplé avec le dernier résultat.
Donc RegExp.$1 me permet de récupérer la première référence, donc le premier groupe entre parenthèse dans ma regexp.

Au final :

var func = function() { return "0" == 0; });
var funcStr = func.toString(); // "function() { return "0" == 0; });" en gros
var returnValRegExp = /return ([^;]+);/;

if (returnValRegExp.test(funcStr)) {
  console.log(RegExp.$1); // "0" == 0
}

sauf que je n'ai pas mis le if

Pour l'insertion implicite des points-virgules, je maintiens qu'un langage qui propose un truc aussi bancal et foireux est plus un moyen de se tirer une balle dans le pied qu'autre chose.

Faut voir, si on prend l'un des derniers trolls sur le sujet (https://github.com/twitter/bootstrap/issues/3057) il apparaît (très rapidement) que le problème n'est pas en fait l'absence du ; mais surtout l'usage de ! comme séparateur

TC39 is considering the use of ! as an infix operator. This code will break in the future. Fix it now. Learn to use semicolons properly. ! is not intended to be a statement separator. ; is.

Alors c'est sur, javascript est laxiste… mais c'est pour ça qu'il faut arriver à bien comprendre les forces et faiblesses de celui-ci, et surtout connaître les limites. Après c'est beaucoup plus facile de coder avec.

P.S. je note que tu n'as rien dit sur le scope des variables déclarées avec "var" :-p

Quel est vraiment le problème ? En effet le scope est la fonction. D'où l'usage courant de

(function() {
[...]
})();

afin d'isoler les traitements

Après il y a des choses bien plus tordues en javascript, notamment ce qui est après un return est accessible
par exemple :

var plop = function() {
  b();
  return;
  function b() { console.log('ok'); };
};
plop();
// ok

mais

var plop = function() {
  b();
  return;
  var b = function() { console.log('ok'); };
};
plop();

ne fonctionnera pas

Un lien assez sympa http://vic.github.com/jwm-tt-js-ninja/

Ben c'est pas ça, mais imagine que quelqu'un veuille intégrer ton nanimenc ou dec non pas sous forme d'un programme mais d'une classe à l'intérieur de son programme (il peut y avoir plein de raisons pour ça). Dans ce cas il faut bien savoir quoi utiliser, non ?

Pour jouer un peu :

var assert = function(test) {
    /return ([^;]+);/.test(test);
    if (!test()) {
        console.error("Oups, '" + RegExp.$1 + "' is false.");
    } else {
        console.info("Yeah, '" + RegExp.$1 + "' is true.");
    }
};
assert(function() { return undefined; });
assert(function() { return null; });
assert(function() { return false; });
assert(function() { return ""; });
assert(function() { return 0; });
assert(function() { return undefined == null; });
assert(function() { return undefined === null; });
assert(function() { return "0" == 0; });
assert(function() { return "" == false; });
assert(function() { return undefined == false; });
assert(function() { return undefined === false; });

Oups, 'undefined' is false.
Oups, 'null' is false.
Oups, 'false' is false.
Oups, '""' is false.
Oups, '0' is false.
Yeah, 'undefined == null' is true.
Oups, 'undefined === null' is false.
Yeah, '"0" == 0' is true.
Yeah, '"" == false' is true.
Oups, 'undefined == false' is false.
Oups, 'undefined === false' is false.

Dernièrement, dans tous mes projets de développement web, j'ai utilisé un moteur de template coté client en plus du moteur de template coté serveur.

Pourtant, il existe de nombreuses solutions permettant d'utiliser des templates (les mêmes) aussi bien côté client que côté serveur. C'est d'ailleurs, je pense, la meilleure solution pour gérer des sites ou applications web, d'autant plus lorsqu'on souhaite avoir aussi bien une version sans code côté client (accessibilité, indexation, référencement, js désactivé) qu'une version type ajax, rafraichissement côté client, interface agréable, etc.

Pour ma part j'utilise beaucoup Closure Templates (y compris en prod sur du grand public) : https://developers.google.com/closure/templates/ mais c'est intéressant surtout si on fait du java
Voir aussi ces très intéressant articles de Linkedin qui est passé de jsp, erb à du templating du même type, avec en bonus une comparaison de plusieurs frameworks de template (le lien parle initialement de templating côté client, mais la solution fait les deux) : http://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-linkedin-dustjs-client-side-templates et http://engineering.linkedin.com/frontend/client-side-templating-throwdown-mustache-handlebars-dustjs-and-more

utilisation plus ou moins laxiste du point-virgule

En quoi l'utilisation est laxiste ? Les derniers trolls sur le point-virgule sont surtout des personnes qui n'ont jamais appris correctement le javascript et qui écrivent un code dépendant de la mise en forme (et donc qui foire dès qu'on le minifie)

p….n de triple "="

Je crois que le jour où j'aurai 5 min, j'irai regarder si l'herbe n'est pas plus verte

Ben tu devrais plutôt passer 5 minutes à apprendre javascript en premier.
Oui il y a des choses étranges, mais l'histoire de == === est loin d'être complexe, il faut juste comprendre que plusieurs choses sont fausses et que tester l'égalité entre deux "valeurs fausses" est vrai mais ne veut pas dire que les valeurs sont identiques.

"" == 0 // true
"0" == 0 // true
undefined == null // true
undefined !== null // true

on va finir avec une pile de code impossible à maintenir

Comme dans tous les langages. Pour le js il "suffit" d'écrire proprement les choses, d'arrêter les syntaxes type jQuery (qui en plus d'être peu lisibles sont peu optimisable). Voir par exemple les "règles" de http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml

Vi vi, suis bien d'accord avec ça.
Le auto format à la sauvegarde est quand même vraiment quelque chose de bien (surtout lorsqu'on travaille à plusieurs).

Mais j'ai surtout tiqué sur la réponse

Je n'indente rien moi même,je laisse cette tâche ingrate à mon IDE/éditeur

Alors qu'on voit bien que c'est pas le cas / mal fait malheureusement

Le vrai programmeur ne commente pas, le code est évident!

J'espère que c'est de l'humour. Mais en tout cas, un tel code, même évident, ne donne pas envie d'y contribuer malheureusement.

Plus sérieusement

ouf

si quelqu'un a besoin d'aide sur mon code, je commenterais les parties non triviales

hum…

Plus sérieusement, avoir des commentaires bien fait ça permet aussi de générer une doc développeur (par exemple une javadoc) qui pourrait laisser un espoir à celui qui souhaite utiliser ton travail.

Je n'indente rien moi même,je laisse cette tâche ingrate à mon IDE/éditeur

Oui, moi aussi. Mais surtout je le configure pour que ça ressemble à quelque chose
Ici c'est quand même pas génial…

public class NanimDec 
{
    private CommandLine commandLine;
    private Nanim nanim;
    private int nbImageDecoded = 0;

    public NanimDec(CommandLine line) {
        this.commandLine = line;
    }

    public static void main( String[] args ) throws ParseException, IOException
    {
        Options options = new Options();
        options.addOption("i", true, "input nanim file");
        options.addOption("o", true, "output directory");

        if(args.length == 0) {
            HelpFormatter formatter = new HelpFormatter();
            formatter.printHelp( "nanimenc [args]", options );
            return;
        }

        GnuParser parser = new GnuParser();
        CommandLine line = parser.parse(options, args);

        NanimDec nanimDec = new NanimDec(line);
        nanimDec.decode();
        nanimDec.save();
    }
[...]
    public static boolean isFilenameValid(String pathname) {
          try {
            new File(pathname).getCanonicalPath();
            return true;
          } catch (IOException e) {
            return false;
          }
        }

Raaaa ! oui le code est propre icitte mais c'est parce que les tabulations sont remplacées par 4 espaces… 'achement malin ! http://bci.im/devnewton/fossils/nanim/artifact/7bac83ad82b5bbee417fc3b7456f604e98e31cf7

Histoire d'expliciter un peu plus :

• devant { au début du static main, c'est des espaces et non des tabulation. Ton code dépendant donc de la valeur des tabulations (je suppose 4 pour toi)
• au niveau de isFilenameValid tu as un sacré mélange d'erreur d'indentation, tabulations et espaces

Tout ça, c'est pas pour casser du sucre sur le code (d'ailleurs j'ai pas vraiment regardé ce que ça fait) mais juste pour pointer des choses qui font qu'un code donne, de mon point de vue, envie d'être utilisé voir y contribuer, ou non.
Et là, mauvaise indentation, aucun commentaire, ben ça donne pas trop envie.

(perso, pour mon style en java j'ai fini par passer aux conventions de Google, je trouve que ça va plutôt bien : http://google-styleguide.googlecode.com/svn/trunk/)

C'est tellement facile à faire que la quasi totalité des jeux utilisent une autre solution:

Ha, et pourquoi utilisent-ils cette autre solution plutôt qu'une solution du type de celle tu as envisagé ?
(vrai question)

Hum, à voir les critiques des formats existant, il ressort surtout l'argument peu répandu / utilisé.
En quoi ton nième format d'animation pourrait en faire un format plus répandu utilisé ?

Et sinon j'ai deux questions existentielles :

• tu ne commente jamais tes codes ?
• comment tu fais pour bosser avec une indentation de 8 caractères o_O

Ha oui, et comment tu gères le € sur un ISO-8859-1 ?

Tu ne le gères pas. Si tu as besoin du symbole € tu prends un autre charmap.

Ha ok.
Donc dans ce cas, j'ai mon beau système de fichier en ISO-8859-1 (ben oui, pourquoi pas finalement) et au milieu un fichier qui porte un nom en ISO-8859-15.
Ha ben merde, comment je fais ?

qui ne transcrivent pas en ISO-8859 peuvent être échappés facilement avec des antislash en code ou avec des caractères joker

Ben idem avec de l'utf-8 alors

console.log('\u00E9\u00E8\u00E7\u00E6\u00E5\u00E4\u00E3' +
  '\u00E2\u00E1\u00EA\u00EB\u00EC\u00ED\u00EE' +
  '\u00EF\u00F0\u00F1\u00F2\u00F3\u00F4\u00F5' +
  '\u00F6\u00F7\u00F8\u00F9\u00FA\u00FB\u00FC' +
  '\u00FD\u00FE\u00FF\u00D1\u00D2\u00D3\u00D4' +
  '\u00D5\u00D6\u00D7\u00D8\u00D9\u00DA\u00DB' +
  '\u00DC\u00DD\u00DE\u00DF\uFEC9');
// éèçæåäãâáêëìíîïðñòóôõö÷øùúûüýþÿÑÒÓÔÕÖ×ØÙÚÛÜÝÞßﻉ

A exécuter dans un navigateur qui comprend le js. Et hop, je viens d'écrire de l'unicode en ISO-8859-1. Alors, il est où le problème finalement ?

Heu… ben disons qu'il faudrait, au moins d'une certaine manière, que ça fasse un peu rêver.
Si t'es dans une simulation du genre, tu veux construire une nouvelle école (supaïr) dans un terrain vague et là le jeu te dis "Attention, si tu poses ton bâtiment icitte tu va détruire l'habitat de 2 abeilles, drame inconcevable ! Dégage sale pourriture de capitaliste !" c'est tout de suite beaucoup moins marrant…

les critères de prise de tête seraient différents

moui, mais faut aussi que ces critères intéresse un joueur…

Par contre, je me consacre à exécuter cela dans la vraie vie,

Ha ok, en fait ton jeu vidéo c'est la même chose que dans la vie ? Et tu demandes pourquoi ce serait moins amusant ? ;-)

À quand un jeu qui récompensera celui qui arrivera à contenter au maximum la population en respectant la nature, les paysages, les conditions sociales?

Quand un tel jeu pourra être amusant, non ? Je pense que si tu arrives à faire un tel jeu qui soit sympa, n'hésite pas à le publier ;-)

Sinon, moi je jouais à SimFarm, au moins tu as le côté nature (enfin presque)

on s'en sort souvent mieux avec une approche plus traditionnelle.

Et c'est quoi l'approche traditionnelle ?
Ne pas permettre d'avoir autre chose que de l'ascii ?
Ton problème de rennomage c'est la même chose entre ISO-8859-1 et CP-1252 par exemple.
Ha oui, et comment tu gères le € sur un ISO-8859-1 ?
Et comment, dans ton approche traditionnelle, tu gères un fichier coréen ?

En fait, ça serait pas mal que tu indiques quelle est l'approche traditionnelle car je pense que beaucoup de personnes seraient intéressées ;-)

Nan mais c'est n'imp là…
UTF-8 ça date pas de 2008 quand même, il est même surtout hallucinant qu'en 2008 des bugs pourris existaient autour d'unicode.
Et je parle pas du non support d'unicode aujourd'hui…

Une bonne lecture sur le sujet : http://french.joelonsoftware.com/Articles/Unicode.html

Ben on dirait pas puisque ton message mélange deux choses différentes et qui n'ont rien à voir (RAM du serveur et RAM d'un client)

Et, par rapport au message du dessus mais aussi au tien, qu'est ce qui indique qu'il n'y a qu'un seul onglet dans le navigateur et pas, par exemple, une autre fenêtre avec d'autres onglets dans ces 500Mo ?

Ou alors le 500Mb de RAM c'est au niveau de chrome, donc du navigateur, et non du serveur (et les valeurs 257 et 16 se place de ce côté)

Ca peut être pris en charge par un magicien (comment traduire wizard?)

assistant