With C# 9 and the introduction of record a lot of boiler plate code was remove from pure data objects. And after watching a dotnet community video on YouTube where then “joked” about it’s time to have more than one record in each file it made me think.
I have a bunch of records that are basically data bearers in API communication, and in this project, I opted to put all of them in one file while testing a few things out. Now I am contemplating moving them all to its own file just because that is the way I used to do it.
Now I am simple interested the hear your take in this. Is it still considered bad practice to have them all in one file?
From some perspective it’s quite handy to group all related records in one source file when they for example are message data objects used in the same REST API. But I am still not convinced it’s good in the long run. I guess I am too used to have “one class in one file” (excluding some types of classes).
There are of course benefits in splitting them up, especially in regard to version control and changes for example, and the “one file one responsibility” view.
I had this question on StackOverflow, but since it’s opinion based that of course was the wrong forum.
Putting multiple small records (or structs) into one single file is not “generally bad” (as almost nothing in software engineering). However, you should check the following preconditions:
-
you don’t mind that you cannot navigate to a certain record by just selecting its file
-
the total file size will be reasonable (IMHO less than 2000 lines, ideally less than 1000 lines)
-
you don’t mind that your records don’t have an individual history in version control
-
you don’t expect the number of merge collisions to increase significantly because of multiple persons working on different records in parallel.
-
the one-file approach does not introduce additional undesirable dependencies between unrelated components
-
this does not product large bureaucratic efforts in your organization to explain this to other team mates
Under these conditions, using one file for a lot of similar records is not a problem.
For code that is generated or code that is almost never changes, it is okay to put it in a single file. It doesn’t matter one whit to the compiler.
For code that is under frequent maintenance, separate files eases source code management. When everything is combined in one file, it’s hard to tell from source code history when someone adds a record type, removes a record type, or modifies an existing one: they all result in the same kind of commit. In contrast, if you use separate files, a new record type will show up as an “add” commit and the removal of a record type will show up as an “rm” commit.
Also, if everything is in one file, and someone decides to rearrange the records within the file, it can cause a confusing merge, or make an automatic merge impossible. (To alleviate this I suggest putting the records in a consistent order, e.g. alphabetical from top to bottom, and ask everyone else on the team to do the same).
Other than that it is really up to your team’s preference.
You want to organize your code in the best way. Would you rather have twenty separate source files, or one still not very large source file? I personally love not having header files in Java and Swift which reduces the number of files by half.
(Swift interestingly has no “friend” declaration like C++, but it has “file private”, that is things are only accessible within a source file. Kind of forces you to put very closely related classes into one source file, reducing the number of source files. But then Swift also has features to split a class into several files).
So I’d put things into one source file when reasonable.