If I have objects on one layer with the same name as objects on another layer, is it best to change the object names with some prefix or have new namespace and refer to them with fully qualified names? For example:
namespace Project1.Data
Object Person;
namespace Project1.Model
Object Person;
Data.Person.Name=Person.Name;
OR
dbPerson.Name= Person.Name;
I'd use namespaces and namespace aliases, e.g:
Define your classes in appropriate namespaces:
namespace Project1.Data
{
public class Person {...}
}
namespace Project1.Model
{
public class Person {...}
}
And where you use the classes, either use fully qualified names or define an alias for the namespaces (especially usefule if the full namespace is long):
using data = Project1.Data;
using model = Project1.Model;
data.Person p1 = new data.Person();
model.Person p2 = new model.Person();
//...
p1.Name = p2.Name;
It depends on how often you're referring to the overloaded name.
If you use it several times in one file, then use the first way.
If you use it only once or twice, then write out the fully qualified name, so that other people won't have to go hunting around at the top of your file to figure out what object you're referring to.
It really depends on the frequency you're requesting each of them. Generally, I use the shortened version for the type I'm referring to most frequently, and use the longer name for the type which is less frequently used. I'd say eventually, if you end up having a lot of usages of both in the same file, that you should use namespace aliasing, but for me, that's a last resort only after the code has bloated to a point where it's hard to follow what's going on.
Had the same thought myself. I think chaging the name of the classes is a bad Idea. For instance I have a data access layer and a business layer. Both deal with users. So I have...
Project1.Business.User
Project1.DataAccess.User
trying to think of inventive new names for the classes is a waste of time and will probably mean odd names for classes with little meaning. Naming classes can be enough of a headache already.
I agree with McWafflestix "I use the shortened version for the type I'm referring to most frequently, and use the longer name for the type which is less frequently used".
It's simple. Listening to the .NET framework guidelines for once actually helps (although plenty of material in the book is just plain Elements of Java style Yet Again in Redmond Wonderland)..
You should avoid similar type names in cross or intra-project/library mixing namespaces ie. mixing across domains and models in generial ( even in C++ one that is extremellly strict and powerful, it also has an incarnation in compiler, resolution and enum-style compiler crashes and problems).
Therefore even fully qualifying all the time is no fool-proof (and btw aliases and 'using' are extremely limited and cause mild duplication at best, as well as prove C# weakness in generic programming etc ).
In my experience, Data domain types are a primary target for a more appropriate name, and thus for name refactoring which is:
a) cheap (as a process in rich ASTs but simple adt-s support like in C#, right-click in IDE and feel powerful according to type-challenged dynamic Ruby fans/backers )
[can also be read as: 4.0 dynamic features sheep will blame everyone but not think about namespaces or functional JS, C-with templates(not C-with-classes), or similar ]
b) communicates the semantics better ie. the intent (ie. plumbing + support to build your own processing )
c) usually of primitive but typed nature or message ( typed not OO; ie. OO-style critique as in aforementioned book which itself breaks straight out of intro lifts all 'Models' to reference land)
d) and 'aliasing' becomes a useful artifact in cross-domain usage (which is actually possible and quite 2020-like.. ie. value-type programming )
There really are no rules but beware that you will see mixing of namespaces in development when least expected.. which means only one thing for a managed-minded dev: confusion. Plus somewhat less serious, more compile-time and IntelliNonsense errors of course..
Tough problem in all languages, so it is your design/naming issue.. Even tool vendors can mess up for machines to parse.. say output of enhanced popular IDEs based on outdated browse information; then again, others do it real well for managed languages.
Not that I am against duplicating names, there are cases (they are tough but necessary) when mixing dual + interop + representation etc other models where same name makes it more readable; ie. where duplication is a necessity of dual-usage.. but that is lower level idioms that C# is not friendly or encouraging of (re: in favour of overhead).
Related
I was often wondering about the right way to do this:
For example, in my program I have around 100 constants (or enums) that are used in some calculation. They should preferrably be stored in one place. They can be grouped hierarchically, for example:
System3 / Rules / Rule7 / ParameterXY / MaxAverageValue
Naturally, I want those values to be accessible while coding, so storing them in some kind of ressource is not really an option.
As far as I could tell, this can be done with:
very long constant names
nesting classes
namespaces
Using names is quite ugly, and it's not really well maintainable. I find nesting classes a nice way to do it, but some stylecop/fxcop rules forbid that, so this must be "bad" in some way. Lastly, I find the suggested alternative, using namespaces, not terribly nice neither. Imho it creates masses of folders and files that each contain almost nothing. And I don't like when 50 sub-namespaces pop up in the assembly reflector.
So.. how do you do this kind of task? What would you suggest?
very long constant names
This is sort of gross, but at least it is discoverable. All your code would reside in the same place so you wouldn't have a problem finding it.
I find nesting classes a nice way to do it, but some stylecop/fxcop rules forbid that, so this must be "bad" in some way
One reason it is is bad because automated code generation/code inspection tools are harder to work with. Another reason is that it is harder to discover these with Intellisense.
The most important reason this is bad is because a nested class should be strongly associated in an object-oriented dependency sense for the layout be make sense logically. In all but some rare cases (e.g. Enumerator classes) it won't make sense. In your case it also doesn't make sense because your classes don't really have any behavior or object orientation at all - they're just a hierarchy of constants.
Namespaces
For the problem you described, this is the best way to handle it. You get the least clutter per-level, and you get Intellisense while typing so you can see what you're narrowing down to while descending through the hierarchy.
Imho it creates masses of folders and files that each contain almost nothing
If you really need a huge pool of constants, and it doesn't make sense to bind them to other parts of your application, then this is one of the rare cases that I'd abuse the one-file-per-class and one-folder-per-namespace rules. The only reason you're even stuffing them into classes at all is because .Net doesn't have support for global variables.
Another suggestion
Do you have domain-specific objects that these constants belong on instead? E.g. is there any logic related to the System3 / Rules / Rule7 class? Is that not some sort of actual business rule that you should embody with its own class?
If you can arrange your code so that you have a thicker domain model, then the most logical place to put your constants is on the classes that embody the corresponding domain logic.
If it doesn't make sense to have a thick domain, you have fully generic rules processing, and you are relying on constants to feed your business engine logic, then you have a data-driven application. This means you should store your data in configuration files, not in code.
How often is each constant re-used in multiple methods? You could consider reorganizing your constants. If you still find yourself with huge numbers of constants, try putting them in a static class with read-only properties.
If you just need a good place to look at them all in one place, you could also look at storing them in the app.config file and you can access them through AppSettings and the ConfigurationManager class.
Well the way I do this is to have a sealed file called Constants.
so
public sealed class Constants
{
//for e.g.
//Sessions
public const string APPSESSIONKEY = "AppType";
}
Than I use this in the rest of my project and the importance here is what you will name it as it will help you remember it and make sense when you need it.
By calling it in your code.
Constants.AppSessionKey
You could also
Create an Assembly whose only purpose is to hold constant values for the project. Every other Assembly should then reference this one. Following DRY and KISS, since adding references is simple enough. Main problem here is recompilation.
We use Resources files with a custom T4 template that generates a static class hierarchy with readonly string fields for the values.
The keys in our Resource file are separated with '.' to build the hierarchy.
We can have separate resource files that are compiled into one class hierarchy.
I know that nested classes is not recommended but in my opinion, for a situation like this it is the nicest solution.
If I'm dealing with one class and one public struct (not nested), Should I create a separate .cs just for the struct? Or leave it un-nested in its .cs file of the class? (This is assuming the struct relates to the class, but isn't so exclusive to the class that it should be nested and declared private)
Edit: I removed my initial question about two classes because I found C# classes in separate files?
Note that the only person(s) that can accurately answer this question is you, and your team. If your team is happy to find several related types inside a single file, combined due to ... whatever... then what I, or whomever other person, says, should be just ... irrelevant.
In any case, I would turn the question upside down:
Is there any reason to place two separate types (related by names, functionality, or whatever, but separate nonetheless) in the same file
and I've yet to come up with a good reason.
There are extensions/addins to Visual Studio where you can type in the name, and quickly navigate to the file, and I can think of three, but there are undoubtedly others:
DPack
ReSharper
CodeRush/Refactor! Pro
The first allows you to quickly navigate to a file by name. If you know the type, but have people putting multiple types into the same type, this will not be helpful, at all.
The second and third, lets you navigate to a type by name, but you shouldn't rely on people having those, or knowing how to use them.
To that end, I would advocate following these rules:
Project names should be identical to the root namespace of that project. I differ from this point myself where in some cases I name my projects "...Core", and I then remove "Core" from the namespace, but otherwise, leave the project name identical to the namespace
Use folders in the project to build namespace hierarchies
The name of a type should correspond 100% to the name of the file + whatever extension is right for your language. So "YourType" should be "YourType.cs", "YourType.vb" or "YourType.whatever" depending on language
That depends on who you ask.
I, personally, find it easier to read if they are all, always, broken out. However, the compiler doesn't care... so whatever you and your team agree is easier to understand.
In my opinion it's a good practice to avoid that. Some day a developer will be looking around for ClassBar in the project and won't be able to find it easily because it's nested in ClassFoo.cs
Tools like Resharper have a neat feature where you can just select a class, right click, place in new file to make this easier.
If you read any of the popular coding standards (Lance Hunt, iDesign, Framework Design Guidelines etc) most of them advocate 1 class per file.
Its annoying to scroll down and search for how many class each.cs file contains/hides.
Maintainability issue while using version control
Usability with our team.
Check here for more interesting discussion on same.
I think it was less about whether you can or whether you should. For things like this, I feel it's best to look to the convention in the rest of the codebase. Sometime conformity is better because it makes other developers jobs easier becaues everybody knows where things are.
If it's entirely new project and you are setting the standards here by yourself, do what makes sense to you. To me if the struct has no use outside the related class, I may put them in the same file. Otherwise, I seperate them out.
Are there any best-practices that state custom code shouldn't be placed in a System namespace? Should System and its children be reserved for Microsoft code?
I ask because I'm writing a class library that will be used across many projects and I'd like to keep things consistent by placing it in System.InteropServices (since it deals with P/Invoke).
It's not a good idea because it defeats one of the primary benefits of namespaces: preventing name clashes. What if a newer version of the framework introduced an identically named type in that namespace?
This is particularly bad for System namespaces since they are imported in many other pieces of code with using directives and introducing custom types in those namespaces pollutes the naming scope of other source files with unexpected identifiers.
To categorize your custom interop related types, you can create a new namespace like MyProduct.InteropServices.
If you place a new class in System.InteropServices, every file that has a using System.InteropServices; clause is forced to have your class in scope, which may confuse the programmer. Since the programmer cannot defend oneself against this, I'd consider this bad practise.
I disagree with everyone.
I think that in a limited subset of cases (mostly with extension methods) it is perfectly reasonable to place code in a system namespace.
Here is my side of the argument from an email thread we had debating Extension methods in the System namespace over at EPS:
Ok, so here's my side of the argument:
I really like to minimize code. That includes usings.
Yes, ReSharper picks up extension methods and adds the usings for you but some people don't have ReSharper, and besides, I prefer Coderush which as of yet does not actually (as far as I know) pick up extension namespaces.
There are at least two different types of extension methods; ones that are helper methods for our application - including domain and application-specific helpers, and ones that encapsulate features and syntax that we believe the language should have had to begin with.
A good example of the latter is the ability to do "a {0} {1}".Format("b", "c") or someListOfStrings.Join(", ") rather than having to do String.Join(someStringList.ToArray(), ", "). Other more debatable examples are IEnumerable<T>.ForEach and the IsNull() extension to take the place of the clumsy object.ReferenceEquals(null, someVar) syntax.
My argument is, that there is every reason to place this latter classification - your team broadly agrees should be in the language but aren't - in the appropriate namespace (System, System.IO, System.Linq, etc.). We want those functions to be available everywhere, just like we prefer the foreach and yield keywords to always be visible. If it is application-specific however it should go in its own namespace. 90% of the time application-specific helper extensions should likely not be extensions and not even be static. I exclude from this statement using extension methods to provide aliases for function names.
You can get in some trouble with this of course when calling into assemblies that contain system-wide extensions. Suppose that I was referencing the assembly containing my void IEnumerable<T>.ForEach method and wanted to create my own ruby-like R IEnumerable<T, R>.ForEach (which is actually just a Select, but nevermind that). This would be a problem! What I like to do to mitigate the issue is to define my extension classes as being internal so that they can be used only on my project. This solves the problem nicely.
Is it a good idea to use "system namespaces" in my class libraries?
Sample:
namespace System.Web {
public static class RequestExtensions {
public static bool IsPost(this HttpRequest r) {
return string.Compare(r.HttpMethod, "POST", StringComparison.OrdinalIgnoreCase) == 0;
}
}
}
The advantage: no need to include additional uses-clauses (especially for extension methods), so all becomes available straight after adding reference to the library.
The best sample is NUnitEx project (which uses NUnit's namespace).
Disadvantages: potential name conflicts.
I have to second everyone else who says its a BAD idea. Namespaces are an organizational tool, on many levels. Not only do they allow you to reuse identifiers for your own purposes without conflicting with other companies, they also allow different companies to isolate their product from your's or anyone else's. Putting code into the System namespace can be very confusing for the people who use your types.
Additionally, people know that anything in a System namespace is good, solid, tested, community vetted, thoroughly documented code that came from Microsoft. Thats a pretty important set of factors to live up to...by sticking your code in the same namespace, not only are you claiming your code is that good, but you have to live up to it.
The design guidelines talk about namespace naming:
The general format for a namespace name is as follows:
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
For example, Microsoft.WindowsMobile.DirectX.
Do prefix namespace names with a company name to prevent namespaces
from different companies from having the same name and prefix.
There is no scope for reusing System or Microsoft here.
Very very bad. It's confusing, and you should only do it if you absolutely have to (there are some cases when it's needed).
Only ever do it when it's 100% required, don't ever do it just for 'convenience'.
I think it is not good idea, because may be Microsoft will decide to create RequestExtensions class in the next versions of framework, It is always good practice to start namespace with your company name to prevent name conflicts
Using a System-based namespace can make it harder for someone to pick up your code and figure out what it's doing. For instance, if I pick up new C#, I often end up Googling things like "System.Web.xyz" when I don't know something.
In this case, I probably wouldn't know that "System.Web.RequestExtensions" wasn't a real member of the System.Web namespace, so I'd get stuck looking for a class that doesn't exist.
So basically, my view is that you need to document it really well or find another namespace.
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 :-)