I'm writing an application using C++ in Visual Studio .NET. Since several days ago the application requires .NET Framework installed while no such requisitions in the last version. This requirement cannot be met because the program will be published and most of our end users do not have .NET installed. It is hard to distinguish the code differences between this and the last versions now becasue of too much code modification, and I have no idea about when the .NET framework was brought in. I simply take Visual Studio .NET as an upgrading C++ environment and never plan to take .NET framework.
Would any one give me hints that may take .NET into account so that I can keep it away from my application and no longer requiring .NET installed in running time? Bow.
During the last couple of years, I have worked on various code bases, some of which used Hongarian notation, some of which used a bastardised attempt at Hongarian, and some which had pure CamelCasing.
I must say, that with time, one stops caring, as long as the code is solid and logic well documented. However, I must admit, that if I have a choice, I will always employ a subset of Hongarian, and prefix member variables with a m_, ints with a n etc...
However, I have also bastardised Hongarian notation to suit my purposes, with a variation where class names are acronym-ised and prefixed to variable names (not pointers), such as:
// then again, I do have Intellisense, so typing these things is not a problem for me
On the subject of pointer variables, I always prefix with a p and then follow with a description of the object...
Anyway, the point I'm trying to make is that notation is important, but is also localised to the team or teams that will work with the code. If you work on an OSS project, I feel it would be good to have a standard notation that all contributors adhere to...
One good thing about touching base with Code Project,
now and again, even just to check the latest survey,
is what one learns. I moved to 2003 .NET MC++ a few
months ago. Work alone. And just pick up this and
that by what I read. I never heard of writing CLS
compliant code. So... One of the options should have
been: "Ever heard of it?" But, now that I have,
I'll look into it. I expect some of the comments of
the survey will help be to see WHY I should even consider
That is easy... CLS compliant means Common Language Specification compliant - when your code is CLS compliant, there is no problem to use it in another CLS compliant language.
Example: IIRC in MSIL you can have class with space inside it's name e.g "my Class" - you can't use in C# or VB.NET or or whatever .NET language you choose... If you read comments below there are more examples or possible problems with naming... there can be problems with types too. But we have CLS and every CLS code is granted to work from another .NET language. It's similar to writing in pure ANSI C for maximal portability
I don't know why nobody uses the hongarian notation anymore. In my opinion, it is one of the more clear naming conventions around. Prefixing variables with their types (except for classes) just makes the code a little bit easier to understand. Besides that, all the this.someVar makes me feel weird. I know that many people like intellisense to pop up a list with members and such, but I just don't like all the blue in my code.
Besides that, using the cls naming convention requires more comment and / or documentation because the variable names are so unclear..
I wonder how other developers feel about that naming convention..
I must agree with you Bob. We currently use this convention and from the little that I have read about the CLS convention, it adds lots of useless and meaningless statments to the code. So to get to your code you actaully need to wade through loads of junk and comments before you actually get to the good stuff.
Bob Stanneveld wrote: Besides that, all the this.someVar makes me feel weird. I know that many people like intellisense to pop up a list with members and such, but I just don't like all the blue in my code.
And now you take into account that various people might not have intellisense editors (gasp) and this.someVar is meaningless, is it a int, char, etc. Better to have this.m_iSomeVar, now we all know it is an int member variable, but wait we can't use an underscore, so that would be this.miSomeVar (which for me doesn't look as distinct as m_ does).
Also, what is wrong with unsigned variables?? I mean, if you know that you don't need the negative but you need the larger number, why is this wrong in CLS?
"Programming today is a race between software engineers striving to build bigger and
better idiot-proff programs, and the Universe trying to produce bigger and better idiots.
So far the Universe is winning." -- Rich Cook
RichardS wrote: Also, what is wrong with unsigned variables?? I mean, if you know that you don't need the negative but you need the larger number, why is this wrong in CLS?
To be CLS-compliant your code must be consumable by all .NET languages. Unsigned variables are not. However, it should be OK to use them for private and internal code. They just shouldn't be in the public/protected interface.
Alvaro, I'm the same as you in that I used to like Hungarian but now don't - pretty much for the reasons you cite. Also, like you I was forced not to use it and then found that I preferred it. My one concession to it is in class members where I think having a scope, not type, prefix improves readability. This would not matter so much if we all practiced the discipline of having short methods but we don't. An alternative to the scope prefixes though is to just qualify class members with the this reference. I also still use prefixes for controls. Though really instead of btnCustomer I should write customerButton.
Like you Kevin, I also like the idea of distinguishing class fields (member variables) inside the code. However, I've been wavering back and forth on what's the best way to handle it consistently.
For a long time I went with "this.variable" in my Java code. Then I moved to .NET and came back to using "m_variable", like I had in the old MFC days. But then I got into ASP.NET and realized that it was a pain in the butt to keep all the variables generated in the codebehind files with the m_ prefix. So I once again dropped it and went back to "this.variable". After a while I realized that my methods were littered with "this.something" and "this.someOtherThing" and that it was actually making it more difficult to read -- everything had "this." in front of it so it was pretty much pointless.
These days I've gone with the "no freaking prefix" policy for my ASP.NET sources. If my form has an OK button, it's name is simply "ok". If it has a lastName textbox, it's name is "lastName", and that's how I use it in the code -- no "this.". Plain and simple.
For separate library source files, I've maintained the m_ prefix, which I still like, and it helps keep the code CLS compliant (the topic of this survey ).
Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is. -- GWB, 1999.
I generally do not follow "hungarian notation" in it's strictest sense and I believe that aside from a "prefix" notation on the front of your variable it's also good to have a good descriptive name. However I follow a more moderate dialect that's briefly descriptive for certain variable types.
The prefixes that I generally tend to use would be:
"p" for pointer, I use this more commonly than the rest. The rest I use sparingly.
"dw" or "i" for dword or unsigned int, integer, generally to simply denote it's a number.
"sz" for NULL-Term string
"swz" for wide char
"uc" for unicode_string
"g_" for Global. I like to use the "_" because it's easier to search for it in the debugger as "G" itself can get you functions that start with "G". Now don't give me that you shouldn't use globals in programming, that's definately true when possible (and usually is possible) however sometimes globals can be useful for things like maintaining a debug state that doesn't directly interact with your program's logic.
I saw someone post in this thread that said that they don't use it because "they will be the only ones viewing the code" so I guess they do not have a job, at least not a real one...
Toby Opferman wrote: I generally do not follow "hungarian notation" in it's strictest sense
I don't believe anybody does that, because then you'll have to prefix you function names with the parameters and return type! There goes the intended readability..
Toby Opferman wrote: it's also good to have a good descriptive name.
That certainly is a good practice. I've seen to many student that write code like:
int a, b, c
/* large function body */
Not only will nobody know why the variables are there and what they are used for, but it just makes the code look ugly.
I also favor the prefix_ to indicate a variable that is used in more than one scope. But I make an exception for structs. These types should'nt have any member functions and therefore you can omit the scope prefix, because you don't have to distinguish between locals and member variables by the prefix, since the struct's variable name does it for you.
Toby Opferman wrote: I saw someone post in this thread that said that they don't use it because "they will be the only ones viewing the code" so I guess they do not have a job, at least not a real one...
That certainly is a bad practice. Everyone should not test their own code and reviewing your code with others helps to improve things a lot..
The whole casing thing is a problem, and I've been bitten by other things as well. I tend to write CLS Compliant projects, and then when my code is not CLS compliant, it's knowingly so, I set the attribute to say I know and accept the fact.
I find though that I often have a camel case private variable, and a first letter uppercase property, and that's not CLS compliant, apparently. You can use _ for the first letter of a private variable, in fact CLS compliance suggests this. I don't like that though.
Christian Graus wrote: I find though that I often have a camel case private variable, and a first letter uppercase property, and that's not CLS compliant, apparently.
I think the problem here is, e.g., VB. VB cannot understand a property defined this way because of case insensitivity. However, I'd have thought MS could have designed VB to cope with this. You can already have a type name and a variable name the same. Makes sense as they're in different namespaces.
George Carlin wrote: "Don't sweat the petty things, and don't pet the sweaty things." Jörgen Sigvardsson wrote: If the physicists find a universal theory describing the laws of universe, I'm sure the a**hole constant will be an integral part of that theory.
When I was developing .NET code, I used to run FxCop[^] before each check-in to VSS, and FxCop reports any non CLS-compliant code. However, it seems I was the only one in the office that practiced this
Running code through FxCop is a really bad way to start the day. "I don't like your naming convention", "get rid of that underscore", "why are initialising that value to null you idiot", "I don't like it when you contract string to str"
I write cls compliant code (as much as possible given the particulars of the project), but since internals are often renamed, why dones internal naming conventions make code "CLS" or "NON-CLS"? to me writing cls compliant code is writing code which complies to the standards of the common runtime language, not a common naming convention...
CLS compliant code must work with all first class .NET languages. VB.NET, for example, isn't case sensitive and uses "_" as a special character so you have to be careful with naming your accessible entity names. Private and internal names you don't have to worry about.
That begs the question though, why did Microsoft design a framework that way to begin with? It wouldn't have been difficult to have similar requirements for variable/function naming across languages. With the possible exception of Managed C++, the .NET languages are all either brand new or redesigns anyway, so it's not like there's any backward compatibility issues. I guess what I'm saying is, VB.NET is vastly different from VB6 anyway, why not go on and make its variable naming similar to C# and company?
The generation of random numbers is too important to be left to chance.