robinHood (./126) :
moi je crayonne kevin pour le coup, rien ne m'énerve plus qu'une foret de fichiers et de classes

Ce n'est pas parce qu'avoir trop de fichiers est mauvais qu'il faut s'obstiner à tout mettre dans le même. Et pas besoin de faire de la programmation orientée objet pour ça, des ensembles indépendants de méthodes, de types, de classes ou de ce que tu veux devraient se trouver dans des fichiers ou dossiers différents. On devrait au moins ne pas avoir de code de l'un des ensembles entrelacé avec celui d'un autre. Il y a plusieurs raisons à ça, parmi elles : réutilisation du code, changement d'un élément simplement en respectant l'interface et aussi développement simplifié (on trouve plus rapidement une fonction déjà existante quand elle se trouve à un endroit logique, ça évite de l'écrire plusieurs fois (comme on en trouve dans le code dont Kevin Kofler a donné un lien (en fait, ce sont des lignes répétées plusieurs fois noyées dans le reste, car il n'y a pas de méthodes qui font des tâches simples dans ce code)).

Kevin Kofler (./122) :
Ce n'est pas une erreur, mais au contraire un design puissant qui permet des features uniques, et en particulier de faire ce qu'attend l'utilisateur (qui n'a pas été préalablement indoctriné par d'autres EDIs moins bien conçus), à savoir de compiler ce qu'il voit dans l'EDI, pas ce qu'il a enregistré auparavant.

C'est au contraire une erreur grave de conception (en lisant le code, on voit surtout qu'il n'y a tout simplement aucun travail de conception). On pourrait fournir exactement les mêmes fonctionnalités avec du code beaucoup plus propre et avoir ainsi beaucoup plus de facilités pour faire évoluer le programme vers des fonctionnalités auxquelles tu n'as pas pensé lorsque tu as établi ce design limité.