./130 non conventionnel serais plutôt le terme, pas non propre, la propreté va de pair avec l'expérience

enfin, non conventionnel pour les règles de code actuelles, pas précédentes

chacun trouve sa lumière qq part, pour ma part c'est dans la manière de coder "à l'ancienne" :- )

RHJPP (./127) :
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)).

bien sur, dès que le projet est assez conséquent et touche à des chose bien définies, non semblable, tout doit être séparé

par exemple dans ce vieux code d'une de mes lib graphique, tout est découpé proprement, son, graphique, touches, ...

mais pour d'autre projets plus réduits (et non moins importants) par exemple celui ci tout est en un seul fichier, certes pas tellement commenté mais très propre tout de même, selon mes critères

bien sur l'objet apporte de la sécurité, la certitude que tout soit bien libéré comme il le faut etc ... mais comme dis plus haut l'expérience amène une certaine rigueur évitant des erreurs grossières,

il faut faire la part des choses entre taille du code, propreté d'écriture, et pertinence des choix, choix dictés encore une fois surtout par l'expérience, il n'y à pas de bonne méthode générale, il y en à par contre par problèmes à régler

RHJPP (./127) :
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é.

l'expérience permet de se passer de conception préalable, du moins en apparence, pour des choses simple on peu coder direct mais le papier + crayon est bien généralement incontournable, la réflexion avant l'implémentation est reine

des fois je vois du code ou le type à du passer plus de temps à commenter (pour des choses débiles généralement) qu'à vraiment coder voir concevoir, encore une fois il faut faire la part des choses

ensuite, concernant ton argument sur l'évolution, c'est un mauvais argument selon moi, quant tu développe qq chose, il faut penser bien sur à son évolution, mais dans le bon sens, un code écrit pour qq chose ne doit pas l'être pour autre chose, sinon cela est du hack, bien sur les projets et leur finalités évolues, que se soit durant la conception ou bien plus certainement par la suite, mais ton code n'à généralement pas été écrit dans ce nouveau but, par chance (ou intelligence de codage) des fois ca marche, mais des fois non, le temps c'est de l'argent, et le temps de conception est limité, au bout d'un moment il faut faire des choix, leurs pertinence est en rapport de l'expérience du dev (encore une fois ^^⁾ mais on ne peu et doit pas cracher dans la soupe par la suite si cela ne règle pas des question non posé dès le début, quant je doit concevoir qq chose pour un client je demande toujours les évolutions futures aux quelles ils aspirent, des fois le temps de conception sera doublé, et il faut alors faire des choix, mais des fois non, c'est le même temps de dev.