|
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.
Tiny Flying Elephant loves flying...
|
|
|
|
|
Hey there,
aren't underscores counted as modifier letters (no?), which are allowed in type identifiers ?
|
|
|
|
|
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:
class CMyCoolObjectThatDoesNothing
{
}
..
CMyCoolObjectThatDoesNothing mcotdnVar;
// 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...
Just my 2 South African cents 
controlSHIFT
[WinShareSpy] [Glossary Manager] [AfterThought Backup Lite]
All good things were meant to be improved
|
|
|
|
|
Heh... for what it's worth, i've written a good number of programs that all behave correctly in regards to the cls command...
Medication for us all
You think you know me, well you're wrong
|
|
|
|
|
|
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
it.
WedgeSoft
|
|
|
|
|
Gammill wrote:
WHY I should even consider
it.
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
David
Never forget: "Stay kul and happy" (I.A.)
David's thoughts / dnhsoftware.org / MyHTMLTidy
|
|
|
|
|
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 also got the blogging virus..[^]
|
|
|
|
|
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.
Kevin
|
|
|
|
|
Yeah, well, which part of the .NET framework doesn't understand unsigned variables? As far as my knowledge goes, all languages support that primitive type...
I also got the blogging virus..[^]
|
|
|
|
|
No, they don't. I think only C# and C++ do. Maybe Delphi? Remember there are 20+ .NET languages.
Kevin
|
|
|
|
|
You mean 2 languages and 18 hanger's on.
(sorry - having some int/uint pain today. Bad CLS! Bad!)
cheers,
Chris Maunder
|
|
|
|
|
|
Hungarian Notation gets discussed in these forums all the time. I'm personally against it. Read my previous posts to see why:
Post 1[^]
Post 2[^]
Regards,
Alvaro
Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is. -- GWB, 1999.
|
|
|
|
|
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.
Kevin
|
|
|
|
|
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 ).
Regards,
Alvaro
Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is. -- GWB, 1999.
|
|
|
|
|
Which Hungarian Notation are we taking about?
I think that putting the type of a variable in the variable name as prefix is redundant (with Intellisense at least), but Apps Hungarian is meaningful in my opinion.
Joel Polsky on Hungarian[^]
Larry Osterman on Hungarian[^]
There are hundreds of 'standards' all called Hungarian, and some are definitely superior to others.
That said, a good IDE makes naming conventions less important. And writing lpszTtt to indicate a tooltiptext string is horrible.
|
|
|
|
|
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:
<br />
int a, b, c<br />
<br />
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..
I also got the blogging virus..[^]
|
|
|
|
|
Bob Stanneveld wrote:
hongarian notation
Hungarian?
[worldspawn]
|
|
|
|
|
Hallo,
I am not following hungarian. I am using my own naming convention.
first I name the scope, than the type, than the name like
privStrUserName,pubBolLockedIn something like this.
Personally I like it. Maybe I am oldfashioned.
Chris
Vietiane (Laos)
|
|
|
|
|
This is the convention I have been using since day one and have carried it across all languages that I code with.
|
|
|
|
|
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 - Microsoft MVP - C++
|
|
|
|
|
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.
Kevin
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
