Zeph (./121) :
Avec un environnement de développement moderne tu peux en un clic (ou un raccourci clavier) aller à la définition d'une méthode ou d'une classe, et si le développeur n'a pas fait trop de zèle il n'y a pas 50 fichiers à parcourir, juste deux ou trois. C'est sûr que ça reste plus long que si la réponse était directement sous tes yeux, mais de toutes façons tu ne pourras pas avoir tous les chemins de code dans un seul fichier alors autant adopter une séparation claire. Où plutôt si, tu peux avoir tous les chemins de code dans un seul fichier en faisant exactement ce que tu fais et en se retrouvant avec des fichiers de 5000 lignes. Du coup au lieu de naviguer vers d'autres fichiers, tu fais des recherches au sein d'un même fichier pour essayer de localiser la partie qui t'intéresse au milieu d'un pâté de trucs sans rapport. Je ne trouve pas que ce soit tellement plus efficace, au contraire.

Si je regarde vite fait les sources d'un projet tiers pour voir ce qu'il fait, ou pour patcher un problème pour mon paquetage de ce projet, je n'ai aucune envie d'importer le projet dans KDevelop et d'attendre qu'il me calcule le cache nécessaire pour exactement ce genre de navigation (ce qui peut prendre quelques minutes pour un gros projet, surtout sur mon PC qui commence à dater), je regarde directement les fichiers avec F3 dans Krusader (voire sur l'interface web du SCM) et donc du coup, si, c'est très agaçant de devoir changer de fichier sans arrêt.

(sinon pour ./120 c'est une erreur de design, encore un problème différent mais ça ne justifie toujours pas cette horreur ^^)

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.