Coding Style
-
>User defined types (UDT's) are given a 3 letter prefix of "obj" [e.g. objMyType etc] and >All fields types have a 3 letter prefix [e.g intMyInt, blnMyBool, strMyString etc] Now how do you deal with all the classes in .NET? Hard to break them down to three letters and can be useless putting obj in front. regards, Paul Watson Bluegrass South Africa Brian Welsch wrote: "blah blah blah, maybe a potato?" while translating my Afrikaans. Crikey! ain't life grand?
I find over complicating your naming conventions nearly always leads to a miss-mash of partly used conventions and random prefixes, typically I use (regardless of language) All names a Capitalised et class DataConnection IDataConnection etc... I distinguish types with 5 very simple rules
o = object i.e oDataConnection = new DataConnection e = enum i.e eDataConnectionType = DataConnectionType.Default n = number i.e int nValue float nValue long nValue s = string i.e sString = ""b = bool i.e bool bDataConnection = true; constants are usually upper case i.e const int MAX_CONNECTIONS = 5; I try and avoid using _ within name eg Data_Connection. Member variables are prefixed with m then type, I try to stay away from public fields, i prefix private/protected members with an _ i.e _moConnection or _msString Properties have the smae name as the private member its accessing i.e _moConnection usually has the propertypublic DataConnection Connection { get { return _moConnection; } }I also dont put my braces on the same line i.e instead ofif(a != b) { a = b; b = d; }I doif(a != b) { a = b; b = c; }I havent got a clue if this is a "standard" or not its just something I have adopted over the years, initially grew from C++ development but applicable to everything else! James Simpson Web Developer imebgo@hotmail.com P S - This is what part of the alphabet would look like if Q and R were eliminated
Mitch Hedberg -
>User defined types (UDT's) are given a 3 letter prefix of "obj" [e.g. objMyType etc] and >All fields types have a 3 letter prefix [e.g intMyInt, blnMyBool, strMyString etc] Now how do you deal with all the classes in .NET? Hard to break them down to three letters and can be useless putting obj in front. regards, Paul Watson Bluegrass South Africa Brian Welsch wrote: "blah blah blah, maybe a potato?" while translating my Afrikaans. Crikey! ain't life grand?
True... I have difficulties with that at times. I'm trying to see if there is a comprehensive list of prefixes out there for the .NET BCL but I've failed miserably so far (i.e. over the last 20 minutes :rolleyes: ). I tend to try to make a prefix for it... if I can't I'll use "nobj" to say it's a .NET object. What you think? Regards, Brian Dela :-) http://www.briandela.com IE 6 required.
http://www.briandela.com/rss/newsrss.xml RSS Feed
MFC.NET Application Wizard Mix .NET and MFC easily. -
Hey Lads, Just wondering what sort of coding style (conventions?) people here are using for C#??? Actually.. does this class as a programming question???? If it is I'll move it and sorry in advance. Quick overview of what I tend to use... Class Names: Start with Uppercase Letter [e.g. DataConnection] Method Names: Start with Uppercase Letter and tend to be Verb+Noun [e.g. GetDbConnectionString()] Properties: Start with Uppercase letter and no prefix [e.g. public bool Enabled] Fields: All fields types have a 3 letter prefix [e.g intMyInt, blnMyBool, strMyString etc] Class members put the letter "m" before this 3 letter prefix [e.g. mstrMyString etc] User defined types (UDT's) are given a 3 letter prefix of "obj" [e.g. objMyType etc] Collections: Arrays, Arraylists etc.... I still haven't come up with a style for defining collections so I'd appreciate some "guidance"/"suggestions" from my fellow CPians. I'm currently prefixing the 3 letter prefix with a "c" to denote it as a collection and in general the name will end in an "s" to show that there is generally more than 1 "element". Anyway... I'm thinking about changing this style if it doesn't confirm to the "norm" for C#. What to people think??? Any examples of good styles and style documents would be appreciated. Regards, Brian Dela :-) http://www.briandela.com IE 6 required.
http://www.briandela.com/rss/newsrss.xml RSS Feed
MFC.NET Application Wizard Mix .NET and MFC easily.This link may be useful http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp[^] It might be out of date now, somebody gave me the link when I asked a similar question in March 02. Michael 'Logic, my dear Zoe, merely enables one to be wrong with authority.' - The Doctor: The Wheel in Space
-
Same as you for methods, classes but I use Hungarian for fields cheers, Chris Maunder
Do you have a code style doc of some sort Chris or is it all in your head? Regards, Brian Dela :-) http://www.briandela.com IE 6 required.
http://www.briandela.com/rss/newsrss.xml RSS Feed
MFC.NET Application Wizard Mix .NET and MFC easily. -
True... I have difficulties with that at times. I'm trying to see if there is a comprehensive list of prefixes out there for the .NET BCL but I've failed miserably so far (i.e. over the last 20 minutes :rolleyes: ). I tend to try to make a prefix for it... if I can't I'll use "nobj" to say it's a .NET object. What you think? Regards, Brian Dela :-) http://www.briandela.com IE 6 required.
http://www.briandela.com/rss/newsrss.xml RSS Feed
MFC.NET Application Wizard Mix .NET and MFC easily.>if I can't I'll use "nobj" to say it's a .NET object. What you think hehe, naah, don't like that idea. To be honest I have variable naming diarrhea. e.g. a TextBox for a first name is
textboxFirstName. I do trim it though if the class name is too long (like SqlDataReader). regards, Paul Watson Bluegrass South Africa Brian Welsch wrote: "blah blah blah, maybe a potato?" while translating my Afrikaans. Crikey! ain't life grand? -
Hey Lads, Just wondering what sort of coding style (conventions?) people here are using for C#??? Actually.. does this class as a programming question???? If it is I'll move it and sorry in advance. Quick overview of what I tend to use... Class Names: Start with Uppercase Letter [e.g. DataConnection] Method Names: Start with Uppercase Letter and tend to be Verb+Noun [e.g. GetDbConnectionString()] Properties: Start with Uppercase letter and no prefix [e.g. public bool Enabled] Fields: All fields types have a 3 letter prefix [e.g intMyInt, blnMyBool, strMyString etc] Class members put the letter "m" before this 3 letter prefix [e.g. mstrMyString etc] User defined types (UDT's) are given a 3 letter prefix of "obj" [e.g. objMyType etc] Collections: Arrays, Arraylists etc.... I still haven't come up with a style for defining collections so I'd appreciate some "guidance"/"suggestions" from my fellow CPians. I'm currently prefixing the 3 letter prefix with a "c" to denote it as a collection and in general the name will end in an "s" to show that there is generally more than 1 "element". Anyway... I'm thinking about changing this style if it doesn't confirm to the "norm" for C#. What to people think??? Any examples of good styles and style documents would be appreciated. Regards, Brian Dela :-) http://www.briandela.com IE 6 required.
http://www.briandela.com/rss/newsrss.xml RSS Feed
MFC.NET Application Wizard Mix .NET and MFC easily.I do the same for class, method, and property names as you. For local variables, fields, and collections though, I differ greatly: NO FREAKIN' PREFIXES! I've seen the light and I've been liberated from prefix hell. It just gets in the way of the real name and it's rarely useful. I admit it felt odd for a while not using
strandbandnin front of my variables, but now it's great. Instead of nSize, it's just size. Instead of bEnabled, it's enabled. And instead of strName, it's name. Much clearer and easier to read, don't you think? From what I understand, the .NET and Java camps have done away with prefix notation. If you ever decide to do the same, you'll understand why they did it. For collections, I just use the plural version of whatever the collection holds: names, bunnies, incredibleThings, fruitEatingTigers, whatevers. It couldn't be much simpler. The only prefix I've kept from the MFC days ism_for fields (member variables). It's just a better alternative tothis., in my opinion. It's only 2 letters (instead of 5), it's clear, and since it's part of the name it's always there, unlikethis., which is optional. Regards, Alvaro
He who laughs last, thinks slowest.
-
>if I can't I'll use "nobj" to say it's a .NET object. What you think hehe, naah, don't like that idea. To be honest I have variable naming diarrhea. e.g. a TextBox for a first name is
textboxFirstName. I do trim it though if the class name is too long (like SqlDataReader). regards, Paul Watson Bluegrass South Africa Brian Welsch wrote: "blah blah blah, maybe a potato?" while translating my Afrikaans. Crikey! ain't life grand?I use txtMyTextBox for textboxes in ASP.NET. I really shoudl try to come up with a consistent way of naming these things. Regards, Brian Dela :-) http://www.briandela.com IE 6 required.
http://www.briandela.com/rss/newsrss.xml RSS Feed
MFC.NET Application Wizard Mix .NET and MFC easily. -
Do you have a code style doc of some sort Chris or is it all in your head? Regards, Brian Dela :-) http://www.briandela.com IE 6 required.
http://www.briandela.com/rss/newsrss.xml RSS Feed
MFC.NET Application Wizard Mix .NET and MFC easily.Docs? That implies some kind of forward planning, right? cheers, Chris Maunder
-
I do the same for class, method, and property names as you. For local variables, fields, and collections though, I differ greatly: NO FREAKIN' PREFIXES! I've seen the light and I've been liberated from prefix hell. It just gets in the way of the real name and it's rarely useful. I admit it felt odd for a while not using
strandbandnin front of my variables, but now it's great. Instead of nSize, it's just size. Instead of bEnabled, it's enabled. And instead of strName, it's name. Much clearer and easier to read, don't you think? From what I understand, the .NET and Java camps have done away with prefix notation. If you ever decide to do the same, you'll understand why they did it. For collections, I just use the plural version of whatever the collection holds: names, bunnies, incredibleThings, fruitEatingTigers, whatevers. It couldn't be much simpler. The only prefix I've kept from the MFC days ism_for fields (member variables). It's just a better alternative tothis., in my opinion. It's only 2 letters (instead of 5), it's clear, and since it's part of the name it's always there, unlikethis., which is optional. Regards, Alvaro
He who laughs last, thinks slowest.
Alvaro Mendez wrote: I've seen the light and I've been liberated from prefix hell. It just gets in the way of the real name and it's rarely useful. I admit it felt odd for a while not using str and b and n in front of my variables, but now it's great. Instead of nSize, it's just size. Instead of bEnabled, it's enabled. And instead of strName, it's name. Much clearer and easier to read, don't you think? For my own code, code where I know that 99% of the time I'll be the only person that sees it then I think that is fine. But code thats going to be worked on within a group and team needs to be treated differently I think. When I get code from another source, CP for example, I like to be able to glance through it and be able to see what is what without having to scroll up and see declarations/difinitions to see what the type is. I find it is much quicker for me to understand "external" code this way. Regards, Brian Dela :-) http://www.briandela.com IE 6 required.
http://www.briandela.com/rss/newsrss.xml RSS Feed
MFC.NET Application Wizard Mix .NET and MFC easily. -
Docs? That implies some kind of forward planning, right? cheers, Chris Maunder
lol. True... Regards, Brian Dela :-) http://www.briandela.com IE 6 required.
http://www.briandela.com/rss/newsrss.xml RSS Feed
MFC.NET Application Wizard Mix .NET and MFC easily. -
I do the same for class, method, and property names as you. For local variables, fields, and collections though, I differ greatly: NO FREAKIN' PREFIXES! I've seen the light and I've been liberated from prefix hell. It just gets in the way of the real name and it's rarely useful. I admit it felt odd for a while not using
strandbandnin front of my variables, but now it's great. Instead of nSize, it's just size. Instead of bEnabled, it's enabled. And instead of strName, it's name. Much clearer and easier to read, don't you think? From what I understand, the .NET and Java camps have done away with prefix notation. If you ever decide to do the same, you'll understand why they did it. For collections, I just use the plural version of whatever the collection holds: names, bunnies, incredibleThings, fruitEatingTigers, whatevers. It couldn't be much simpler. The only prefix I've kept from the MFC days ism_for fields (member variables). It's just a better alternative tothis., in my opinion. It's only 2 letters (instead of 5), it's clear, and since it's part of the name it's always there, unlikethis., which is optional. Regards, Alvaro
He who laughs last, thinks slowest.
Exactly. Why prefix strongly typed fields? Many people will argue that it gets to be too much of a hassle to scroll up to see what the type of a field is, if they don't remember. If scrolling is that much of an issue, maybe the code should be refactored and split into smaller methods. Either that, or use a good developer tool so that if you wonder what type something is, all you have to do is mouse over it.
-
Alvaro Mendez wrote: I've seen the light and I've been liberated from prefix hell. It just gets in the way of the real name and it's rarely useful. I admit it felt odd for a while not using str and b and n in front of my variables, but now it's great. Instead of nSize, it's just size. Instead of bEnabled, it's enabled. And instead of strName, it's name. Much clearer and easier to read, don't you think? For my own code, code where I know that 99% of the time I'll be the only person that sees it then I think that is fine. But code thats going to be worked on within a group and team needs to be treated differently I think. When I get code from another source, CP for example, I like to be able to glance through it and be able to see what is what without having to scroll up and see declarations/difinitions to see what the type is. I find it is much quicker for me to understand "external" code this way. Regards, Brian Dela :-) http://www.briandela.com IE 6 required.
http://www.briandela.com/rss/newsrss.xml RSS Feed
MFC.NET Application Wizard Mix .NET and MFC easily.I used to think the same as you, and for years I used Hungarian notation. But here are some things to consider. 1. Chances are that for the most part, the code you're going to look at will be your own. That's been my experience at least; when working in a group, I spend most of the time looking at my own code. 2. Many times the type of the variable can be deduced by the name. For example, you wouldn't look at a variable called
lastNameand wonder what it's type is. How about a variable calledevilGiraffes? The name implies that it's a collection of EvilGiraffe objects. 3. If you write your code in a modular fashion, delegating small tasks to individual methods, the variable's declaration and where it gets used will be in close proximity. So if you really need to know its type, it's nearby. Where it can become a problem is in really large methods, where the variable is declared somewhere at the top and you have to scroll to figure out its type. But I argue that these type of methods are few and far between. Also, if you run other's people's code inside the debugger, you'll see the variable's name, value, and type inside the Watch windows, so it's not necessary to search for its declaration to determine it's type. 3. Coming up with and keeping track of all the different prefixes can be a pain, and an even greater pain is enforcing it among a group of developers. If I now joing your group and I prefer to usebinsteadblnfor my booleans, it's gonna suck for me, and maybe for you too since I may forget to useblnand usebinstead. So it's a lot easier to enforce the rule of "no prefixes". Now people just worry about what to call their variables and they don't need to also remember to tag it with the right prefix every time. 4. I don't remember where I read that prefixes suck if the variable type gets changed, since now you have to rename it. But that's not really a big deal, I don't think, since the Find/Replace box can take care of that pretty easily. Still, it could be noted as another point in favor of "no prefixes". Regards, Alvaro
He who laughs last, thinks slowest.
-
Hey Lads, Just wondering what sort of coding style (conventions?) people here are using for C#??? Actually.. does this class as a programming question???? If it is I'll move it and sorry in advance. Quick overview of what I tend to use... Class Names: Start with Uppercase Letter [e.g. DataConnection] Method Names: Start with Uppercase Letter and tend to be Verb+Noun [e.g. GetDbConnectionString()] Properties: Start with Uppercase letter and no prefix [e.g. public bool Enabled] Fields: All fields types have a 3 letter prefix [e.g intMyInt, blnMyBool, strMyString etc] Class members put the letter "m" before this 3 letter prefix [e.g. mstrMyString etc] User defined types (UDT's) are given a 3 letter prefix of "obj" [e.g. objMyType etc] Collections: Arrays, Arraylists etc.... I still haven't come up with a style for defining collections so I'd appreciate some "guidance"/"suggestions" from my fellow CPians. I'm currently prefixing the 3 letter prefix with a "c" to denote it as a collection and in general the name will end in an "s" to show that there is generally more than 1 "element". Anyway... I'm thinking about changing this style if it doesn't confirm to the "norm" for C#. What to people think??? Any examples of good styles and style documents would be appreciated. Regards, Brian Dela :-) http://www.briandela.com IE 6 required.
http://www.briandela.com/rss/newsrss.xml RSS Feed
MFC.NET Application Wizard Mix .NET and MFC easily.This is what I do: FunctionsAreLikeThis() PropertiesAreLikeThis ClassesAreLikeThis _PrivateFieldsAreLikeThis variablesinfunctionsarelikethis I do not allow any public fields, just properties. I do not use any prefixes or suffixes, except the private fields one and some with event handling (EventHandler at the end of delegates).
-
Hey Lads, Just wondering what sort of coding style (conventions?) people here are using for C#??? Actually.. does this class as a programming question???? If it is I'll move it and sorry in advance. Quick overview of what I tend to use... Class Names: Start with Uppercase Letter [e.g. DataConnection] Method Names: Start with Uppercase Letter and tend to be Verb+Noun [e.g. GetDbConnectionString()] Properties: Start with Uppercase letter and no prefix [e.g. public bool Enabled] Fields: All fields types have a 3 letter prefix [e.g intMyInt, blnMyBool, strMyString etc] Class members put the letter "m" before this 3 letter prefix [e.g. mstrMyString etc] User defined types (UDT's) are given a 3 letter prefix of "obj" [e.g. objMyType etc] Collections: Arrays, Arraylists etc.... I still haven't come up with a style for defining collections so I'd appreciate some "guidance"/"suggestions" from my fellow CPians. I'm currently prefixing the 3 letter prefix with a "c" to denote it as a collection and in general the name will end in an "s" to show that there is generally more than 1 "element". Anyway... I'm thinking about changing this style if it doesn't confirm to the "norm" for C#. What to people think??? Any examples of good styles and style documents would be appreciated. Regards, Brian Dela :-) http://www.briandela.com IE 6 required.
http://www.briandela.com/rss/newsrss.xml RSS Feed
MFC.NET Application Wizard Mix .NET and MFC easily.http://www.ecma-international.org/publications/standards/Ecma-334.htm You can find a link to the actual PDF file at the bottom. Didn't read the replies to your post, sorry if it's a repost. Vikram.
I'd rather use VB than use COBOL. And I'd rather be eaten by a crocodile than use VB. Put up your ad on CP for free- NO strings attached! Shameless plug: http://www.geocities.com/vpunathambekar
-
Hey Lads, Just wondering what sort of coding style (conventions?) people here are using for C#??? Actually.. does this class as a programming question???? If it is I'll move it and sorry in advance. Quick overview of what I tend to use... Class Names: Start with Uppercase Letter [e.g. DataConnection] Method Names: Start with Uppercase Letter and tend to be Verb+Noun [e.g. GetDbConnectionString()] Properties: Start with Uppercase letter and no prefix [e.g. public bool Enabled] Fields: All fields types have a 3 letter prefix [e.g intMyInt, blnMyBool, strMyString etc] Class members put the letter "m" before this 3 letter prefix [e.g. mstrMyString etc] User defined types (UDT's) are given a 3 letter prefix of "obj" [e.g. objMyType etc] Collections: Arrays, Arraylists etc.... I still haven't come up with a style for defining collections so I'd appreciate some "guidance"/"suggestions" from my fellow CPians. I'm currently prefixing the 3 letter prefix with a "c" to denote it as a collection and in general the name will end in an "s" to show that there is generally more than 1 "element". Anyway... I'm thinking about changing this style if it doesn't confirm to the "norm" for C#. What to people think??? Any examples of good styles and style documents would be appreciated. Regards, Brian Dela :-) http://www.briandela.com IE 6 required.
http://www.briandela.com/rss/newsrss.xml RSS Feed
MFC.NET Application Wizard Mix .NET and MFC easily.I worry less about style than I do about readability and meaning. Very little meaning is conveyed in name mangled type scheme, at least for me. More keys to type, more refactoring to do when its type changes, and harder to read. I think deep down I prefer loosely typed languages (no comment from the peanut gallery, please). I really don't care if it's a string, an int, a double, or a cosmic constant. I just want it to work right. Marc Latest AAL Article My blog Join my forum!
-
I do the same for class, method, and property names as you. For local variables, fields, and collections though, I differ greatly: NO FREAKIN' PREFIXES! I've seen the light and I've been liberated from prefix hell. It just gets in the way of the real name and it's rarely useful. I admit it felt odd for a while not using
strandbandnin front of my variables, but now it's great. Instead of nSize, it's just size. Instead of bEnabled, it's enabled. And instead of strName, it's name. Much clearer and easier to read, don't you think? From what I understand, the .NET and Java camps have done away with prefix notation. If you ever decide to do the same, you'll understand why they did it. For collections, I just use the plural version of whatever the collection holds: names, bunnies, incredibleThings, fruitEatingTigers, whatevers. It couldn't be much simpler. The only prefix I've kept from the MFC days ism_for fields (member variables). It's just a better alternative tothis., in my opinion. It's only 2 letters (instead of 5), it's clear, and since it's part of the name it's always there, unlikethis., which is optional. Regards, Alvaro
He who laughs last, thinks slowest.
Alvaro Mendez wrote: the only prefix I've kept from the MFC days is m_ for fields (member variables). Same here. :)
**"It is impossible to rightly govern the world without God and the Bible." -- George Washington
-
I used to think the same as you, and for years I used Hungarian notation. But here are some things to consider. 1. Chances are that for the most part, the code you're going to look at will be your own. That's been my experience at least; when working in a group, I spend most of the time looking at my own code. 2. Many times the type of the variable can be deduced by the name. For example, you wouldn't look at a variable called
lastNameand wonder what it's type is. How about a variable calledevilGiraffes? The name implies that it's a collection of EvilGiraffe objects. 3. If you write your code in a modular fashion, delegating small tasks to individual methods, the variable's declaration and where it gets used will be in close proximity. So if you really need to know its type, it's nearby. Where it can become a problem is in really large methods, where the variable is declared somewhere at the top and you have to scroll to figure out its type. But I argue that these type of methods are few and far between. Also, if you run other's people's code inside the debugger, you'll see the variable's name, value, and type inside the Watch windows, so it's not necessary to search for its declaration to determine it's type. 3. Coming up with and keeping track of all the different prefixes can be a pain, and an even greater pain is enforcing it among a group of developers. If I now joing your group and I prefer to usebinsteadblnfor my booleans, it's gonna suck for me, and maybe for you too since I may forget to useblnand usebinstead. So it's a lot easier to enforce the rule of "no prefixes". Now people just worry about what to call their variables and they don't need to also remember to tag it with the right prefix every time. 4. I don't remember where I read that prefixes suck if the variable type gets changed, since now you have to rename it. But that's not really a big deal, I don't think, since the Find/Replace box can take care of that pretty easily. Still, it could be noted as another point in favor of "no prefixes". Regards, Alvaro
He who laughs last, thinks slowest.
Amen, Bro'! Marc Latest AAL Article My blog Join my forum!
-
I worry less about style than I do about readability and meaning. Very little meaning is conveyed in name mangled type scheme, at least for me. More keys to type, more refactoring to do when its type changes, and harder to read. I think deep down I prefer loosely typed languages (no comment from the peanut gallery, please). I really don't care if it's a string, an int, a double, or a cosmic constant. I just want it to work right. Marc Latest AAL Article My blog Join my forum!
Marc Clifton wrote: I think deep down I prefer loosely typed languages (no comment from the peanut gallery, please). I really don't care if it's a string, an int, a double, or a cosmic constant. I just want it to work right. Same here. And that's one of the reasons we went with script for the rendering and sizing/positioning of elements in Fluid - otherwise we would have to use reflection, because the renderers have to deal with lots of control classes.
**"The real and lasting victories are those of peace, and not of war." -- Ralph Waldo Emerson
-
Hey Lads, Just wondering what sort of coding style (conventions?) people here are using for C#??? Actually.. does this class as a programming question???? If it is I'll move it and sorry in advance. Quick overview of what I tend to use... Class Names: Start with Uppercase Letter [e.g. DataConnection] Method Names: Start with Uppercase Letter and tend to be Verb+Noun [e.g. GetDbConnectionString()] Properties: Start with Uppercase letter and no prefix [e.g. public bool Enabled] Fields: All fields types have a 3 letter prefix [e.g intMyInt, blnMyBool, strMyString etc] Class members put the letter "m" before this 3 letter prefix [e.g. mstrMyString etc] User defined types (UDT's) are given a 3 letter prefix of "obj" [e.g. objMyType etc] Collections: Arrays, Arraylists etc.... I still haven't come up with a style for defining collections so I'd appreciate some "guidance"/"suggestions" from my fellow CPians. I'm currently prefixing the 3 letter prefix with a "c" to denote it as a collection and in general the name will end in an "s" to show that there is generally more than 1 "element". Anyway... I'm thinking about changing this style if it doesn't confirm to the "norm" for C#. What to people think??? Any examples of good styles and style documents would be appreciated. Regards, Brian Dela :-) http://www.briandela.com IE 6 required.
http://www.briandela.com/rss/newsrss.xml RSS Feed
MFC.NET Application Wizard Mix .NET and MFC easily.Properties / public fields:
MemberNamemember variablesm_MemberNamemethod-level variables:membernamecontrols - haven't really made up my mind here, but I think a prefix is warranted for controlstextboxControlName or txtControlName comboControlName or cmbControlNamecollections: ClassNameCollection ClassNameDictionary ClassNameHashlist classes: NO "C" at the beginning of the name!!**"Worry not that no one knows of you; seek to be worth knowing." -- Confucius
-
This is what I do: FunctionsAreLikeThis() PropertiesAreLikeThis ClassesAreLikeThis _PrivateFieldsAreLikeThis variablesinfunctionsarelikethis I do not allow any public fields, just properties. I do not use any prefixes or suffixes, except the private fields one and some with event handling (EventHandler at the end of delegates).
Same here mate, except PrivateFieldsAreLikeThat_ because my _GlobalVariablesAreLikeThisWhenIOccaisionalyUseThemInC++ Got rid of the m_ habit on my last C++ project and feel much better for it. Ryan.