Je vais répondre en deux commentaires, sur deux points différents. Pour commencer, je vais parler du style.
Au niveau du code dense et de l'absence de points virgules, c'est juste une question de style. Que je ne défendrais absolument pas !
J'aime bien, mais je ne pense pas être capable d'imposer un tel choix (si peu orthodoxe, qui plus est) dans le cadre d'une collaboration. Il vaut mieux un code lisible par le plus grand monde. Si tout le monde dans le projet est d'accord pour ce style (ou si je veux développer en autiste et filtrer sévèrement les contributions pour les limiter aux personnes pas trop bornée :-°), un style de ce genre est ok, mais la plupart du temps on préfèrera un style éprouvé.
La raison pour laquelle j'ai utilisé ce style est surtout parce qu'il est permit par la factorisation (ça vient tout seul). Sans la factorisation, difficile d'omettre les accolades, et si on les met à un endroit, autant les mettre partout (c'est plus consistant).
Pour le passage du goog, on touche à la première remarque que je me suis abstenu de faire pour éviter un pâté :
le passage de tout ce code en closure vient du fait que ce morceau de code est écrit dans un style particulier, que je n'ai pas le contexte autour, et que le style du code en question est bien différent du reste de la librairie. La closure est là pour ne pas polluer l'espace de nom (ni le global, ni le goog), mais dans un projet qui a adopté ce style de manière officielle, l'espace de noms sera adapté de manière à éviter une closure de ce genre (les fonctions sont prisonnières de ce contexte, alors qu'une partie d'entre elles peuvent être, à condition d'un nommage moins ambigüe, partagée par tout le projet).
Éviter la closure est une remarque pertinente et importante : quand on parle de l'impact de la factorization sur les performances, on pense au coût des appels de fonctions, mais la gestion des closures est très coûteuse au niveau temps, par rapport à, par exemple, un objet javascript. (source : un benchmark que j'ai la flemme de chercher :-°). Un projet qui est pensé avec un code de ce style va donc éviter les closures (dans le cas de ce morceau de code, ça demande de renommer errorText en cantWriteError, par exemple, ou quel que soit le nouveau nom trouvé, tant qu'il est moins vague que errorText qui n'est acceptable que dans la portée locale de ce code).
Une chose qui pour moi est importante, plus importante que la quantité de commentaires, est la cohérence du projet. Un projet peut avoir des fonctions qui font en moyenne vingt lignes avec quelque commentaires, ou une cinquantaine/centaine de lignes très commentées, ou cinq lignes sans commentaires. Dans tout les cas (pour moi), un bon codeur va écrire un code lisible dans chacun de ces styles (enfin, s'il est bon dans ce style en question). Et un mauvais codeur va écrire un code illisible, quelque soit les précautions qu'on lui a demandé de prendre. L'important est que quand on travaille sur un projet, une fois qu'on s'est fait au style, on n'a pas à en réapprendre un autre totalement différent.
Le style que j'ai utilisé est très exigeant : les fonctions ne doivent pas faire plus de cinq lignes (j'ai pas compté, je juge à l'œil), ne pas dépasser la soixante dixième colonne de mon éditeur (en fait, une des lignes fait un peu plus, là, mais comme c'est un exemple…), et dans la mesure du possible, éviter d'avoir plusieurs expressions après un if. Si on est habitué à lire un code de ce genre, un code mal écrit devient très vite évident : fonctions trop longues, niveau d'indentation qui s'accumule… La seule incartade permise par ce style est un choix ridicule de noms. Et quand je code comme ça, je relis sans cesse mon code en me demandant : « est-ce que ce nom est vraiment pertinent ? ».
Ça ne veut pas dire que ce style est bon pour autant. Il me force à réfléchir énormément à ce que j'écris et à son sens, et quand j'écris comme ça, je corrige souvent plein d'erreurs. Mais c'est aussi un style qui peut s'apparenter à du code spaghetti (comme tu le dis : « Je trouve ça moins lisible car cela oblige à faire des allez retour. »), et qui peut avoir un coût à force de créer des fonctions ou des variables (À supposer que ce coût ne soit pas acceptable. Ça dépend de la fréquence d'appel du code, de sa complexité, et de l'environnement d'exécution.).
L'effet spaghetti est censé se retrouver mitigé par le fait que quand on est dans une fonction, on ne devrait pas avoir à aller voir ce que fait une autre fonction pour s'assurer que cette fonction fait bien ce qu'elle dit (donc, pas d'aller-retour). Ça, c'est dans le meilleur des mondes. C'est le résultat recherché. Mais le meilleur juge est le novice qui doit se plonger dans un code qu'il ne maîtrise pas.
Un ami m'a affirmé préférer mon style pour la découverte d'un code (il avait deux morceaux de code équivalents pour juger), car il avait sous les yeux la « preuve » (à condition de faire confiance aux noms) que la fonction fait bien ce qu'elle dit faire.
your mileage may vary
La chose la plus importante pour moi reste d'avoir un seul style dans le projet : je ne proposerais jamais ce code comme patch à Google, parce que s'il est le seul de ce style dans le projet, tout le monde va faire des efforts pour le lire – même moi, peut-être, si je lis en même temps énormément de code du même projet, écrit dans le style commenté de ce journal.
[^] # Re: Code auto-documenté
Posté par daeldir . En réponse au journal To comment or not to comment. That is the question.. Évalué à 2.
Je vais répondre en deux commentaires, sur deux points différents. Pour commencer, je vais parler du style.
Au niveau du code dense et de l'absence de points virgules, c'est juste une question de style. Que je ne défendrais absolument pas !
J'aime bien, mais je ne pense pas être capable d'imposer un tel choix (si peu orthodoxe, qui plus est) dans le cadre d'une collaboration. Il vaut mieux un code lisible par le plus grand monde. Si tout le monde dans le projet est d'accord pour ce style (ou si je veux développer en autiste et filtrer sévèrement les contributions pour les limiter aux personnes pas trop bornée :-°), un style de ce genre est ok, mais la plupart du temps on préfèrera un style éprouvé.
La raison pour laquelle j'ai utilisé ce style est surtout parce qu'il est permit par la factorisation (ça vient tout seul). Sans la factorisation, difficile d'omettre les accolades, et si on les met à un endroit, autant les mettre partout (c'est plus consistant).
Pour le passage du
goog, on touche à la première remarque que je me suis abstenu de faire pour éviter un pâté :le passage de tout ce code en closure vient du fait que ce morceau de code est écrit dans un style particulier, que je n'ai pas le contexte autour, et que le style du code en question est bien différent du reste de la librairie. La closure est là pour ne pas polluer l'espace de nom (ni le global, ni le
goog), mais dans un projet qui a adopté ce style de manière officielle, l'espace de noms sera adapté de manière à éviter une closure de ce genre (les fonctions sont prisonnières de ce contexte, alors qu'une partie d'entre elles peuvent être, à condition d'un nommage moins ambigüe, partagée par tout le projet).Éviter la closure est une remarque pertinente et importante : quand on parle de l'impact de la factorization sur les performances, on pense au coût des appels de fonctions, mais la gestion des closures est très coûteuse au niveau temps, par rapport à, par exemple, un objet javascript. (source : un benchmark que j'ai la flemme de chercher :-°). Un projet qui est pensé avec un code de ce style va donc éviter les closures (dans le cas de ce morceau de code, ça demande de renommer
errorTextencantWriteError, par exemple, ou quel que soit le nouveau nom trouvé, tant qu'il est moins vague queerrorTextqui n'est acceptable que dans la portée locale de ce code).Une chose qui pour moi est importante, plus importante que la quantité de commentaires, est la cohérence du projet. Un projet peut avoir des fonctions qui font en moyenne vingt lignes avec quelque commentaires, ou une cinquantaine/centaine de lignes très commentées, ou cinq lignes sans commentaires. Dans tout les cas (pour moi), un bon codeur va écrire un code lisible dans chacun de ces styles (enfin, s'il est bon dans ce style en question). Et un mauvais codeur va écrire un code illisible, quelque soit les précautions qu'on lui a demandé de prendre. L'important est que quand on travaille sur un projet, une fois qu'on s'est fait au style, on n'a pas à en réapprendre un autre totalement différent.
Le style que j'ai utilisé est très exigeant : les fonctions ne doivent pas faire plus de cinq lignes (j'ai pas compté, je juge à l'œil), ne pas dépasser la soixante dixième colonne de mon éditeur (en fait, une des lignes fait un peu plus, là, mais comme c'est un exemple…), et dans la mesure du possible, éviter d'avoir plusieurs expressions après un
if. Si on est habitué à lire un code de ce genre, un code mal écrit devient très vite évident : fonctions trop longues, niveau d'indentation qui s'accumule… La seule incartade permise par ce style est un choix ridicule de noms. Et quand je code comme ça, je relis sans cesse mon code en me demandant : « est-ce que ce nom est vraiment pertinent ? ».Ça ne veut pas dire que ce style est bon pour autant. Il me force à réfléchir énormément à ce que j'écris et à son sens, et quand j'écris comme ça, je corrige souvent plein d'erreurs. Mais c'est aussi un style qui peut s'apparenter à du code spaghetti (comme tu le dis : « Je trouve ça moins lisible car cela oblige à faire des allez retour. »), et qui peut avoir un coût à force de créer des fonctions ou des variables (À supposer que ce coût ne soit pas acceptable. Ça dépend de la fréquence d'appel du code, de sa complexité, et de l'environnement d'exécution.).
L'effet spaghetti est censé se retrouver mitigé par le fait que quand on est dans une fonction, on ne devrait pas avoir à aller voir ce que fait une autre fonction pour s'assurer que cette fonction fait bien ce qu'elle dit (donc, pas d'aller-retour). Ça, c'est dans le meilleur des mondes. C'est le résultat recherché. Mais le meilleur juge est le novice qui doit se plonger dans un code qu'il ne maîtrise pas.
Un ami m'a affirmé préférer mon style pour la découverte d'un code (il avait deux morceaux de code équivalents pour juger), car il avait sous les yeux la « preuve » (à condition de faire confiance aux noms) que la fonction fait bien ce qu'elle dit faire.
your mileage may vary
La chose la plus importante pour moi reste d'avoir un seul style dans le projet : je ne proposerais jamais ce code comme patch à Google, parce que s'il est le seul de ce style dans le projet, tout le monde va faire des efforts pour le lire – même moi, peut-être, si je lis en même temps énormément de code du même projet, écrit dans le style commenté de ce journal.