Coding Style
-
>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. -
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.
-
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.Following the example set by Microsoft that I find every time I need to trace some item in the registry, I now use GUIDs for everything except local variables that are only in use briefly. Since this makes even my own code completely unreadable, I start out with perfectly normal notation such as you describe, then use 'Find and Replace" to convert them all to GUIDs before releasing the final version. "Your village called -
They're missing their idiot." -
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.
Excellent job of summing it up! :-D
**"Be not overcome with evil, but overcome evil with good." -- Romans 12:21
-
>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?Paul Watson wrote: 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).
I've followed the Microsoft documentation where I append my data type to the end. Usually, it's something like this: FirstNameTextBox, YesNoCheckBox or maybe MyCustomException. That's for local variables. For instance variables and parameter values, I use the camel casing, so I might have a variable called sampleTextBox. Using the different casing helps me to identify scope. Andy Hochstetler
-
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.
True. I agree with most of your points. There... I'll have a more serious look at my ways and see what I can do :-D 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.