13

My company's team lead\architect argues that a large-scale project is easier to understand if "entities connected by logic" are placed in one .cs file.

I quote:

  • "The whole structure of the logic and the interface and the class can be seen in one place, this is an argument which can't be refute. To see the same thing but with a bunch of files you need to use the tools, class diagram, R# for navigation, etc."

  • "Following the poor theory I might scream that an army of separated files is cool, but when it comes to making changes to the existing code, especially if you were not a writer of this code, it's very difficult to understand plenty of scattered files. So on forums, you can write that "one enum- one file", but in practice this approach should never be used "

  • "... As to the separation of code base between developers, nowadays it's not a problem edit simultaneously the same file. The merge is not a problem."

I heard and read many times that we have to create one .cs file per enum, class and so on and this is the best practice.

But I can't convince him. He says that he don't trust to any well-known programmers such as Jon Skeet. By the way here is Skeet's opinion on this topic: Where is the best place to locate enum types?

What do you think? Is there a real problem? Or is it a matter of taste and should be regulated by the coding standard of the organization?

Improve this question
4
  • You can't win'em all, even when you play the Skeet Card.
    – JeffO
    Commented Mar 18, 2013 at 18:59
  • 6
    In fairness, Jon Skeet's claim to fame is not being an excellent code craftsman, it's being willing and able to answer C# questions quickly and accurately (and he did literally write the book). And possibly never sleeping, although this is only a rumour. His opinion on this alone should not be enough, and his argument there is not a strong one. That doesn't mean he's wrong in this case, I'm just saying that your senior has a right to say "come to me with facts and reasons, not opinions."
    – pdr
    Commented Mar 18, 2013 at 19:05
  • 2
    I vote for one class per file, and any enums or interfaces which are only relevant to that class should be inside the class, not just inside the file. On the other hand, you should follow the company's coding standard, no matter how unreasonable it may be, because that's part of writing good code for your job.
    – Bobson
    Commented Mar 18, 2013 at 19:59
  • 2
    You could point out that StyleCop as a Visual Studio plugin has warnings if there is > 1 class per file
    – Kevin
    Commented Mar 18, 2013 at 22:35

2 Answers 2

Reset to default
23

There are a couple of flaws in your Team Lead's argument:

  1. Well-designed classes and enums are intended to be used anywhere in your project, not just where they may make sense logically.

  2. Classes and enums that are properly documented with XML comments are very self-describing, by merely hovering over the item referencing it.

  3. You can always get to a class or enum definition by right-clicking the reference and selecting "Go to Definition," so it really shouldn't matter where you put it.

  4. Putting objects together in a "logical" fashion is arbitrary (i.e. you have to think about what "logical" means. I'd rather expend those clock cycles doing actual programming).

Setting up each object definition in its own file creates a uniform, disciplined expectation of organization and structure, and doesn't raise questions like "why is this here?" That's a very nice thing to have.

If two or more objects are logically related, simply put them in their own folder in the Project Explorer.

Improve this answer
1
  • 5
    On another note, code merges suck. Sure, you can do them, but why, if you don't have to?
    – Robert Harvey
    Commented Mar 18, 2013 at 19:15
5

Most likely the team lead cut his teeth in an earlier era when right clicking and choosing "go to definition" wasn't an option. I know when I'm in heavy spike development mode I will grow pretty massive class files until I let resharper fix it for me.

In any case, if you wanted to take the team lead to task, ask him why these classes and enums aren't child classes and enums -- no reason to declare them as independent entities if they are truly dependent entities. This might help him think the fatwa through a bit.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.