Coding Style
-
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.