196

I follow this rule but some of my colleagues disagree with it and argue that if a class is smaller it can be left in the same file with other class(es).

Another argument I hear all the time is "Even Microsoft doesn't do this, so why should we?"

What's the general consensus on this? Are there cases where this should be avoided?

Beska
  • 12,445
  • 14
  • 77
  • 112
Joan Venge
  • 315,713
  • 212
  • 479
  • 689
  • 1
    possible duplicate of [C# classes in separate files?](http://stackoverflow.com/questions/144783/c-sharp-classes-in-separate-files) –  Mar 12 '15 at 16:21
  • 1
    See also: http://programmers.stackexchange.com/questions/121365/what-naming-convention-for-c-file-that-contains-multiple-classes/121366#121366 – George Mamaladze May 24 '15 at 08:52
  • I see this is closed as opinion-based, however, it really isn't opinion-based in practice. There are issues with check-ins and merges or pull requests, visibility, readability. Now there are times to have multiple classes in the same file, but they should be rare or you will have problems. For example, in practice, it increases the chances of merge collisions, clutters source control history, causes lost history when you split the files, etc. None of those problems are opinions, they really exist. – Rhyous Jan 24 '23 at 17:12

30 Answers30

294

I hate it when people think in absolutes and say you should never do this or that with something subjective and nit-picky like this, as if we all need to conform to someones stupid idea of right and wrong. Bottom line: having more than one class per file is totally fine if it makes sense. By makes sense I mean things like:

  1. Makes the code easier to digest and maintain
  2. Makes the solution less annoying (scrolling through countless unnecessary files) and less slow
  3. The dev team is okay with it as a local coding practice

A really good example of why I may want multiple classes per file:

Say I've got a few dozen custom exception classes, each one is a 4 liner, I could have a separate file for each one or I could group the exceptions and have a file per group. For me what seems the most rational/pragmatic approach is to group them, and just have a few files, because it's more efficient time/coding wise (I don't have to right-click -> Add Class, rename, 50 times), it keeps the solution less cluttered and better performing.

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
James
  • 12,636
  • 12
  • 67
  • 104
  • 98
    +1,000. Understanding the rationale for best practices and thinking twice before violating them is great. Slavish adherence is evil. – dsimcha Mar 12 '10 at 19:06
  • Sometimes just "making sense" or being okay with something doesn't allow for additional benefits gained by making the shift. At other times it does. – John K Mar 12 '10 at 20:19
  • 1
    Thats true, emphasizing the "other times it does". For this specific topic there are good reasons for doing one or the other on either side of the equation. In other words there is not a right or wrong answer here, and the dev writing the code ultimately needs to make the decision and not feel bad for his/her choice. – James Mar 12 '10 at 20:42
  • 22
    *A few dozen custom exception classes*? Isn't that the real source of the problem? I don't just mean to be nit-picky here: I think most of the time people want to combine classes into a single file, it's because they're needlessly creating too many types. (Having said that, perhaps there is an actual case where a few dozen custom exception classes make sense). Numerous small, no-op classes are normally a sign of a bigger problem. – Jeff Sternal Mar 12 '10 at 22:01
  • 17
    I agree with you for the most part. But exceptions are a special case. Because a properly architected system needs to have proper exception handling to deal with all the cases that yield legitimate errors, most of the best practice articles i've read emphasize the need to create specific exceptions (and some times you need a lot of them to cover the all the business rules on a large project) so that you don't end up catching system.exception which isn't proper exception handling at all. – James Mar 12 '10 at 22:12
  • 7
    I agree that you should not slavishly follow some guideline without a good reason, however I disagree with the fact that you should have more than one class in a file. For me the file should be named after the class and not contain more than one. Some languages (java being one) make a note of actually enforcing that the class is in a file with the file name matching the class name. For me it makes it easier for newcommers to navigate so for that reason I believe that the one class per file is the right thing to do – krystan honour Mar 14 '10 at 12:45
  • 5
    Keeping one class per file and keeping file name and class name in sync is a convention, just like naming variables. Visual Studio is very well tuned for this approach. It is easier for source control systems, and developers that are added in the middle of the project. They'll intuitively search for the file name matching the class name. – Oybek Oct 27 '13 at 15:09
  • 1
    @James, "scrolling through countless unnecessary files" - this sounds like you have never heard about things that people call `folder` or `directory`. People actually use those weird things to organize the codebase structure. – Victor Yarema Oct 23 '18 at 12:38
  • @James, there is no evidence that "more than one class per file" "Makes the code easier to digest and maintain". You simply state this here without any argument. It is not true just because you think so. – Victor Yarema Oct 23 '18 at 14:03
  • Nested classes is one feature of the language that would be unavailable to strict one class per file adherents. – Paul Childs Jan 10 '21 at 22:11
  • I can understand that for some people it is easier to have like 6 types which are 4 lines each in one file. But those are from my experience, the same people who end up with 2-4 classes in one file causing the file to go past 1k lines of code and becoming completely unreadable. "okay this method is called here, a wait i am in the wrong class" – Welcor Feb 01 '23 at 17:45
185

One class per file also gives you a better idea of what each check in is changing without looking at the diffs of the file.

Mark
  • 9,966
  • 7
  • 37
  • 39
  • 5
    More classes in the same file enhances the diff between related classes in only one operation. – Luca Mar 12 '10 at 19:02
  • 3
    Proper diff viewers let you view all diffs of one commit. – Dykam Mar 12 '10 at 19:11
  • 50
    I'm not entirely sure how this particular answer is THE answer to the question(s) of the original post. Sure it provides A reason to keep 1 class to a file (though Luca and Dykam make good points), but it doesn't reflect general consensus or provide cases when it should be avoided. – Robert Davis Mar 12 '10 at 21:07
  • 6
    Best practices don't exist, if you believe in best practices understand they only apply to a given context. As other responses point out there are times when this rule will actually create less maintainable code. As tools get better this rule really becomes less relevant as its much easier to find classes and types within an project. – abombss Oct 04 '11 at 14:48
80
static bool GeneralRuleShouldBeFollowed(IGeneralRule rule, IUseCase useCase)
{
    return (rule.Overhead(useCase) 
            < My.PersonalThresholds.ConformismVsPracticality);
}
cHao
  • 84,970
  • 20
  • 145
  • 172
Jeremy Bell
  • 5,253
  • 5
  • 41
  • 63
51

I sometimes group more than one class within a file if they are tightly coupled and at least one of them is very small.

General 'best practice' is to have one file per class.

Phil Rykoff
  • 11,999
  • 3
  • 39
  • 63
  • 7
    If you recognize that they're coupled, why aren't you decoupling them? – The Matt Mar 12 '10 at 18:56
  • 41
    @The Matt: It's called avoiding overengineering. If you have a few tightly coupled classes and decoupling them would add a lot of complexity compared to the amount of practical flexibility it provides, then what's the point? – dsimcha Mar 12 '10 at 19:04
  • 10
    Sometimes I have like basically "data" classes that are used only by this one class, so I usually put the data-class in the same file as the user because the datac-lass usually has little to no logic itself and it seems like a waste to create a new file for it. – Earlz Mar 12 '10 at 19:11
  • 3
    @The Matt: Sometimes there are helper classes that I would argue as coupling-acceptable. They reduce the complexity for part of another class but still facilitate a very specific purpose to that class. – Jordan Parmer Mar 12 '10 at 19:11
  • 2
    @jordan, earlz: i spoked about exactly these types of classes :-) sometimes it just doesn't make sense to decouple classes. – Phil Rykoff Mar 12 '10 at 19:23
  • 2
    I do this at times myself... although I generally now create child classes under the main class to encapsulate this relationship. For instance, a List type object which contain SubNodes. – Nick Mar 12 '10 at 19:38
  • 6
    @TheMatt: Decouple this: http://msdn.microsoft.com/en-us/library/system.diagnostics.debuggervisualizerattribute.aspx Coupling between modules is bad, but collaboration between classes within a logical feature is unavoidable. – Ben Voigt Mar 12 '10 at 19:41
  • 2
    @dsimcha The point is that by decoupling you should be reducing the complexity. The 'complexity' you're referring to must be navigating physical files on disk because all we're talking about is the physical location of the class. So its unclear to me why separating two classes from the same physical file in anticipation of reuse is going to add complexity. Sounds more like laziness. By that reasoning, if more files is more complex and that's what you want to avoid, you should just shove all your code into a single file. – The Matt Mar 12 '10 at 22:03
  • 1
    I generally always keep strongly typed collection classes in the same file as the class the collection is composed of, especially if there's little extended logic to the collection class. – Chris Mar 12 '10 at 23:19
  • @js1 I'd prefer to use classes for their pass-by-reference semantics (though I've used structs in the past for some tasks as well) – Earlz Mar 11 '11 at 23:11
27

Beyond hypothetical arguments and focusing instead on Windows .NET with Visual Studio IDE and growing software projects, it just makes sense in this context to have one class per file.

In general, for visual reference nothing beats one class per file. Really.

I don't know if Microsoft does or doesn't do the same, however they did create the partial keyword to split one class over multiple files (this is even more severe). It's often used to split the auto-generated designer code from your custom code in the same class (but sometimes is used to allow different developers to work on the class at the same time via different files). So Microsoft does see benefits of multiple files and everybody has multiple file organization thoughts in mind for sure with .NET.

For nested classes you have no choice but to use one file, or at least the first parts of the classes in them. One file is necessary and fine in this case:

class BicycleWheel {
    class WheelSpoke {
    }
}

Otherwise why would you keep multiple classes in one file? The argument "because they're small" or associated with each other doesn't hold much water because eventually your classes will be associated with other classes. Ultimately you can't easily infer in-file organization of objects based on their usage especially as software continues to grow.

Additionally if you use folders for namespaces then you'll never have a class filename clash. It's also convenient to locate a class by filename on the file system when not inside a development environment like Visual Studio (e.g. if you want to quickly edit a class with Notepad or something quick/light).

So many good reasons...

Wayne Koorts
  • 10,861
  • 13
  • 46
  • 72
John K
  • 28,441
  • 31
  • 139
  • 229
  • Thanks, what do you mean by "at least the first parts of them"? You mean you can also separate nested classes? – Joan Venge Mar 12 '10 at 19:30
  • 1
    That's a indirect reference to the `partial` keyword I mentioned. – John K Mar 12 '10 at 19:32
  • 2
    For the record nested classes can be `partial` http://msdn.microsoft.com/en-us/library/wa80x488(VS.80).aspx I looked this up out of curiosity. – John K Mar 12 '10 at 23:08
  • This only goes to show that the default view should be logical (namespace/class) and not physical (files). – David Schmitt Mar 28 '10 at 20:58
  • @DavidSchmitt that is what Class View is for in Visual Studio. – Zack Nov 17 '15 at 17:13
  • `partial` keyword was designed to allow merging auto-generated code with hand-made code. [See Eric Lippert's info on "partial"](https://blogs.msdn.microsoft.com/ericlippert/2009/09/14/whats-the-difference-between-a-partial-method-and-a-partial-class/). Quote: `The motivation for this feature was machine-generated code that is to be extended by the user by adding to it directly. (...)What if it is re-generated?` Also, note that reasons regarding separating classes he says as "**sometimes** it's nice to ", not "have to". – quetzalcoatl Aug 04 '17 at 16:09
17

In the vast majority of cases, I follow the one class per file rule. The only exception I regularly make is the definition of an enum that is tightly coupled to a specific class. In that one case, I will frequently include the enum's definition in that class' file.

Greg D
  • 43,259
  • 14
  • 84
  • 117
13

I, too, believe there should be one type included in a single file.

There is one exception to this rule that must be mentioned: Having two classes that differ only by a generic argument such as:

RelayCommand

and

RelayCommand<T>
Wayne Koorts
  • 10,861
  • 13
  • 46
  • 72
Andrei Rînea
  • 20,288
  • 17
  • 117
  • 166
  • Do you know the workaround to make StyleCop happy in this case? – George Polevoy Apr 25 '12 at 17:58
  • Disagree, there is another convention for generic classes, Foo`1.cs for `Foo` and Foo`2.cs for `Foo`. – Oybek Oct 27 '13 at 15:11
  • @Oybek : What if I have Foo, Foo and Foo? Now what? – Andrei Rînea Oct 28 '13 at 14:52
  • 1
    @AndreiRinea It is impossible to have `Foo` and `Foo` within the same namespace. But if the namespaces differ, they are usually in different folders. Thus for `Foo` and `Foo` it should be Foo`1.cs and for `Foo` Foo`2.cs. But still one class per file. – Oybek Oct 28 '13 at 15:02
  • I thought you can have a Foo and Foo in the same namespace if you include `where` statements to a specific interface in one or both generics, but apparently this isn't the case. I suppose this makes sense with multiple interfaces on a single class. – RyanJMcGowan Jan 12 '14 at 04:11
  • I used to call my files e.g. Foo{T}.txt and Foo{UT}.txt in this scenario. – Jon Rea Sep 16 '15 at 10:37
11

Really, this boils down to personal preference. Everybody will say "one class per file", but we all have our reasons for avoiding that in certain circumstances. I used to have a large project that had about 300 different enums. No way am I going to have 300 seperate files, one for each class, when some of the enums only were tri-state.

Also for people that can't find certain classes if they aren't all in files named after what they are, is there a reason you don't use Find looking in the entire solution? Using Find saves me valuable time scrolling through Solution Explorer.

Wayne Koorts
  • 10,861
  • 13
  • 46
  • 72
Jason M
  • 512
  • 2
  • 8
  • Re: find - when I'm looking for a type's definition, I don't want to see where it's used. Besides, find takes significantly longer than scrolling through an alphabetically sorted list of files I've probably already divided up (by namespace). – Jeff Sternal Mar 12 '10 at 22:14
  • 1
    I notice you've indicated you're working with something you've divided up by namespace. We're not all lucky enough to always work with projects we've been able to manage, unfortunately. – Jason M Mar 15 '10 at 19:10
6

No matter how lightweight the content, I think one class / interface / etc. per file is essential.

If I'm working on a big solution in Visual Studio I want to be able to see the files and not have to delve inside to see. Even with navigation tools like ReSharper, I want a 1:1 mapping.

If you find a lot of source files with little or no content (maybe extending a class but adding nothing to it) then perhaps you should rethink your design.

Wayne Koorts
  • 10,861
  • 13
  • 46
  • 72
Mike
  • 6,149
  • 5
  • 34
  • 45
  • If you are in Visual Studio, just use the Class View for that 1:1 mapping it is much more accurate. – Zorkind Feb 26 '21 at 19:28
5

The StyleCop tool for C# has standard rules that require no more than one top-level class in one namespace (plus any number of interfaces, delegates and enums in that namespace).

In cases of two or more classes where the second and subsequent classes are only ever used by the first, those could and should be inner classes, visible only to the consuming class.

Steve Gilham
  • 11,237
  • 3
  • 31
  • 37
  • 3
    When you say "no more than one top-level class in one namespace", you mean in one `namespace` block, right? – Daniel Pryden Mar 12 '10 at 19:25
  • 1
    The rules alluded to are SA1403: A C# document may only contain a single namespace. SA1402: A C# document may only contain a single class at the root level unless all of the classes are partial and are of the same type. – Steve Gilham Mar 12 '10 at 23:02
  • The rules you quoted do not suggest restricting a namespace to one class. Obviously, a namespace can be spread over multiple files that each contain a single class. – MarredCheese Dec 02 '21 at 03:35
5

I find that grouping a class with it's standard factory class in the same file is very useful.

Robert Davis
  • 2,255
  • 2
  • 21
  • 21
5

I would normally have one class per file but you would normally have to use your discretion to see if the file could contain related classes e.g. grouping your exceptions which can be re-used by yourself and other developers. In this case, the user only needs one file to be included rather than multiple files.

So the point is: discretion should be used!!!

Wayne Koorts
  • 10,861
  • 13
  • 46
  • 72
akapet
  • 31
  • 3
4

In larger solutions I think it is very valuable to have one class per file and that the file is named the same thing as the class. It makes it much easier to locate the code you need to work in.

Chris Clark
  • 4,544
  • 2
  • 22
  • 22
  • I find this argument less valuable with tools like ReSharper. I Do CTRL+T and start typing the name of the type I'm looking for. – Mark Mar 12 '10 at 18:51
  • 3
    Yes, but do you want your application structure to be dependent on a third party tool? – magnus Mar 12 '10 at 19:01
  • 1
    @magnus I wasn't saying this isn't a reason not to do it, but a less compelling of an argument for someone to do it. – Mark Mar 12 '10 at 20:23
4

Sometime one class per file, but...

When multiple classes are stricly related, more than one class in the same source file is, IMHO, BETTER than dedicating a short source file to each class. The source is more readable and compact (and using #region the same source can be be more structured than before).

Consider also that sometimes it's NECESSARY to spread the same class across different files (using partial), since having a 20000+ line source file is not handy even with the RAM I have available (but this is another question).

Wayne Koorts
  • 10,861
  • 13
  • 46
  • 72
Luca
  • 11,646
  • 11
  • 70
  • 125
  • Of course, you should try to avoid having a class with so many lines of code. I'd say even 1000+ is getting too large. I also realize this is not always possible in legacy code. – Peter Jun 08 '11 at 14:51
  • If you try to generate source code (my case is the generation of C# binding for OpenGL from its specification, having thousands of entry points) it's difficult to think a little class for a lot of amount of data... – Luca Jun 08 '11 at 15:50
4

One reason for putting multiple related classes in one file is so that the poor bastard who uses your API doesn't have to spend half a day typing import declaration boilerplate and the poor bastard who has to maintain the code doesn't have to spend half a day scrolling through import declaration boilerplate. My rule of thumb is that multiple classes belong in the same file if you would almost always use a large subset of them at the same time instead of just one at a time.

dsimcha
  • 67,514
  • 53
  • 213
  • 334
  • 1
    What do you mean by "import declaration boilerplate"? "Using statements"? But aren't the classes gonna be in the same namespace? – Joan Venge Mar 12 '10 at 19:13
  • 3
    @Joan: I mean having to import 15 different but related modules to accomplish something really simple. Maybe it doesn't apply specifically to C#. I don't really know C#, but in other languages it's a pretty annoying problem. – dsimcha Mar 12 '10 at 21:05
  • Thanks yeah that's why I was confused. – Joan Venge Mar 13 '10 at 02:28
3

I only do this rarely. For example if there is an enumeration or struct that is closely related to the class yet too trivial to be separated on its own.

Or a separate class to contain some extension methods for that main class.

Wayne Koorts
  • 10,861
  • 13
  • 46
  • 72
puffpio
  • 3,402
  • 6
  • 36
  • 41
3

Is that really a problem?:)
Really small classes, just like enums, can be put together with others. There's one rule to follow: put together only classes that have something in common.

As a digression - in one of my projects I have a file that has 150 classes inside. The file has 10000 lines of code. But it's auto generated so it's fully acceptable :)

IamDeveloper
  • 5,156
  • 6
  • 34
  • 50
  • 1
    I have a same file with 120 classes and 750 subclasses with half a million lines, it is also autogenerated.the problem is:if i click on it, i must reboot because everything stops. – Behrooz Jul 24 '10 at 15:34
3

On occasion I will leave a small class in with a larger class but only if they are very tightly related like an object and it's collection class or factory.

There is one problem with this though. Eventually the small class grows to the point at which it should be in its own file, if you move it to the new file you lose easy access to your revision history.

ie.

  • on monday I make a change to my classes x and y in file y.css
  • on tuesday I seperate class x in to its own file x.css because it has grow to large
  • on wednesday my boss wants to see what I changed in class x on monday so he looks at the history for x.css, only x.css doesn't show the history before tuesdays changes.
gingerbreadboy
  • 7,386
  • 5
  • 36
  • 62
  • 1
    What if the "small class" is something like a derivative of EventArgs, which is intended for passing information to recipients of your class's events? Would code be made any cleaner or easier to maintain by moving such a thing to another file? Arguably, such a thing should be a nested public class, but those seem to be frowned upon also. As for the revision history, wouldn't the class have appeared out of nowhere in the changelog, and shouldn't a comment in the code note where it came from? – supercat Jan 04 '11 at 21:06
  • I would class that as a `very tightly related` class and leave it in provided it only takes up a small amount of screen space and isn't used for the same purpose by any other class. – gingerbreadboy Jan 05 '11 at 10:34
2

I do this, but only when the classes are related in a child-parent fashion and the child classes are ONLY used by the parent.

CResults
  • 5,100
  • 1
  • 22
  • 28
  • Thanks, but why don't you separate it into another file? Just curious. – Joan Venge Mar 12 '10 at 18:49
  • @henchman has said it a lot more eloquently than I have, especially when the child object is very small. It is usally the case that the child class is properties only with maybe only a little logic – CResults Mar 12 '10 at 19:52
2

One case could be: when your classes jointly form a module / unit that serves some main classes like helper classes, other wise no.

have a look at ASP.NET MVC 2.0 project source code. It strictly follows this rule

Asad
  • 21,468
  • 17
  • 69
  • 94
2

The responses so far seem to revolve around people's exceptions to the rule, so here's mine: I keep classes and their metadata 'buddy' classes together when using the DataAnnotations package in .NET3.5 SP1. Otherwise, they're always in seperate files. You know, most of the time. Except when they aren't.

Wayne Koorts
  • 10,861
  • 13
  • 46
  • 72
Brant Bobby
  • 14,956
  • 14
  • 78
  • 115
2

I usually stick with one class per file. But I will make exceptions for groups of similar constructs that are used project-wide. For example:

  • An EventArgs.cs that contains any EventArgs subclasses, since they're usually only 5-10 lines of code each, but they typically are used by several different classes. Alternatively, I might put the EventArgs classes in the same file as the class that declares the events.
  • A Delegates.cs that contains Delegates that are used throughout the project, since they're usually only 1 line each. Again, the alternative is to put them in the same file with the class that exposes/consumes them.
  • An Enums.cs that contains enums used throughout the project. (If there's an enum that's used only by one class, I'll usually make it private to that class.)
Daniel Pryden
  • 59,486
  • 16
  • 97
  • 135
2

Another vote for one class per file with the file being named the same as the class. For me, it helps with long term maintainability. I can easily look through the repository and see what classes are part of a solution without having to open the project or any of the files.

Tim Scarborough
  • 1,270
  • 1
  • 11
  • 22
2

I follow it 99% of the time. It's good to follow standards, but I also believe flexibility has its place. Sometimes it just seems like a silly waste of time to break things apart. In those times, I get over myself and just write my code.

Mike Pateras
  • 14,715
  • 30
  • 97
  • 137
1

I like the idea of creating smaller classes and making sure that the class is doing only what it is supposed to do. If you have multiple classes which are contributing to solve a single problem then there is no harm in putting them together in the same file.

I would not follow MS practices as they are not the BEST PRACTICES!

Wayne Koorts
  • 10,861
  • 13
  • 46
  • 72
azamsharp
  • 19,710
  • 36
  • 144
  • 222
1

Another point I have not seen anyone else mention is that when you develop using the one class per file rule you can easily see what that specific class is using.

For example: you may have two classes where one class uses Linq and the other does not.

If these classes were in the same file you would not be able to tell without looking through the code which class uses what. When it is one class per file all you have to do is look at the top of the file to see exactly what is being used in that class. Helps if you are ever migrating over to a new lib etc.

Kieran Oldham
  • 36
  • 5
1

Another reason for one-class-per-file that hasn't been mentioned in the answers posted so far is that one-class-per-file makes it easier to understand the impact of a PR during a code review. It also reduces merge conflicts.

When someone posts a PR for feedback I can look at the list of files changed and immediately see any overlap with what I might be working on. Depending on the overlap I might want to look at their code more deeply or give it an OK because I'm fairly confident it isn't going to affect my own changes.

When two people are working in a multi-class file and both add a dependency there's a good chance you'll get a merge conflict in the using block at the top. Separating the classes into files separates the dependencies so you can see what each class is using and you don't get conflicts like this.

There are exceptions to this rule (interface + implementation, enums, ...) but it's a better starting place than the opposite which typically lets junior developers bundle all manner of unrelated classes into the same file.

One-class-per-file is a clear unambiguous rule not subject to interpretation.

Related-classes-in-a-file is subject to personal preferences and interpretation (as you can see from all the other answers here as to when it's OK to use) and thus is a poor rule.

Ian Mercer
  • 38,490
  • 8
  • 97
  • 133
-1

The back and forth has been very interesting, and seemingly inconclusive, though my general impression is that a 1-1 mapping between classes and files is the majority opinion, though with some person-by-person exceptions.

I'm curious if any of your answers vary depending on whether you are: (1) developing a Windows Forms app, a Web app, a Library, or whatever; or (2) using Visual Studio or not. In using VS, it would appear that the one class per file rule would also imply one class per VS project since the concensus in other threads seems to be that VS solutions/projects should be mirrored in the directory/file naming and structure. Indeed, my impression is that the concensus is to have the project name = assembly name = (nested) namespace name, all of which would then be mirrored in the directory/file naming and structure. If those are the right guidelines (or rules), then all these seemingly orthogonal organizing mechanisms would be nevertheless kept in sync.

Cincy Steve
  • 457
  • 6
  • 16
-3

Yes for the sake of readability we should have one file per class!. Just jumped into a project. I see many classes in one file. it just makes it so hard for a new guy to understand it. shouldnt we think of maintainibility? when we develop a software? many times development will continue by other developers. We have namespaces to arrange our stuff, we dont need files to do that!.

Ceti
  • 1
-6

One code item per file, yes.

Everything else is a malpractice - and, quite frankly, a sign of RAD victimness.

As soon as one starts proper software development (IoC, design patterns, DDD, TDD, etc...) and leaves the "omg lets get this done, I have no idea how, but I get paid" playground, one will see that this rule really, really, matters.

Turing Complete
  • 929
  • 2
  • 12
  • 19