CrEv a écrit 4577 commentaires

• IDE générant automatiquement des prototypes de documentation de code

Ca c'est vraiment une fausse bonne idée.
Il suffit de prendre un code java et de voir le nombre de commentaires autogénérés (et par essence qui ne servent à rien puisque tout l'information provient du code) qui sont laissés tels quels. C'est pire que tout car ça donne l'impression que c'est commenté alors que non.

Ce qui fait commenter ? Prendre conscience du problème. Comment ? Etre confronté à des vrais problèmes.
En fait, c'est beaucoup l'expérience. Soit personnelle, soit d'un lead dev (ou autre). Mais bon, c'est plus facile à dire qu'à faire.

Être deux permet d'avoir quelqu'un qui te tape sur les doigts plus facilement et se laisser aller moins facilement

Hum, c'est pas tellement la vision que j'en avais…

Mais oui dans ce cas ce n'est pas le côté extérieur qui est recherché, mais plutôt le fait que les deux personnes ne vont pas penser exactement de la même manière (c'est bien là le but du pair programming). L'un s'attachant plus au code proprement dit, et l'autre plus sur l'intention, les objectifs, la doc justement.
Et en effet, ça ne remplace pas pour moi une revue de code.

Un bonne pratique peut être d'ajuster les commentaires lors de la revue de code car avec un oeil extérieur…

Ca peut être intéressant. A condition que ce soit fait assez rapidement tout de même.
Mais ça peut être une solution, dans ce cas il faudrait que le commentaire soit justement écris par la personne réalisant la revue (qui n'a donc pas ou moins le côté évident de la résolution)

Mais d'ailleurs, c'est aussi à rapprocher du pair programming. Car dans ce cas on a deux personnes, travaillant sur le même sujet mais en intervenant différemment. Un peu comme si, pour reprendre la présentation, chacun s'occupait d'un côté du cerveau ;-)

Hum, quel est le rapport entre trop laxiste et mauvais pour la doc ?

Après, le fait d'avoir plusieurs libs, ben c'est comme dans tous les langages pour le coup.
Et il n'est pas obligatoire d'utiliser des libs pour avoir du code durable, je dirais presque que c'est le contraire…

Je n'aime pas trop le commentaire interne. Cela empêche souvent d'avoir la fonction entière sur un seul écran

Ton écran fait quelle taille ? ;)

C'est surtout que ça dépend. Un commentaire au dessus de la fonction pour indiquer les objectifs de la fonction c'est normal. On peut certes y rajouter des informations "générales". Mais les détails doivent être au plus proche du code. Sinon c'est aussi le risque de voir apparaître avec le temps un décalage entre le code et les commentaires (et là ça devient vraiment galère)

D'ailleurs, parfois, on peut se rabattre sur le gestionnaire de sources pour glaner des informations. Mais, étrangement, un code non commenté n'aura que très peu de messages de commit parlant…
J'ai sous les yeux un projet, pendant 2 ans il n'y a eu aucun message de commit. Et très peu de commentaire (pour ne pas dire rien de plus qu'une javadoc automatique). Heureusement pour lui que le dev qui a écrit ça n'est plus ici.

Mais oui, les commentaires sont aussi (surtout ?) à destination des autres. Point que les gens négligent beaucoup trop, mais plus généralement c'est la question de la maintenance qui est souvent négligée.

Merci :)

Pour ce qui est de mélanger, fusionner documentation et code, il y a aussi tout ce qui tourne autour du literate programming. J'en avais d'ailleurs parlé dans mon De tout, de rien, des bookmarks, du bla bla #10 ainsi que dans un article « Literate programming, pour un code toujours documenté »

Mais il est vrai que les langages (et les applications) sont plus ou moins facile à écrire de la sorte.

Quel est le problème pour javascript ? Certe il n'y a pas beaucoup d'outils, mais il y a par exemple YUIDoc de Yahoo!. Ce que je regrette c'est que Google n'ai pas publié l'outil qu'ils utilisent pour Closure. D'autant plus qu'avec cette lib il est nécessaire de bien commenter (les commentaires incluent les notions de typage).

ça reste ici un dock avec une vue '3D'

Avec les stacks aussi.

Parce qu'il y en a beaucoup d'autres qui ont mis en avant ce type de dock ? Enfin avant que Apple le démocratise ? Pas vraiment à ma connaissance.

Après moi j'ai rien contre, mais lorsqu'on voit les screenshot on ne peut quand même pas nier l'inspiration. Maintenant c'est pas un mal, c'est aussi ce que certains veulent, et c'est pas un problème.

Nan mais par contre si on regarde le screenshot, il y a quand même plus que de l'inspiration (forme du dock, stack)

Non, ils ont certainement de bonnes raisons. Mais je les invite tout de même à essayer cette distribution que l'on peut façonner aux petits oignons

Ou alors ils veulent au contraire une distribution qui fonctionne, simplement, non un truc à façonner.
Parfois la meilleur distrib / le meilleur os c'est celui qui sait se faire oublier pour laisser place aux applications / documents.

Je ne vois pas l'intérêt de nier les défauts de javascript.

C'est pas une histoire de nier, c'est juste que tu ne fais rien avancer en disant "c'est mauvais".

Java aussi est mauvais et lent (enfin moins lent aujourd'hui c'est vrai). Ha tiens, comme js.

Ok, C++ est rapide (pas à compiler). Mais mauvais.

Bon, avec tout ça on a vraiment bien avancé, non ?

C'est vraiment le problème ça ?

Oui!

Ben je vois toujours pas le problème. On ne te demande pas de faire des jeux en js, on compile simplement ton jeu en js. Idem si tu fais du flash, du java, du c++ (faut bien le compiler), du .Net ou autre. Et dans ce cas, le fait que js pose problème à certains à cause de == et === c'est vraiment le dernier des soucis puisque tu ne l'utilises pas directement.

Sauf que côté serveur ou desktop, tu as le choix des armes. Si tu n'aimes pas java, tu n'es pas forcé de l'utiliser ou de t'en servir comme assembleur.

Non, c'est vrai. En fait tu utilise le bytecode de la jvm comme assembleur.
Tu n'exécutes pas de java, du compile du java en bytecode et tu l'utilises. Et d'ailleurs c'est la même chose avec groovy ou scala.

Ben là faut juste dire que le bytecode c'est asm.js. Et dans ce cas, faire du java, groovy ou scala et l'exécuter sur une jvm c'est comme faire du javascript, du coffeescript, du dart et l'exécuter sur un moteur js.

Si tu ne vois pas les tabulations c'est que ton éditeur est réglé pour que la tabulation fasse la taille de 0 caractère. Donc là c'est toi qu'il faut blâmer, pas quelqu'un d'autre.

La tabulation apporte un décalage horizontal. Et oui c'est visible.

On a un langage mauvais et lent

Ha oui, pour faire tourner un jeu 3D dans un navigateur c'est lent.
Heu…
C'est vraiment le problème ça ?
Pour faire ce qu'on lui demande initialement, il n'y a pas tant de problème de perf que ça (les problèmes de perfs se résolvent souvent par un meilleur usage de http par exemple)

Mais le côté mauvais, moi je dirais un peu comme java, avec son modèle objet qui casse franchement pas trois pates à un canard…

Pour ne pas l'utiliser, on s'en sert comme d'un assembleur.

Ca c'est récent tout de même… Et pour faire du jeux vidéo oui. Mais pour beaucoup de choses c'est loin d'être nécessaire.

Quand je parle de compiler, c'est js vers js, pas js vers asm.js

Et quand bien même. Tu n'as qu'à le compiler en js alors, il est où le problème ?
En fait, même le js se compile en js (et je parle pas asm.js). C'est d'ailleurs la solution pour avoir des perfs meilleurs avec une lisibilité correcte (et donc sans passer par des intermédiaires type dart, coffee ou autre)

Et sinon, ben il te reste à aider les développeurs de browser pour supporter d'autres langages.

faut voir. Tu peux faire text/javascript, text/vbscript, text/dart, text/ruby

(bon, de tête, les noms sont peut-être pas exactes)

Faut voir…

Dart ? Principalement pour un problème de performance et d'optimisation
TypeScript ? En effet, là c'est beaucoup relatif au typage
CoffeeScript ? En gros il voudrait du ruby dans les navigateurs

Maintenant si beaucoup de dev arrivaient à penser autrement que par classe (prototype) et autrement que à travers jQuery ça aiderait pas mal.

Je ne dis pas que le javascript est bien fait, loin de là. Il y a pas mal de casseroles qui trainent. Il y a des incohérences, des choses étranges. Des choses que je n'aime pas du tout. Et je me suis planté, comme tout le monde, sur des égalité undefined / null par exemple. Mais c'est loin d'être insurmontable. Tous les langages ont des trucs étranges. Mais j'ai surtout l'impression que beaucoup de monde fait du javascript à contre coeur, parce qu'ils sont obligés (oué enfin, vous êtes obligé à rien…) et qu'ils ne font pas du tout l'effort de chercher à apprendre.
Tu le dis toi même : j'ai rencontré le problème 100 fois et je m'en souviens toujours pas. Tu cherches vraiment à t'en souvenir ?

Donc bon, oui il y a des choses bien naze en js. Mais == / === n'est qu'une spécificité d'un langage, beaucoup plus simple, par exemple, que la gestion des pointeurs, la gestion de la mémoire, etc.

desole, mais non 0 == "0" n'a aucune bonne raison de retourner true

Ben faut croire que ça l'est pour des gens qui créent des langages pourtant.
Et dans un contexte orienté texte, il y a une bonne raison de le faire.
On peut trouver ça bien ou pas, mais c'est pas un oubli, c'est volontaire ça. Donc oui il y a une bonne raison de retourner true.

En général === ça veut dire strictement égal. C'est à dire égalité de valeur (0 et "0") sont égaux si on prend juste leur valeur) et égalité de type (number vs string)

(et d'ailleurs javascript n'est pas le seul langage avec un ===)

Le double not c'est, justement, une double négation. C'est !(!bla).

donc not(not(something) n'est pas forcement egal a something?
Ben c'est du propre dis donc.

Ben oui, et c'est le cas dans beaucoup de langages.
Dans beaucoup on définit ce qui a une valeur de faux.
Mais une valeur de faux n'est pas forcément "false" pour autant.

Donc en javascript 0, "", null, undefined ont tous une valeur de faux.
Donc ! donne vrai
Donc !! donne faux <- le bool false

Donc on peut ensuite tester des égalités (strictes) dessus.
Mon exemple était en effet très mal choisi.
En général, on va transformer un argument en booléen (pour savoir si une valeur non fausse a été envoyée). Et ensuite on va tester ce booléén, pour un booléen, réellement. Sans se soucier de savoir si la valeur était fausse, si c'était non renseigné, etc.

Oui, j'ai écris un peu trop vite l'exemple.
Le but est bien de traiter !!bla comme un booléen.

Il n'y a pas que sur les serveurs qu'on virtualise hein…
Il m'est arrivé d'avoir une machine de dev avec un xen. Le dom0 était mon système de base. Et j'avais plusieurs VM que je démarrais à la demande sous Xen.
Ca fonctionnait plutôt pas mal.
J'ai d'ailleurs fait la même chose à base de kvm, virtualbox (enfin là c'est un poil différent) ou du vmware.

Et après, je ne sais pas si c'est très utilisé, mais il est parfois aussi envisageable d'arrêter des serveurs pour baisser la conso globale lors de faible besoins. C'est loin d'être idiot, et la mise en veille peut s'avérer intéressante.

Pourtant le problème n'a pas changé entre temps hein. Et la réponse non plus puisque c'est tout ce qui est lié à la notion de faux.

Et d'ailleurs tout cela permet d'écrire des trucs sympa, comme les double not :

var plop = function(bla) {
  if (!!bla) {
    doSomethingWith(bla);
  }
};

« Convention over configuration »

— Plein de bonnes choses, telles Rails

« There's more than one way to do it »

— Perl

« Excplicit is better than implicit » est une des raisons pour lesquelles je trouve python inélégant et fait que je n'y accroche pas du tout contrairement à ruby, javascript, perl, go

En gros, la règle de base c'est que si tu compares à undefined, null, "", 0, true, false tu dois utiliser === (sinon le résultat n'est pas certain).

D'une part, je comprends pas pourquoi ces valeurs en particulier

Parce qu'il y a conversion implicite de type.

var _ = function(a, b) {
  console.log(str(a) + (a == b ? " == " : " != ") + str(b));
  console.log(str(a) + (a === b ? " === " : " !== ") + str(b));
};
var str = function(a) {
  if (a === null) {
    return "null";
  } else if (a === undefined) {
    return "undefined";
  } else if (typeof a == "string") {
    return '"' + a + '"';
  } else if (typeof a == "boolean") {
    return a ? "true" : "false";
  }
  return a;
};

_(0, "0");
_(undefined, null);
_(0, false);
_("", false);
_(1, true);

Le résultat donne :

0 == "0"

0 !== "0"

undefined == null

undefined !== null

0 == false

0 !== false

"" == false

"" !== false

1 == true

1 !== true

Donc si tu veux tester précisément si ta variable est non initialisée / inexistante ou null tu ne peux pas utiliser ==. Si tu veux tester si tu as une chaine vide ou rien, tu ne peux pas utiliser ==.

Le « pas certain » ne pose en fait pas vraiment de problème, il faut juste comprendre ce qui est vrai et ce qui est faux. Parfois c'est simple, il n'y a qu'un booléen (ou une expression) qui puisse être vrai ou fausse. Parfois c'est un peu plus complexe que ça. C'est comme == / equals en java (enfin le problème n'est pas le même, mais le fait de tester deux choses différentes, mais pas tout le temps)

Les gens qui ont permis des conversion implicites dans les comparaisons doivent être satanistes pour en vouloir autant aux autres développeurs.

Non. Il faut bien voir aussi que ce qui est traité en javascript est, initialement, essentiellement textuel. Par exemple, si je te demande de saisir un entier dans un champ d'une page web, je vais recevoir une chaine de caractère. De la sorte, traiter 0 et "0" de la même manière a du sens puisque initialement tu ne peux pas faire la différence. Cette souplesse a des avantages, et des inconvénients. Il faut juste l'apprendre et l'utiliser à bon escient. Comme toute spécificité d'un langage.

Et alors ?

== et === sont bien définies en javascript aussi. On fait bien la différence entre = et == alors pourquoi pas entre == et === ?
Si === s'appelait equals ça ne changerait rien au fait que si les développeurs n'apprennent pas la différence alors ils l'utiliseront mal.