Re: Code auto-documenté

Bon, pas mal de choses à dire :)

Autant les ; en javascript sont discutables (rien que par leur côté simplement optionnel). Pourtant je les conserve pour deux raisons essentiellement, une bonne et une mauvaise.

• la bonne : on ne peux pas, toujours, les supprimer. Et on se retrouve avec des horreurs genre ;!function() {… Et ça franchement, c'est dégueulasse je trouve.
• la mauvaise : ça date du temps où on utilisait des minifieurs un peu trop bêtes : il ne faisaient que supprimer les commentaires et les espaces. Si une accolade manquait, si un point virgule manquait, c'était alors vraiment galère.

Par contre, je suis en général contre l'inline (les block sur la ligne de la condition) et contre l'absence des accolades. Mais ça c'est pour des raisons beaucoup plus terre à terre.

Déjà, c'est tout con, mais placer un point d'arrêt dans le bloc d'une condition c'est quand même parfois vachement pratique lorsqu'on debug. Et quand on a

if (shouldNotWrite(scriptSource, loadedFromBaseJS)) return false

Ben c'est juste pas possible comme ça :)

Le deuxième point c'est que, parfois, on va vouloir ajouter une ligne de log (par exemple). Et si on va un peu trop vite, en plein debug, on va avoir des choses sympa.

Genre

if (shouldNotWrite(scriptSource, loadedFromBaseJS))
 return false

va se transformer en

if (shouldNotWrite(scriptSource, loadedFromBaseJS))
 console.log('shouldNotWrite')
 return false

Et là, c'est le drame.

Ensuite, il y a simplement des cas où on ne peut pas s'en passer (plus d'une instruction) et on arrive parfois à :

if (shouldNotWrite(scriptSource, loadedFromBaseJS)) {
 console.log("shouldNotWrite")
 return false
} else
 console.log("shouldWrite")

Et là, franchement, c'est gerbant.

Et enfin, dernier cas, en obligeant les accolades et interdisant plusieurs instructions sur la même ligne, je vais éviter que quelqu'un me sorte un truc de ce genre :

using namespace std;
vector<int> myIntVector;
vector<int>::iterator myIntVectorIterator;
// Add some elements to myIntVector
myIntVector.push_back(1);
myIntVector.push_back(2);
myIntVector.push_back(3);
myIntVector.push_back(4);
myIntVector.push_back(5);
for(myIntVectorIterator = myIntVector.begin(); myIntVectorIterator != myIntVector.end(); myIntVectorIterator++) if (*myIntVectorIterator % 2) {
 cout<<*myIntVectorIterator<<" ";
 //Should output 1 3 5
}

(cet exemple est beaucoup plus sympa si vous n'avez pas de retour automatique à la ligne ;-) )

Et là, vraiment, je peux plus le voir ce type de code.

Alors c'est peut-être pas totalement fun mes diverses règles, mais pour le coup c'est réellement l'expérience qui parle. Ce que je veux dire c'est que tous ces cas je les ai rencontré en vrai, certains bien plus qu'une fois.
Et les conventions de code, si elles doivent permettre d'avoir un code élégant, doivent aussi s'assurer que tout fonctionnera au mieux, en prenant si possible en compte les erreurs humaines.

Après, sur le côté closure. Par exemple, le doc = goog.global.document est assez particulier, surtout que je n'en vois pas du tout l'intérêt. En plus, il est utilisé avant sa déclaration (ok, c'est pas forcément un problème, mais quand même).

De manière globale, je trouve qu'il faut plus d'effort pour lire ton code que la version initiale. Ok, chaque méthode est plus petite. Mais finalement c'est tellement morcelé que ça complexifie la lecture et la compréhension, alors que quand même, le code initial est plutôt simple :)

Avoir des limites genre pas plus de 5 lignes, j'en vois pas vraiment l'intérêt. A part mettre chaque instruction ou condition dans une méthode qui lui est propre, mais ça revient à découper pour découper là. D'ailleurs je trouve étrange de limiter la taille des lignes et en même temps vouloir tout mettre sur une ligne…
Par exemple, lorsque tu lis la méthode principale, tu n'as absolument aucune idée du fait que ça peut lever une erreur. Pour le savoir, il faut que tu fouilles dans les fonctions. D'ailleurs ta fonction, shouldNotWrite, n'est pas explicite. On ne s'attend pas à ce que ça lève une erreur non plus.

Idem, le côté not / false, c'est pas génial en général. A la rigueur si on avait du unless ça serait différent par exemple.