C# – Should we put classes, enums and other entities to their’s own files?

ccode-organizationnetproject

I had a discussion with our's company teamlead\architect on this topic.

He argues that it is easier to understand the large-scale project 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?

Best Answer

In my opinion:

Small enums and classes that are needed inside a bigger logical class can stay in its file.
But if the smaller classes and enums are used outside of that scope, you should have them separately (although if they are logically linked they themselves could be in the same file).
So I agree with him about the logical coupling.

Saying that, i must say that there are other alternatives, you can create logical folders inside a project to hold classes from the same logical environment or connections.
The IDEs today give you easy access and mobility throughout the solution with Go-To functionality, so finding the code isn't a problem.

Keeping logical components together (as long as they are really closely coupled) does have a big advantage when scaling. As the project gets bigger it tends to get more of a mess, and that's exactly what he's trying to avoid.

BTW, if you read Skeet's opinion closely you'll notice:

and assuming they're going to be used by other classes, make them top-level types in their own files.

Related Solutions

C# Events and Thread Safety

The JIT isn't allowed to perform the optimization you're talking about in the first part, because of the condition. I know this was raised as a spectre a while ago, but it's not valid. (I checked it with either Joe Duffy or Vance Morrison a while ago; I can't remember which.)

Without the volatile modifier it's possible that the local copy taken will be out of date, but that's all. It won't cause a NullReferenceException.

And yes, there's certainly a race condition - but there always will be. Suppose we just change the code to:

TheEvent(this, EventArgs.Empty);

Now suppose that the invocation list for that delegate has 1000 entries. It's perfectly possible that the action at the start of the list will have executed before another thread unsubscribes a handler near the end of the list. However, that handler will still be executed because it'll be a new list. (Delegates are immutable.) As far as I can see this is unavoidable.

Using an empty delegate certainly avoids the nullity check, but doesn't fix the race condition. It also doesn't guarantee that you always "see" the latest value of the variable.

C# – Problem in selecting constants of an enum class

The Language class is not an enum in C# terminology. It is an ordinary class with public const string fields. ROWLEX intentionally generates enum-imitating-classes instead of native enums for 2 reasons:

The value of an native C# enum is an integer, while a public const string field can take the URI of the OWL class instance.
The class can have one additional public static string that is "URI" which represents the class URI consistently for every single ROWLEX generated class.

That was the background. If I understood your question right, you had an issue binding the selected name displayed in the dropdown back to the URI, and you wanted to use the position of the element inside the array you created. I would not do it that way. DropDownLists typically have both ID and Value fields for every list item (can be named differently component to component). The ID is expected to be a unique object while the Value is expected to contain something human readable. Set the ID with URI of the "enum" field, and the Value as you have done. So this is how you populate your dropdown:

System.Reflection.FieldInfo[] resLanFields = typeof(Language).GetFields();
foreach(FieldInfo field in resLanFields)
{
  ListItem item = new ListItem();
  item.ID = field.GetValue(null); // takes the URI value of the const field
  item.Value = field.Name; // takes the name of the const field
  dropDownList_lang.AddItem(item);
}

And when the user made his/her choice, this is how you read the result out:

learningResource.hasLanguage = (string) dropDownList_lang.SelectedItem.ID;

Since there is implicit casting operator implemented on the ROWLEX enum-imitating-class (string=>Language) you can safely set your triple subject as a string. Should compile without issue. Simple, isn't it? ;)

Best Answer

Related Solutions

C# Events and Thread Safety

C# – Problem in selecting constants of an enum class

Related Topic