I have a class named AppVisum.Membership.Views.AppVisum.Membership.Controllers.Membership._Page_Views_AppVisum_Membership_Controllers_Membership_Validate_cshtml. Yeah, I know it is hidious, but I rather think it has to be named that, and as for the namespaces, those are unnecessary, but the class is generated by a tool, and the folder needs to be named AppVisum.Membership.Controllers.Membership, so I don't know if I can change the namespaces. However, hideous names isn't the real problem, the main issue is getting to the class AppVisum.Sys.AppSys. The ide tells me that it can't find AppVisum.Membership.Views.AppVisum.Sys.AppSys, so how can I tell it that I want the root one?
[Edit]
Sorry I wasn't specific enough as I thought this would be a simple problem to solve. The global:: would've worked perfectly if this had been a normal .cs file, however, it's a razor-file and razor don't quite like #using global::AppVisum.Sys (that just translates to using global, which doesn't make any sense). I've found 2 possible solutions, the first is to simply change the rule that search for files to search for folders with _ instead of .. Then I'd get paths like AppVisum.Membership.Views.AppVisum_Membership_Controllers_Membership._Page_Views_AppVisum_Membership_Controllers_Membership_Validate_cshtml. This would probably work just fine, and unless someone comes up with a better alternative I think I'm going for that. Another option is to rewrite the custom-tool that generates the classes (it's opensource, so I think I should be able to do that too fairly simply). Hope that clarifies things.
Add the global:: prefix to the namespace.
try:
using Sys = AppVisum.Sys;
or:
using AppSys = AppVisum.Sys.AppSys;
Basically, you can reduce ambiguity by aliasing types and namespaces in your using directives. (And the aliases don't need to be the same as the type/namespace names, they just are in my examples.)
As SLaks mentions in a comment, you should basically fix your project's default namespace - either that, or avoid creating the folder hierarchy. You've tagged this question with C#, but is your generated code actually in VB? While the VB compiler prepends the project's namespace when compiling, I don't believe the C# compiler does, so I'm surprised you're getting this namespace to be honest.
I disagree with your claim that "hideous names isn't the real problem" - I'd say it is the real problem, and making it hard to get at a particular namespace is one consequence of the problem. Fix the real problem (the bad namespaces) and the rest will go away. Using global:: etc is just a workaround, and one that you'll need to apply all over the place. It would be better to sort this out once and for all.
Basically if you can tell us more about how you've got into this situation, we're more likely to be able to help you get out of it.
maybe you can simplify by adding an using alias :
using AV = AppVisum.Membership.Views.AppVisum;
and in the code :
var s = new AV.Sys.AppSys();
Related
we are changing the name of our product, so i also want to rename the namespaces of our
framework-classes. But now i have the problem, that i don't know in which programms and scripts our namespaces are used. Is there a way in c#, to locate the same class in two different namespaces?
I know the solution, that i could inherited from my classes in the new namespace, but this is a very bad solution i think. So I have no idea how to solve this problem, because simply renaming all namespaces doesn't help and will cause a lot trouble.
Thank you!
If external scripts are referencing your assembly using the old namespace names then those names will have to remain in your assembly in you wish to continue to use those scripts. If you also want to create new namespace names to reflect the new name of your product, those names will also need to be hardcoded into your assembly. This will inevitably lead to problems!
I would recommend one of the following:
Leave the namespace names as they are.
Rename the namespaces in full and update the Python scripts at the same time.
I would definitely not recommend the faux 'inheritance' method, or any other solution which results in duplication within the assembly.
You could search the whole project / solution of course, but that seems sort of messy and time-consuming too, if you've got more than a trivial project.
Are you using Resharper? For this type of task, you definitely should be. If so, there is a chance this could at least help you on your way:
Rename the folders your source files are in in the Visual Studio Solution Explorer (this should in theory be easier than looking at each source file one by one, right?).
Now open one source file that you know will have the wrong namespace due to a renamed folder. It should appear with a blue squiggly line, as in the picture below.
Use the Resharper tip (pyramid to the left, or Alt + Enter) to open the context meny thingy also shown below.
Select Find all issues of this type in scope, and select Solution as your scope. That might at least help you get an overview of which classes you need to change the namespaces for, and go through them and change them systematically.
As for your scripts, I would guess that you best bet is to do a plain text search for the old namespaces - possibly a search and replace. Perhaps you can include your scripts in a VS solution, and use the built in search there to scan and fix them. That might at least ease the pain a little..
Is it possible to create a namespace hierarchy in C++ that resembles how it works in C#. For instance if I were to need a type to deal colors within C#, I could dive down through the namespaces to get the appropriate type by using the:
System.drawing.color;
type. In this case, it appears the namespaces are resolved at a project level and determined by the namespaces that the type is contained within. For the developer that this code targets, they get all of this in their auto-complete and aren't left searching through folders and files for that type. In C++ I might have to first include the appropriate header file, at which point I feel like we've already gone through the trouble of grepping source code for the appropriate types and finding which file includes those types. In C++ it would look like:
#include "Core/Color.h"
Color c = new Color();
The IDE offers me little help here. I have to do a directory search for the correct type. The directory paradigm seems to break down unless everyone specifically uses the right filenames and directory structure, which isn't always the case.
To fix this, it looks like not only would I have to come up with a namespace hierarchy for all of my types, which isn't such a large problem, but I'd have to also come up with a header hierarchy to eliminate the problem of constantly grepping the code to find the correct files that include those types.
Does a master header hierarchy present a problem for the compiler, preprocessor, or resulting compiled code since we'd essentially have every other header up the chain (up to a point of course) included in new files?
In the end I want a way to assist the developers who use this code by giving their IDEs a way to dive down to all the types without having to do all of the grepping that we currently have to do. There may be a way to quickly do this within IDEs already, at which point I wouldn't need to utilize the language itself to solve this sort of development problem, however I can't seem to find it.
See the following SO discussion and how this was handled by one of the SO users
C++ namespaces advice
http://www.adamjamesnaylor.com/2012/10/23/NestedNamespacesInC.aspx
edit typos
Hi,
This is possibly a moronic question, but if it helps me follow best practice I don't care :P
Say I want to use classes & methods within the System.Data namespace... and also the System.Data.SqlClient namespace.
Is it better to pull both into play or just the parent, ie...
using System.Data
using System.Data.SqlClient
or just...
using System.Data
More importantly I guess, does it have ANY effect on the application - or is it just a matter of preference (declaring both the parent and child keeps the rest of the code neat and tidy, but is that at the detriment of the application's speed because its pulling in the whole parent namespace AND then a child?)
Hope thats not too much waffle
It doesn't make any difference to the compiled code.
Personally I like to only have the ones that I'm using (no pun intended) but if you want to have 100 of them, it may slow down the compiler a smidge, but it won't change the compiled code (assuming there are no naming collisions, of course).
It's just a compile-time way of letting you write Z when you're talking about X.Y.Z... the compiler works out what you mean, and after that it's identical.
If you're going to use types from two different namespaces (and the hierarchy is largely illusional here) I would have both using directives, personally.
Click Organize->Remove Usings and Visual Studio will tell you the correct answer.
Firstly, it has no effect on the application. You can prove this by looking at the CIL code generated by the compiler. All types are declared in CIL with their full canonical names.
Importing namespaces is just syntactical sugar to help you write shorter code. In some cases, perhaps where you have a very large code file and are only referring to a type from a specific namespace a single time, you might choose not to import the namespace and instead use the fully-qualified name so it's clear to the developer where the type comes from. Still, though, it makes no difference.
Express what you mean and aim for concise, clear code - that's all that matters here. This has no effect on the application, just on you, your colleagues and your future workers brains.
Use whatever happens when write your type name and press Ctrl + .,Enter in VS.
In my background in C++ I was a supporter of using the scope resolution operator, for example
class Foo
{
std::list<int> m_list;
...
}
for external libraries, to keep clear which library you were using.
Now in C# I don't know if there's a rule of thumb or a best practice to know which packages should be included via the using keyword and which classes should be fully qualified. I suppose that this can be a subjetive issue, but would like to know the most extended practices.
I pretty much never fully qualify names - I always use using directives instead.
If I need to use two names which clash, I'll give both of them aliases:
using WinFormsTextBox = System.Windows.Forms.TextBox;
using WebFormsTextBox = System.Web.UI.WebControls.TextBox;
That rarely comes up though, in my experience.
I tend to make autogenerated code fully qualify everything though, just for simplicity and robustness.
I think the saving grace in C# is the directives are fully constrained to the file you place them in. I use them whenever their use is clear for the code in the file and it helps readability of the code. Another team at my office doesn't use them at all - I think it's nuts but they came up with their own rules and are happy with them.
Tend towards whatever makes the code more readable and understandable.
If the name may be ambiguous and their is no common "most likely case" then fully/partially qualifying to make this clear can be sensible even if this increases verbosity.
If confusion exists but one candidate is far more likely then qualify only in those cases where you do not use the most common case.
Common example is the use of System.Collection.X classes rather than the System.Collections.Generics versions (perhaps for back wards compatibility). In this case importing the generic namespace is fine and any non generic ones are fully qualified.
This makes it clear where you are using legacy code.
If you will be dealing with multiple clashes and the resulting full qualification would make you code extremely unreadable then it may make sense to use aliases to separate them out but you should be pretty averse to doing this since it renders the resulting code easier to physically read but harder to conceptually understand.
You have injected an element of inconsistency with the wider world. this makes code snippets within the class harder to understand in isolation.
If you must do this consider alias names which make it very clear that these are aliases as an indication to readers that they should look at the using statements for confirmation of the real types.
In a recent VB.NET project I adopted the naming conventions I'm used to using in C#. Namely, often calling a variable the same name as the class it references, only with a different case, e.g.
Foo foo = new Foo(); // C#
Dim foo As New Foo() ' VB.NET
I find this is often the clearest way to write code, especially for small methods. This coding style obviously works fine in C#, being case sensitive, and because of the syntax highlighting provided by Visual Studio, it is very easy to see that the class name and the variable name are different.
However, to my surprise, this also worked fine nearly 100% of the time* in VB.NET. The only issue was that the variable name then appeared to take on a multiple identity. Namely it could be used to call both instance methods and Shared (static) methods of the Foo class. This didn't really cause any problems though, it just meant that Intellisense would provide a list containing both static and instance methods after you hit the '.' after the variable name.
I found, again to my surprise, that this didn't actually lead to any confusion in my project, and it's been very successful so far! However I was the only person working on this particular project.
Here is a slightly longer example:
Dim collection as Collection = New Collection()
For Each bar As Bar in Bar.All()
collection.SomeInstanceMethod(bar)
Next
collection.SomeSharedMethod()
* The only issue I found with this was that sometimes the 'Rename' refactoring tool got confused, i.e. when renaming a class it would rename the variables with the same name as the class as well, in their declaration lines (Dim foo As...), but not the other references to that variable, causing compiler issues (duh). These were always easy to correct though.
Another small annoyance is that the VB.NET syntax highlighter doesn't highlight class names any differently than variable names, making it not quite as nice as when using it in C#. I still found the code very readable though.
Has anyone else tried allowing this in a team environment? Are there any other potential issues with this naming convention in VB.NET?
Although VB is case-insensitive, the compiler is intelligent enough to not being confused between the object-instance and the class.
However, it's certainly very dangerous and wrong to use the same name in a case-insensitive language! Especially if other programmers are working on that project.
I have to move back and forth between VB and C#, and we consider this poor practice. We also don't like letting variable names in C# differ from their type only by case. Instead, we use an _ prefix or give it a more meaningful name.
Whenever you start a new language it's inevitable you'll notice a bunch of things that are different and miss the old way of doing things. Often this is because you are initially unaware of different features in the other language has that address the same problem. Since you're new to VB, here are a couple notes that will help you get things done:
It's not 100% correct to say that VB.Net is case-insensitive unless you also make the point that it is case-aware. When you declare an variableidentifier, the IDE will take note of what case you used and auto-correct other uses to match that case. You can use this feature to help spot typos or places where the IDE might be confused about a variable or type. I've actually come to prefer this to real case-sensitive schemes.
VB.Net imports namespaces differently. If you want to use the File class, you can just say IO.File without needing to import System.IO at the top. The feature especially comes in handy when learning a new API with a few nested namespace layers, because you can import a top-level section of API, type the next namespace name, and you'll be prompted with a list of classes in that namespace. It's hard to explain here, but if you look for it and start using it, you'll really miss it when going back to C#. The main thing is that, for me at least, it really breaks my flow to need to jump to the top of the file to add yet another using directive for a namespace I may only use once or twice. In VB, that interruption is much less common.
VB.Net does background compilation. The moment your cursor leaves a line, you know whether or not that line compiles. This somewhat makes up for not highlighting class names, because part of why that's useful in C# is so you know that you typed it correctly. VB.Net gives you even more confidence in this regard.
I'm going to differ with the rest of the answers here... I don't think there is any problem with doing this. I do it regularly, and have absolutely 0 problems resulting from it.
If you use lowercase for the variable name you can easily differentiate the variable from the type, and the compiler will not confuse the two identifiers.
If you delete the variable declaration, the compiler will think other references to this variable now refer to the type, but it's not really a problem because those will be tagged as errors.
I have done the same thing in the past. I'm starting to move away from it though because Visual Studio will occasionally get confused when it auto formats the code and changes the casing on my static method calls to lower case. That is even more annoying than not being able to differentiate the variable and class names by case only. But, purely from technical perspective it should not cause any issues.
As Moayad notes, the compiler can tell the difference--but it's bad practice that can lead to maintenance issues and other side effects.
A better practice all-around is to try to name the variable in the context they're being used, rather than just the type name. This leads to self-documenting code and requires fewer comments (comments are greatly abused as an excuse to write dense code).
It's only safe as long as the compiler can always tell whether Foo means the class or the variable, and eventually you'll hit a case where it can't. Eric Lippert discusses the sort of thing that can go wrong on his blog.
I use this convention all the time, and it's never been a problem. The most natural name for a variable is often the class name, and therefore that's what you should call it (Best name for an arbitrary Line? line.).
The only downside is when some tool interprets the context incorrectly. For example, visual studio 2010 beta 1 sometimes uses the class highlight on variables named the same as the class. That's a bit annoying.
Context sensitivity is much closer to how I think than case sensitivity.
Well, this isn't the final answer, and I don't think there is a definitive one, but the general opinion seems to be that it's not a good idea to use this naming convention! There must be one true way to write nice VB.NET variable names though, and I don't like any of the alternatives...
Here are links to the official Microsoft guidelines for anyone who's interested, although they don't seem to cover this particular question (please correct me if I've missed it).
Visual Basic Naming Conventions: http://msdn.microsoft.com/en-us/library/0b283bse.aspx
Declared Element Names: http://msdn.microsoft.com/en-us/library/81ed9a62.aspx
Cheers all!
VB.NET isn't case sensitive! This equates to:
Foo Foo = new Foo(); // C#
As a standard in our team environment we would use:
Dim oFoo as New Foo 'VB.NET