Actually, if you're browsing the code in Visual Studio, it's a hell of a lot easier to jump around the code if you have one class per file. All the main navigat

Actually, if you're browsing the code in Visual Studio, it's a hell of a lot easier to jump around the code if you have one class per file. All the main navigation UI is geared to the file level - the tree in solution explorer is all files. The tabs in the editor are lists of files. ctrl-tab brings up a list of files. You can bring up a new tab group and see two files side by side. So, yes, one thing per file is actually a pretty good idea. Sometimes it's fine to put multiple things into a single file, if there's a lot of small implementations... but for anything even mediumly big, it's good to give it its own file. It helps a lot with navigation. And yes, I know you can do "go to definition" etc, but if you want to go back and forth between code, separate files is a lot easier. It also makes source control a lot easier, because you can see a file changed and know immediately what it will and will not affect. Which is not to say that I don't think java got it wrong, it did, it's just that the problem is not with one class per file, but rather that the file heirarchy matters.