We Keep Coding

How to organise class files in C#

I am working on a simple project and I have created several classes, interfaces, one static class and so on. What I am asking is, how to organise this files into namespaces. Is there any good practice for this or I should just follow the logic of my program. I am currently thinking that I should move the interfaces into one namespace and all the classes into another. So what can you advise me. I am really curious to find out the best way to separate my files.
Have a nice day :)

You should group your code in namespace with other types which have the highest cohesion. That is, group types together when they perform common functionality. The type of cohesion you're suggesting is logical cohesion, and is really a rather weak form of cohesion.

Namespaces are mainly for the benifit of large projects. Since you are working on a "simple project", I suggest that you use a single namespace for the entire application. Since everything in C# must be a type or a member of a type (i.e., there are no global variables or methods), the types that you create (objects, classes, interfaces, enums, etc.) are usually a good-enough organizing feature for a small project.
For slightly larger projects, I suggest putting each tier into its own namespace.
For even larger projects, namespaces should be a logical grouping of related types or subsystems, according to preference.

Into specific namespace you should put everything which concerns some matter. For example all the stuff concerning string manipulations you should put into separate namespace, e.g. com.server.string.
It's very important especially in case you have class with names existing in other namespaces.

The only reason to split your code in files is to make your code maintainable.
As a general rule of thumb, I tend to create folders for enum's, struct's, models, controllers, etc. Depending on the size of the solution, you keep nesting in groups after that.
Sometimes it makes sense to just put the entire namespace in the file, other times, you let your nesting take care of the naming.
A good rule of tumb is that you should be able to find what you are looking for quicky, and, more importantly, someone who hasn't seen the project, should find his way around quickly.
One thing to keep in mind is that you never put more then one thing in one file. Never put two classes in the same file, never append enums at the end of a class file, etc.

You are confusing files with classes. You can create folders in Visual Studio to organize your files. That way you can group interfaces and classes (which is what I usually do). VS will automatically put new classes for which the file is in those folders in the namespace of the same name. This is usually not what you want (I don't know how to turn it off, so I can't help you with that).
I agree with the other answers here that you should group types based on what they do, not on what kind of language construct they are.

Is this the good pratice to name the namespace according to the directory name

I have a directory structure to store the source files. Is this the good practice to
name the naming space according to the directory structure?
Like
Models\model.cs
Data\data.cs
One is defined in namespace Models
One is defined in namespace Data

Yes, that's the typical approach, and it's also one that's supported by tools such as ReSharper.
The difference between this and the Java approach is that you don't add directories all the way down from the top - just from the default namespace for the project. So for example, suppose we were creating Foo.Bar.Baz.Model and Foo.Bar.Baz.Data, the C# and java solutions might be:
C#:
Foo.Bar.Baz
Foo.Bar.Baz.csproj defining a project with default namespace of Foo.Bar.Baz
Model\
SomeModel.cs
Data\
SomeData.cs
Java:
src\
foo\
bar\
baz\
model\
SomeModel.java
data\
SomeData.java

yes is the usual practice, but you also put the project name before the directory name so you will have: myclasslibraryname.Models.Model and myclasslibraryname.Data.Data

Yes. It is a common practice in Java (at least, the source code I've looked at for big projects has almost always been structured this way). Not as common in C# from what I've seen, but there's nothing keeping you from doing it, and it helps you find the code a lot faster.
You'll probably want a deeper namespace hierarchy than just one level though. It is common to preface it with your organization or group name, the project name, the library/program name, then code architectural names (like Model, View, Data, etc). Whatever makes the most sense for whatever scope the source code of your project will live.

Generally I think it is a good practice. When you do it in such a manner, while going through the code, you can generally associate or easy to locate and get to know where your code file is coming from.
This is also a good practice in terms for maintaining the code. Some new user comes in, he can just see the namespace and identify where the code files are located or needs to be searched.

I don't know really if this is good or not.
But I name it like this.
I defined categories for the different modules.
Like this:
Company.Common
Company.Common.Web
Company.Windows
Company.Windows.Services
Common represent a directory. Inside it I created a solution with VS2010.
Inside the solution I create a project for each part and therefor the subdirectories for the project and if the project is complex, more sub dirs for the existing classes inside the dll.
There I have a good overview in all views (dir - view and project view - code view ).

This is a convenient convention for many projects, and one which some tools support or expect.
However, this isn't the full story. Although it's a good default, I don't think it should be regarded as inviolable best practice, because there are some circumstances which might motivate doing things another way. Additional factors to think about include:
Unnecessary namespace proliferation
and deeply nested namespace
hierarchies can be a pain for users
of your types. In a large library you
may want to start organising the
source code files into some folder
structure before you feel the need to
impose multiple namespaces on your
clients.
Related to this, namespace
hierarchies in .NET are supposed to
work such that dependencies between
types go from child namespace to
parent, not the other way around.
This isn't always the natural way to
organise source code into
folders/directories. For example, one
often sees people creating namespaces
such as MyNamespace.Foo.Common
containing utility types used both by
types in MyNamespace.Foo.Bar1 and
those in MyNamespace.Foo.Bar2. It
seems sensible to them at the source
code organisation level, but it
breaks the namespace dependency
convention.
Sometimes you may want to provide
additional functionality by adding
some types to a library namespace by
distributing a supplementary assembly
rather than releasing a completely
new version of the full library
assembly. It's likely to be more
convenient to keep source code files
for the respective assemblies
separate from each other in the
repository, rather than to store them
together just so as to keep all types
for the namespace in the same folder.
In short, I'd say follow the usual practice unless you have a good reason to do otherwise. But don't let it deter you, if you have a good reason to make use of the fact that Namespaces can provide a grouping of types completely orthogonal to their grouping into deployable assemblies and the source code which builds those.

How to choose a naming convention for WPF view-model and data-model classes?

I am trying to figure out a naming convention to use when naming my WPF view-model and data-model classes and would appreciate input from others who have already done this.
My problem is that the data-model and view-model class that I want to name have almost the same name.
As an example, I am working on an application that has a flow-chart editor. In my data-model I am going to have a Node class.
In my view-model I am also going to have a Node class that wraps the data-model class and adds view specific properties such as IsSelected.
What is the best way to actually differentiate these class names to avoid confusion?
Obviously they will be in different namespaces. Eg Flowchart.Node and FlowchartView.Node. So they don't really need to have different class names. That said I think that different class names would be better to help, as I mentioned, avoid confusion.
I had thought of naming them Node and NodeView which I suppose sounds reasonable but for some reason leaves a bad taste for me.
So this is a call out for advice on what naming conventions others are using. This is admittedly a simple problem, but then again finding good names seems to be a constant battle.

I suffix all my view models with "ViewModel", and all views with "View". Thus, you'd have NodeViewModel, NodeView, and Node (the data class). This is just a personal convention, though. I'm sure there are other equally valid one out there.

I'll keep the namespace and folders in synch as that's the expectation most .NET developers will have. Needless to say, each class in its own file. This will make it easy to find source in projects.
/Views
namespace: <Company>.(<Product>|<Technology>)[.<Feature>].Views
/ViewModels
namespace: <Company>.(<Product>|<Technology>)[.<Feature>].ViewModels
/Models
namespace: <Company>.(<Product>|<Technology>)[.<Feature>].Models
No need to add suffix to distinguish between classes. Namespace already does that.

Namespaces
System - contains the main system classes, a.k.a. the model.
System.ViewModels - contains the view-models.
System.Windows - contains anything used for presentation.
Simple project, I include all the namespaces.
For bigger projects, I create one project for each namespace. Avoid deep namespaces. See Framework Design Guidelines.
I do not append any suffixes because the namespace is clear enough. For instance, if I create a UserControl (a view) that displays a collection of "Alerts", then I name that user-control AlertsPanel or AlertsListBox or 'AlertsItemsControl`.
The exception is view-models. There I find it is better to append "ViewModel" because this convention avoids the natural naming conflicts that can occur when all three namespaces must be used.
As an alternative to appending "ViewModel", using VM = System.ViewModels; allows for a model and view-model class to share the same name, as in VM.Foo oFoo = new VM.Foo(new Foo());.

Common namespace naming suggestion

I have a layered application with namespaces:
App.Core - business layer logic services
App.Data - data access layer store classes and data access objects
App.Web - user interface layer
I also have business objects/DTOs. They reside in App.Objects namespace, but I dont like this naming convention. Why? Because this namespace will also have subnamespaces suffixed Objects like App.Objects.KeywordObjects. These subnamespaces can't be without the Objects suffix, because some of them will also contain classes with the same name (App.Objects.KeywordObjects will contain Keyword and Keywords classes).
I was thinking of changing App.Objects to something else. So I don't have duplicate "Objects" word. But I can't seem to find any usable word. And I don't want to use acronyms like DTO or BO.
How do you normally name your namespaces and what would you suggest I should use in this case.

I'm a fan of the guidelines in "Framework Design Guidelines" by Brad Abrams et Al, which would give you:
YourCompany.BusinessArea for your business objects and YourCompany.BusinessArea.Web for your web layer. I seem to remember there was also a guideline that an object shouldn't rely on a nested namespace (but you could rely on a parent namespace)

Namespace depth should correlate to frequency of usage. Why not put them in App? If your application revolves around the business objects, it makes sense to keep them at or near the root.
For a practical comparison, for many business applications the business objects are analogous to keeping common types in System. They are pervasive.

Here are some suggestions:
App.Contracts
App.Entities
Giving things a good name is hard to do. The best thing I can suggest is find something that works for you and try your best to be consistent in style and tone. This is easier said than done.
“When I use a word," Humpty Dumpty said in rather a scornful tone, "it means just what I choose it to mean - neither more nor less.” - Lewis Caroll

I normally use common acronyms freely (so I wouldn't mind using App.BO, personally), but if you always have the Objects suffix in the subnamespace I think App.Business reads nicely, e.g App.Business.KeywordObjects with that "business [something] objects" phrase. (If you don't always have the Objects suffix for subnamespaces then this suggestion wouldn't work as well, as things would read strangely).

I would make the following change
App.Core => App.Services
App.Objects => App.Core
or
App.Objects => App.Model

App.Business ?

Naming types in a namespace by the .NET Framework Design Guidelines

I'm having some problems to come up with a sane type naming scheme for our new line of applications. I want to follow the .NET Framework Developer's Guide - Design Guidelines for Developing Class Libraries, but I'm starting to wonder if that's such a good idea.
I'd like to use the Company.Product.Feature namespace scheme as a basis.
Problem 1: We have our own control and form base classes, and I want these to go into the Company.Product.Forms namespace. However, according to the guidelines, we shouldn't let our type names be Control or Form, even if they are in our own Company.Product.Forms namespace, since they will clash with system types.
Problem 2: We have some distinct feature areas in the application and I want these to go into their own Company.Product.Feature namespace. Lots of these features have similar design, with a controller and some views, so under each Company.Product.Feature namespace I'd like to have types named Controller, SomeView, AnotherView, etc. However, according to the guidelines, we shouldn't have the same type names in different namespaces.
The only solution I see to overcome these problems is to prefix the types with something that in some way makes the namespaces redundant. Or not?

Microsoft clearly favors some redundancy. A common example is:
System.Xml.XmlDocument
General class names, even bound within a proper named namespace can cause headaches for the many programmers who like to avoid fully qualifying their class instantiations. "Document" could be an Xml, Html or word document. This ambiguity will cause endless confusion if you happen to import more than one namespace with a "Document" class.

I'd prefer Company.Product.UI, for some reason. I would use that naming for the web, too.
Regarding problem 1, if these are base types, you might include Base in the class name.
Then, you typically have a set of domain specific controls, which won't clash with built-in types.
If you also keep wrappers for common UI controls(TextBox, DropDownList etc), then i would actually recommend use a prefix for them,
maybe this prefix is an abbreviated name of the product.
And then, if you do that, then you might want to be consistent, and do it for all types,
regardless of whether they are ambigious names or not.
I tell you from my own experience.
You'll end up constantly hovering over variables to see their full type names, etc, you will use aliasing etc..
The code will be harder to read.
Problem 2: While at GUI layer, i tend to break these rules, because you will want naming consistency(common verbs; Show,Edit,List). If the guideline tells you otherwise, i would believe it is because it is simply not specific enough.

First post here in StackOverFlow, on an old question. Please, be kind with me :)
General class names, even bound within a proper named namespace can cause headaches for the many programmers who like to avoid fully qualifying their class instantiations. "Document" could be an Xml, Html or word document. This ambiguity will cause endless confusion if you happen to import more than one namespace with a "Document" class.
Microsoft MIGHT sometimes favor some redundency but it's not always de case.
As for the Document vs XMLDocument problematic, when you know there might be more than one type of document, why not just include the qualifying part of the namespace in the declaration?
For example :
Xml.XmlDocument
vs
Html.HtmlDocument
Instead of importing the XML and HTML namespace, why not just include the containing namespace? It would become like this :
Xml.Document
vs
Html.Document

If it makes logical sense, then do it. They are just guidelines, not the LAW. (not that you cant break that too.)

Having classes in the with the same name in different namespaces is just is against the guidelines for a reason, it makes reading the code just a little bit harder because when you see "Controller" you have to mentally map it to "Feature1.Controller" or "Feature2.Controller".
I would prefer to use Company.Product.Features.Feature1.Feature1Conroller with the redundant information or maybe Company.Product.Features.Feature1Controller if it bothers you (and I personally don't like having too many namespaces).
But feel free to break the guidelines, rules are there to make you think before you break them :-)