Is C# project file diarrhea the norm?

A C# programmer rewrote a Delphi 6 program (no GUI, just files-in-files-out grinding, about 50 procedures and functions totaling less than 1200 lines == 57kb keystrokes) that lives as a single .DPR file.

He delivered a project containing 58 files (52 of them .CS files) in 13 folders nested to various degrees, totaling over 330kb.

Is that typical of C# projects? What strategy do C# programmers typically use to decide how to chop up and organize their proj开发者_运维知识库ect?

---

Code-file size is a horrible metric to determine the worth of a project, especially in line-of-business projects. Three reasons for that:

1) Small code files are easier to understand than large ones, but this can lead to some repetition of certain constructs (using declarations, namespace declaration, etc.) and certainly adds to the number of files in the project.

2) Small classes are easier to understand than large ones. This is a major benefit for newcomers to the code. If they can wrap their head around any one class, they can expand their understanding outward from there.

3) Good code is larger than small code. When you add decent error-checking, documentation and descriptive method/variable names, your code is more resilient and maintainable, but also much larger. That's perfectly okay.

Now with that all said, of course there are plenty of cases where the code is big simply because the programmer doesn't know what they're doing. You'll be able to identify that by looking at the largest files; if you see a lot of repetition of precisely the same code... or if you see lots and lots of string concatenation.... or you don't see any comments at all (or the comments don't tell you anything useful) then you probably have some good old-fashioned code bloat on your hands.

---

It's more an artifact of the developer using Visual Studio IDE (VS) rather than an issue of C#/.NET itself. The tendancy, when using VS tools, is to put each class in its own .cs file because the Solution Explorer window shows files/folders in a tree-like structure allowing the programmer to visually target their classes quickly.

Also the Visual Studio Add New Item dialog encourages a one-class-per-file approach by generating a new file each time you add a Class to your project.

The namespace hierarchy of a program is usually mimicked using directory folders in Solution Explorer (although it's not required to match) but this is just another visual quickie.

Example:

_{(source: spaanjaars.com)}

If the programmer were to work outside of the Visual Studio environment you'd likely have much less diarrhea on your hands. Ewww...

---

Without seeing the actual code of the original or the new code I can't tell you if the new organization is properly designed code just by knowing the line count, method count, and file size. In C# I usually :

1. Separate each class and interface into its own files.
2. Static helper methods are grouped by function
3. I usually separate files into folders by layers. Ex. GUI layer, Business Logic Layer, etc...
4. Extension methods are separated by the class or interface they relate to or sometimes by function.

Now, the new code could be broken up to follow a more object oriented design, but I can't tell without seeing the code.

---

Delphi is a great language, but its not a magical language. So no, what you are seeing is not a typical scenario.

Without knowing anything about what your program does its hard to impossible to make any meaningful comment about why your programmer decided to a) rewrite it and b) why the disparity when he did.

I will say this though, its common that when developers do not understand someone else's source, and especially when they do understand the requirements they will choose to rewrite rather than refactor. It's something we see in this industry time and time again.