freem a écrit 5059 commentaires

J'ai aussi failli le relever tellement c'est gros: sur les 17 organismes, 4 ou 5 (juste le tiers quoi) sont la FSF :D
4 ou 5 sont des partis pirates de divers pays…

Je doute fort que cette lettre impacte, mais tant mieux si c'est le cas.

Exact. Pardon.

Lisaac battait le code C

Battait, ça veut dire que C a rattrapé Lisaac ensuite?

Et sinon, le C++ n'a pas ces problèmes il me semble, et pourtant les bench disent souvent la même chose: il est souvent plus lent que le C.

J'ai aussi vu ce bench, je crois :)
C'était un moment d'anthologie pour moi qui aime rire.

C'est marrant de dire qu'un langage mort est capable de faire mieux que les existants… pourtant, il y a pas mal de langages de niche (dans la catégorie merdique, j'appelle PowerBuilder!), donc je suis intrigué qu'il n'ait pas réussi s'il est meilleur (bien que ce soit très possible, je ne le nie pas).

Lisaac a été premier de ce benchmark

Ce benchmark est à 2 dimensions: taille du code (et pas expressivité) à l'horizontale et vitesse d'exécution sur la hauteur, si je ne me trompe pas?
Pour le coup (prêcher pour ma paroisse avec force mauvaise foi - comme ça c'est dit ;) - ne m'a jamais empêché de dormir) je remarque que comparer ocaml au C++ est intéressant en effet j'ai regardé sur du quad-core (C++ et les thread c'était pas ça, jusqu'au C++ après tout… toujours pas testé d'ailleurs) et je remarque qu'Ocaml est plus économe en mémoire. Sur 3 domaines. Equivalent sur 2, et il perds sur 5.

Niveau vitesse, il atteint C++ sur 2 domaines, les autres C++ gagne.
Code plus petit (de moitié) dans 1 cas, plus grand dans 2 cas, et équivalent dans les autres.

Pour le coup, je te remercie, ce bench est très intéressant, même si je m'en suis un peu servi pour embêter le monde mesquinement :)

Notes un peu plus objectives et de moins mauvaise foi:

• dans la config ou OCaml se place le mieux, c'est à dire x86 un seul coeur, il se fait moins démonter… Problème de compilateur en retard dans les autres domaines?
• je n'ai pas utilisé les graphiques pour comparer, ni les chiffres brut, mais la section " 2 : Are the OCaml programs faster? Approximately.". C'est celle qui m'arrange le plus après tout ;)
• je n'ai pas pu regarder la comparaison avec "shortest C++", je sais pas pourquoi. Dommage, ça m'aurait pas mal intéressé… rien que comparer shortest C++ avec G++C++ pour voir à quel point l'optimisation est utile aurait été sympa
• il n'y a que des algo de calcul, donc pas d'accès aux ressources, de gestion d'IHM, et caetera. Donc, comme d'hab avec les bench, résultats à n'utiliser que pour des optimisations des "zones de calcul".
• ils mesurent la taille du code en octets, en ayant enlevé commentaires et espaces, et en compressant le texte ainsi obtenu. Franchement… je trouve difficile de trouver une façon moins pertinente de mesurer la taille des codes.

En même temps, la souris, c'est juste le périphérique de pointage le plus connu, et qui a engendré les IHM graphiques telles qu'on les connaissait jusqu'a il y a peu…

Mouai, enfin, on touche quand même là à quelque chose de bien plus important qu'un nouvel OS… on parle du net en général!

Je n'arrive a rien trouver d'autre que les articles wikipedia sur lisaac… le site officiel n'affiche qu'une page avec sa propre URL en titre centré gris, le wiki à l'air HS, et les seuls trucs que je trouve à son sujet sont les endroits ou l'on peut utiliser son source… pas envie de fouiller dans du code source inconnu la :)
As-tu d'autres infos?

Pour OCaml… les seules choses que je lise sur wikipedia au sujet de sa vitesse, c'est que ça dépasse les 50% de la vitesse du C, et le passage ou il est dit que ses fonctions sont plus rapides que celles des langages impératifs contiens le mot théoriquement. Je sais qu'on ne peut pas forcément prouver (benchmark? Y'a toujours quelqu'un pour les renier…) qu'un langage est plus rapide qu'un autre, mais je me demande de quel top 10 tu parles?

En tout cas +1 pour avoir parlé de lisaac, il semble intéressant.

Ça fait quelques années que j'ai tendance à utiliser systématiquement des langages de haut niveau, et quand je vois des trucs comme ça,

Allez, j'ai envie de tomber dans ton troll:

Ca tombe bien, C++ est un langage de haut niveau. Il est aussi bas niveau, cependant. Donc moyen niveau selon wikipedia, parce qu'il intègre des éléments des 2.
Note quand même que, perso, je me passe très bien de l'allocation mémoire, y compris pour les collections polymorphes, grâces à boost::ptr_container.

C++

C++ (pronounced "see plus plus") is a statically typed, free-form, multi-paradigm, compiled, general-purpose programming language. It is regarded as an intermediate-level language, as it comprises both high-level and low-level language features.

quand je vois des trucs comme ça

Le truc que tu vois qui ne te donne pas envie, ça s'appelle le paradigme de la programmation générique et selon wikipedia, "C'est un concept important pour un langage de haut niveau car il permet d'augmenter le niveau d'abstraction du langage."

Faut pas confondre langage de haut niveau et langage simpliste :D

plus imbittable que le code C++: les erreurs retournées par le compilateur, avec un petit bonus quand la STL est impliquée et qu'il faut scroller dans le terminal pour retrouver le début de la dernière erreur…

Enfin un peu de vérité… un poil obsolète, mais malgré tout encore d'actualité. Essaies clang.

Pour clôturer ce message, le problème du C++ c'est pas le langage lui-même, mais la pauvreté de sa lib standard, qui a grandement été fixé par C++11 et devrait être encore largement amélioré dans 2-3 ans. En attendant, y'a boost.
Et pour les IHM, t'as le choix: MFC, Qt, GTK, WxWidgets…

Ou alors son échelle à un putain de palier nécessitant du matériel d'escalade ;)

Je pense qu'on arrive au stade de la fusée la :)

Mea culpa, j'aurais du vérifier l'assertion de "2011" faite avant moi :/

Bref, on verra. 😊

On verra dans au moins 4 ans, au minimum. 2 ans mini pour atteindre la prochaine stable, et mini 2 nouvelles années pour que la prochaine stable devienne old-stable.

A part ce point important, je pense que ça va durer longtemps la maintenance de sysvinit chez Debian (et gentoo pour le peu que j'en connais… je vais rester sur Debian, mais je pense que plusieurs des points suivants concernent aussi gentoo):

• c'est une distribution qui s'adresse à des gens qui aiment bidouiller eux-même ET qui visent la liberté et le choix. J'inclus la liberté par rapport aux licences, mais aussi par rapport aux tendances générales: les utilisateurs utilisant LILO ou n'ayant pas de DE ne sont pas rares sur la ml internationale.
• kFreeBSD est encore un peu jeune, mais j'ai bien l'impression qu'il attire pas mal de monde. Peut-être que cette impression est biaisée par le fait que moi-même, je me sens attiré…
• dans 4 ans, si systemd continue de rajouter des palanquées d'options, il sera devenu un bloatware. Pour Debian, se baser sur un bloatware ne sera pas acceptable: la distro qui se veut l'OS universel doit pouvoir marcher sur de vieilles machines.
• si ce n'est pas le cas, le travail de maintenance parallèle ne sera pas si gros que ça, surtout si des outils sont faits pour générer les script à partir des fichiers de systemd.
• c'est fou le nombre de gens qui n'apprécient pas les trucKit et dbus, l'air de rien.

Le très jeune projet « Debian GNU/kFreeBSD » (sorti avec Debian Squeeze, en février 2011) justifiera-t-il de rejeter systemd comme solution par défaut ? Ce choix impliquerait, pour les contributeurs Debian, une plus grande quantité de travail : il faudrait en effet maintenir SysVinit/initscripts.

Non. Même s'il n'est pas par défaut, la quantité de travail sera la même: déjà, pour les versions 6 et 7 de Debian qui seront encore maintenues, et ensuite parce que par défaut ou pas, les paquets sont maintenus. KDE, LXDE et XFCE ne sont pas les options par défaut, pas plus qu'i3, et ils sont bien maintenus…
La mise par défaut n'augmentera donc pas la charge de travail.

C++11 à justement intégré des outils qui permettent de simplifier les messages d'erreur: les assertions statiques

Sinon, je ne crois pas que le C++ ait un jour été destiné à être un langage de programmation pour débutant.
Pas plus que les design pattern ne doivent être employés sans réflexion (surtout pas même, ça te pourris un code très vite sinon), donc la réflexion qu'engage cet article me semble plutôt salutaire.
De là à qualifier les sources affichées de "template de haut vol" par contre, il y a un gouffre que je n'oserais pas franchir. Si toi oui, alors ne lis jamais le source de la STL fournie avec Gnu… (ça m'arrive régulièrement, mais je suis toujours largué quand je le fais)

J'avais un doute sur le fait qu'il était ironique ou pas… me suis fait tromper par le coup du code natif, et il me semblait bien avoir lu il y a longtemps qu'il était possible de le faire (même si c'est… bref, c'était aussi y'a 6ans).

C'est le matin :)

Tu codes tassé toi dis donc, ça coûte si cher que ça les lignes vides? :D

Sinon, autre version, avec une méthode supplémentaire à implémenter:

void visitBinaryExpression(BinaryExpression& expr) {
  Type *left = expr.getLHS()->MethodeSup(*this);
  Type *right = expr.getRHS()->MethodeSup(*this);
  Type *result = ComputeType(left, right);
  setResult(result);
}

class Type
{
  virtual accept(fooBar*)=0;
  Type* MethodeSup(FooBar* foo)
  {
    accept(*foo);
    return getResult();
  }
};

Pour le coup, la lisibilité de visitBinaryExpression est la même, il n'y qu'une seule méthode supplémentaire a créer.

Note que je suis pas sûr de la bonne équivalence du code, vu que ton getResult() ne semble lié à aucun objet. J'ai donc supposé un prototype genre "Type* TypeDerive::getResult(void)" mais ça reste une supposition.
Si c'est lié à autre chose, le même principe peut se faire aussi de toute façon.

Je pense aussi que tu vas lever l'argument de la méthode virtuelle pure qui empêche d'utiliser accept() sur Type, mais ce n'est pas parce qu'une méthode est virtuelle pure qu'il est interdit de l'implémenter. C'est juste les filles ont l'obligation de le faire (j'ai appris ça il y a quelques mois, j'ai testé vite fait et effectivement… mais je n'ai pas trop joué avec, pas eu l'utilité encore).

PS: j'ai l'impression d'avoir merdé quelque part… alors je m'excuse par avance -.-'

Mis à part ça tout le monde sait que Java gère l'héritage multiple, que l'héritage privé est possible, que les annotations de type sont préservées à l'exécution et que la plupart des compilateurs Java produisent du code natif…

Pas moi.
Je veux bien des sources d'ailleurs pour compléter ces lacunes?

S'il s'avère que c'est effectivement le cas, je risque de n'avoir plus que les unsigned à opposer :D (euhh… y'a pas encore, dis?)

roi c'est pas plutôt Retour sur Investissement ? (Return On Investment)

Dans un programme qui manipule des images, c'est moyennement crédible :) mais bon, c'est pas du code dont je suis fier… ça marche, c'est sûr, mais bon…

Je suppose que je mettrais justement le if/else dans une autre fonction, avec un nom qui indique ce que fait cette condition. myIntVectorIterator est un nom très long, est-ce qu'il n'y en a pas un plus court qui ait un sens dans le contexte actuel ?…

D'un autre côté, si tu as une boucle sur un ensemble de données appartenant à un conteneur (allez, un vector, soyons fous) ou tu n'effectue une action que dans un cas, il y a les algo du C++ (et j'oublie volontairement pour le moment le C++11 qui a introduit range_loop et lambda):

• for_each
• transform
• find_if
• …

Sachant que le reproche le plus populaire fait au C++ est la petite taille et le manque de fonctionnalités de la lib standard, j'imagine que les autres langages n'ont pas cette lacune?

for(myIntVectorIterator = myIntVector.begin(); myIntVectorIterator != myIntVector.end(); myIntVectorIterator++) if (*myIntVectorIterator % 2) {
    cout<<*myIntVectorIterator<<" ";
    //Should output 1 3 5
}

void print(int i)
{
  if(i%2)
    std::cout<<i<<" ";
}
...
...
...
  for_each(myIntVector.begin();myIntVector.end();print);

Je sais que cette ancienne méthode n'était pas appréciée (code déporté ailleurs, et syntaxe pénible quand on veut plus d'arguments due à l'emploi de foncteurs, entres autres) mais je trouve que ça réduit l'illisibilité de certaines (plus de la moitié des boucles for je pense) boucles de façon assez propre.
Pas les boucles for ou l'on incrémente plus d'un pointeur (toujours trouvé ça dégueu perso), ni les boucles où l'intervalle n'est pas connu avant l'exécution du corps, ni celle ou le pas n'est pas uniforme, par contre.
Donc, dès qu'on utilise un truc genre "exit" ou "return" au milieu de la boucle, des modifications du compteur/itérateur, ça n'aide plus.

Maintenant, si je prend Java, ou un C++ plus moderne (allez, va pour C++, moins de risque de me lourder):

for(auto i: myIntVector)
{
  if(i%2)
    std::cout<<i<<" "; 
}

Je pense qu'il n'y a nul besoin de commenter de tels codes (pourtant j'ai même viré le type de i, chose que je ne fais pas trop)…

(oui, je sais que je vais dans ton sens, mais pour moi on peut très bien se passer de commentaires explicites et avoir un code documenté. Même si parfois les commentaires aident.)

J'ai compris l'article, même si je suis assez septique sur les raisons d'utiliser la version template… mais un des commentaires plus haut à répondu avec un assez pertinent: ABI break restreinte (faudra que je réfléchisse un peu au comment du pourquoi, par contre, je n'ai pas encore pris le temps de penser en détail).

Par contre, il y a des "avantages" de la version template sur lesquels je suis vraiment dubitatif et ou j'aimerai une explication:

Autre avantage, si on ajoute une classe dans la hiérarchie et qu'on n'a pas mis de méthode par défaut, on tombera dans le cas de Base. Ce cas ne sera sans doute pas pertinent, mais ça compilera. Avec le Visiteur polymorphe, il faudra ajouter la méthode adéquate dans le visiteur sinon, ça ne compilera pas.

Justement, je trouve plutôt utile que le compilateur refuse de compiler quand le cas n'est pas pertinent, ça évite les bogues…

Mais on peut faire mieux et mettre le type de retour dans le template du visiteur.

Je ne vois vraiment pas l'intérêt? Quand j'ai eu besoin de visiteur, c'était pour effectuer un traitement sur les données (sur un arbre dans mon cas passé). Je ne parviens pas à voir de situation ou je voudrais récupérer une donnée sur l'acte de visiter, sachant que le type de donnée en question va varier en fonction de l'objet visité… enfin, je m'embrouille, mais bref, j'aimerai un exemple concret de l'intérêt de ce point?

Autre petit plus inspiré de LLVM et qui là, peut tout à fait s'appliquer au Visiteur polymorphe.

Pas vraiment un plus, puisque tu le dis toi-même, ça s'applique aussi à la version polymorphe?

Si je résume, on aurai la version template qui permet d'éviter d'avoir à utiliser la RTTI et de casser l'ABI, et la version polymorphe qui elle offre de meilleures performances?

Ce fut instructif de débattre avec toi.

De même.

Dommage qu'on aie quelques soucis de compréhension, mais ça n'est pas toujours évident à l'écrit de retransmettre exactement ce que l'on veut dire, entre les imprécisions de vocabulaire et celles de lecture (méa culpa pour avoir raté le mot évolution) :D

Bon, il semble que tu ne tentes plus de me contredire sur l'ensemble de mes propos, c'est déjà pas mal, alors je vais expliciter, sans imprécisions ce coups-ci, ma pensée.

Je te conseil de lire la dernière phrase du chapitre de ton lien

Bon, je vais copier coller le chapitre en question, et mettre en gras la phrase que j'ai utilisée et la dernière (que tu me demandes de lire), je pense que ce sera plus simple pour la compréhension:

Windows ME was complemented by NT-based Windows 2000, which was aimed at professional users. Both operating systems were succeeded by Windows XP with their features unified. All Windows ME support, including security updates and security related hotfixes, was terminated on July 11, 2006. Support for Windows 98 and Windows 98 SE was also terminated on that date. Microsoft ended support for these products because the company considers them obsolete and running these products can expose users to security risks.[41]

Many third-party applications written for earlier editions of Microsoft Windows, especially older games, run under Windows ME but not under Windows 2000. This fact has become less relevant with the sharp decline in popularity of Windows ME after the release of Windows XP, which features a compatibility mode which allows many of these older applications to run.

If an installation CD-ROM from the Windows 2000 family is inserted into the drive of a computer running Windows ME, the user is prompted to upgrade to Windows 2000 because Windows ME has an older version number than Windows 2000. While this is not technically so (Windows ME was released several months after Windows 2000), Windows ME is in fact derived from the older, monolithic MS-DOS codebase (Windows 4.x) while Windows 2000 is the first of the NT 5.0 family, making the latter an upgrade.

Windows 2000 cannot, however, be upgraded to Windows ME. If an installation CD-ROM from Windows ME is inserted while running Windows 2000, the user will receive an error message that Setup cannot run from within Windows 2000. The user is prompted to shut down Windows 2000, restart the computer using Windows 95 or 98, or start MS-DOS and then run Setup from the MS-DOS command prompt.

Windows XP, which is NT-based, became the successor to Windows ME. It also closed the gap between consumer Windows and Windows NT. In addition, no service packs for Windows ME were released.

Along with Windows 2000 from the NT family, Windows ME was the last version of Windows that lacked product activation.

Windows ME was the last Windows release to be based on the Windows 9x (monolithic) kernel and MS-DOS.

Ok, donc, en fait, ce que tu essayais de me dire, c'est que ce n'est pas la version familiale de NT2000, parce que ce n'est pas la même branche de noyau?
Si c'est ça, comme je l'ai déjà dis ("Quand je parlais de version familiale, c'était peut-être un raccourcis un peu rapide, puisque le kernel n'est pas partagé…"), j'ai été imprécis en parlant de version, et je l'ai reconnu sans le moindre problème.

Tout ce que je tente de faire accepter, depuis le début, c'est que:

• 2000NT était pour les entreprises
• ME était pour le grand public (d'où mon raccourcis bancal sur "la version familiale")
• que ME étant sorti après 2000NT, 2000NT n'a pas pu être financé par celui-ci (contrairement à ton propos)

Est ensuite venu le fait que j'ai dit que windows XP possède deux déclinaisons pour répondre à l'assertion fausse que XP aurait été la version familiale de 2000NT qui a été opposée à mon imprécision, l'une étant grand public et l'autre pour les entreprises.

Toutes ces opinions qui sont miennes depuis le début, sont manifestement corroborées par wikipedia, bien que je l'ignorais au moment de ma première intervention (que wikipedia disais la même chose, modulo mon imprécision sur le mot "version").

En espérant avoir clarifié l'ensemble de mon propos sans ajouter d'imprécision…

Je ne suis pas sûr de comprendre ce que tu veux dire?

Si j'ai une fonction de 50 lignes (j'ai rarement plus) qui s'appelle "printPage(int number)" le pourquoi appeler cette fonction est déjà commenté dans le nom, et on sait que tout ce qu'elle fera sera avec l'objectif d'afficher le contenu de la page number, non?

Après, logiquement, si tu modifies un programme, tu devrais savoir à quoi il sert, et en creusant couche après couche, si les noms sont corrects (pas toujours simple cela dis) le pourquoi devrait (conditionnel) se situer dans le nommage, pour moi…

Idem, si tu as une grosse expression type:

return (x*y+j<2?callFoo(x,y):callBar(j,k);

Si on y comprend rien c'est clairement parce que les noms sont foireux, et que le développeur à tout mis sur une seule ligne pour rien…

int FooBarCaller(...)
{
int ret;
if((x*y+j<<k%tmp)>2)
  ret=callFoo(x,y);
else
  ret=callBar(j,k);
}

Bien que plus lisible, on s'aperçoit encore une fois qu'on ne comprend rien, mais forcément avec des noms à la con… (en même temps, c'est pas un exemple tiré de la vie réelle)

J'ai un bout de code la (je n'irai pas dire que c'est super propre hein, et c'est de moi il y a quelques mois… :/):

void Camera::AutoCalibration(void)
{
...
...
...
    CvRect r; //will contain final values of used rectangle
...
...
...
    if(r.x && r.y && !InsideTolerance(r))
    {
        m_roi=r;
        SetSize(m_roi.width,m_roi.height);
    }
}

bool Camera::InsideTolerance(CvRect const &target)
{
    if(m_tolEnabled)
        return CheckSingleTolerance(target.x,m_roi.x,m_tolX)
            &&CheckSingleTolerance(target.y,m_roi.y,m_tolY)
            &&CheckSingleTolerance(target.width,m_roi.width,m_tolX)
            &&CheckSingleTolerance(target.height,m_roi.height,m_tolY);
    return false;
}
...
...
...
bool Camera::CheckSingleTolerance(double value, double base, double percent)
{
    return value*(1+percent)>base && value*(1-percent)<base;
}

1er constat: j'ai un commentaire qui explique le pourquoi de l'existence de la variable "r"… un meilleur nom aurait suffit. Pour m_roi, l'abréviation est un peu plus justifiée, mais pas terrible quand même (RegionOfInterest au cas où. Vu que c'est une classe qui manipule des images prises d'une caméra…).

2nd constat (où je voulais en venir au final):

if(r.x && r.y && !InsideTolerance(r))

ici, "InsideTolerance" ne sers qu'une seule fois dans tout le code, et sert justement à nommer le "pourquoi" de son code.
Les quelques lignes se traduisent en "si on a des valeurs non-nulles ou en dehors de la zone de tolérance, on les utilise comme nouvelle région d'intérêt.".

PS:
Le nommage pourrait vraiment être amélioré d'ailleurs… j'ai limite honte de foutre ça sur un forum… j'aurai aussi du diviser ce bazard en plusieurs classes, rétrospectivement. Pour le coup Camera fait clairement office de fourre-tout, ce qui aide pas du tout à avoir des noms cohérents et clairs: si j'avais encapsulé cette histoire de région dans sa propre classe, avec ses méthodes dédiées donc, l'ensemble aurait été plus simple à lire et comprendre.

PPS:
Le code complet de la fonction en question:

void Camera::AutoCalibration(void)
{
    if(!m_objectDetect)
        return;

    ObjectDetect();
    unsigned short decalX,decalY;

    CvRect r; //will contain final values of used rectangle
    r.x=10000;r.y=10000; //dumb values. I should have used a macro like INT_MAX in stdint.h, but VC9 doesn't respect C++03 standard
    r.width=0;r.height=0;
    for( int i = 0; i < m_Objects->total; ++i )
    {
        CvRect rt=GetObjectN(i);
        if( rt.height<= 0 || rt.width<= 0 ||rt.x<= 0||rt.y<= 0 )
            continue;//!\todo verify that following code (from an example on the web) is not useless

        //enlarge rt rectangle with decal values
        decalX=static_cast<unsigned short>(rt.width*m_decalX);
        decalY=static_cast<unsigned short>(rt.height*m_decalY);
        //calculate the final rectangle, which will contain both previous r rectangle and current rt rectangle
        r.x=std::min(rt.x-decalX,r.x);
        r.y=std::min( rt.y-decalY,r.y);
        r.width=std::max(rt.x+rt.width+decalX,r.width);
        r.height=std::max(rt.y+rt.height+decalY,r.height);
    }

    //ensure (x,y) contain the lowest coordinates
    if(r.y>r.height)
        std::swap(r.y,r.height);
    if(r.x>r.width)
        std::swap(r.x,r.width);

    //transform width and height into dimensions (they are actually coordinates)
    r.width-=r.x;
    r.height-=r.y;

    //checking if new roi should be applyed (tolerance and sigsegv fault checks)
    if(r.x && r.y && !InsideTolerance(r))
    {
        m_roi=r;
        SetSize(m_roi.width,m_roi.height);
    }
}

//checking if new roi should be applyed (tolerance and sigsegv fault checks)

comme quoi je commente quand même un peu. Mais ce commentaire aurait sûrement pu sauter si la méthode avait été proprement découpée et ne faisait pas le café. (je suis vraiment pas fier de ce truc)

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 :)

Je me suis dis la même chose, mais je pense que c'est parce que je ne suis pas habitué à ce style d'écriture.
Je pense que ça aurait été plus lisible si les définitions des fonctions n'étaient pas imbriquées. J'ai toujours trouvé absolument vomitif ce type de choses, et pour moi, même si les lambdas sont parfois utiles, je trouve qu'en abuser n'est pas vraiment une bonne chose.

En fait, je suis d'accord avec ton intervention, mais je pense que ce qui rend le code difficile a lire, au moins dans mon cas, est que j'ai plusieurs handicap:
* je maîtrise pas JS,
* j'aime les langages typés (pour moi, savoir qu'une variable est un entier, signé ou pas, par exemple, aide à comprendre son futur rôle: non signé? Ah, peut-être un index… signé? Probablement pas.),
* je supporte difficilement les lignes avec plusieurs instructions (sauf cas très précis, et jamais sur de boucles/conditions)

Mais toutes ces raisons qui font que je lis mal son code n'ont rien à voir avec la présence ou pas de commentaires.

PS: vive le C++11 pour le range loop, auto, et les lambda :p

Il faut toujours commenter le domaine des arguments acceptés, car en général le type seul ne permet pas déterminer le domaine de la fonction. Il faut aussi commenter les conditions d'erreur, particulièrement celles qui ne sont pas gérées.

En gros, tu prônes la programmation par contrat?

Celle-ci permets justement de virer pas mal de commentaires (enfin, pas trop pour le C, vu qu'on ne possède pas certains outils nativement comme les exceptions, mais…):

"my_structure* returnPointer();"

my_structure* returnPointer()
{
my_structure* ret;
…
if(ret==NULL)
generateSigSegv();
}

La, on sait que si on retourne NULL (0) on génère une sigsegv et le programme se plantera. Avant même d'essayer d'utiliser une valeur invalide, et pourtant je ne l'ai commenté nulle part.

Ensuite, le nom est redondant avec la signature de la fonction: on sait déjà, grâce au code, que la fonction retourne un pointeur… grâce au prototype, on sait même de quel type, d'ailleurs. Par contre, rien ne nous indique sur quoi le pointeur pointe…
my_structure* getVideoAddress() serait par exemple bien meilleur. On sait qu'on se récupère une adresse vidéo, sous forme d'une instance de type my_structure.

Déjà, ne pas utiliser d'abréviations: l'auto-complétion, s'pas pour les chiens.
Et finalement, utiliser des noms qui veulent dire quelque chose, de préférence qui se réfère au rôle de la variable/fonction/méthode/classe.
Cette phrase à le mérite de bannir les noms à 1 lettre, sauf cas particuliers: i, j pour les compteurs de boucle, x, y, z pour des coordonnées…

Il m'arrive d'utiliser le mot "ret" (abréviation) parce que return est un mot-clé, cependant. Tmp aussi, même si c'est rare et limité à de très petites fonctions/méthodes, et idem j'essaie d'éviter.

J'ai vu des conseils qui indiquent d'utiliser des noms pour les variables et objets et des verbes d'action pour les méthodes/fonctions, c'est pas trop mal, mais parfois limité quand on utilise l'anglais (print? Mais print what?) donc je dirais garder le coup du verbe d'action et le compléter si nécessaire (printPageNumber, ah, ok).

Ensuite, je pense que le reste c'est en fonction du langage et des conventions de l'équipe:
* si t'as pas de typage fort, la notation hollandaise n'est pas une mauvaise idée, sinon si.
* si le langage tends à utiliser camelCase, et que l'équipe veut faire du code qui soit aisément distinguable de la lib standard, on peut vouloir utiliser les _ pour séparer les mots, par exemple.
* si l'équipe préfère utiliser le français pour coder, l'utiliser.
* …

A noter: rien de tout ça ne doit être utilisé comme règle absolue :)