Coding standards
I'm a little confused by some of the coding standards for C#. They have some commonality but there are other places where they diverge. Some things I've yet to find a standard for. Even Microsoft's 101 samples don't stick to their own coding standards - and use sloppy component names such as editbox1, editbox2, etc. So, some questions:
1. Properties. Some standards say prefix private properties with m_ - and then say don't ever use underscores. That's obviously contradictory, and I don't particularly like underscores anyway. In Delphi we used to prefix with an f for private properties. What is the preferred method?
2. Types and variables of those types. The following code is supposed to be non-preferred because I've used a variable name the same as a type name, differing only by case (why oh why is C# case sensitive?). What should I be doing?
public enum Style {None, Overlap1, Overlap2, OverlapBoth};
public Style style;
3. Components. What is the naming convention? Some say Hungarian, others say don't ever use Hungarian again. Currently I've got things like buttonOk, radioButtonStyleNone, radioButtonStyleOverlapBot
4. Forms. I've got an EditNodeForm class contained within a file called EditNodeForm.cs. Should that be formEditNode, or what?
I realise this can be a subjective topic so all I want are opinions really. Thanks
Geoff M.
1. Properties. Some standards say prefix private properties with m_ - and then say don't ever use underscores. That's obviously contradictory, and I don't particularly like underscores anyway. In Delphi we used to prefix with an f for private properties. What is the preferred method?
2. Types and variables of those types. The following code is supposed to be non-preferred because I've used a variable name the same as a type name, differing only by case (why oh why is C# case sensitive?). What should I be doing?
public enum Style {None, Overlap1, Overlap2, OverlapBoth};
public Style style;
3. Components. What is the naming convention? Some say Hungarian, others say don't ever use Hungarian again. Currently I've got things like buttonOk, radioButtonStyleNone, radioButtonStyleOverlapBot
4. Forms. I've got an EditNodeForm class contained within a file called EditNodeForm.cs. Should that be formEditNode, or what?
I realise this can be a subjective topic so all I want are opinions really. Thanks
Geoff M.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The purpose of using FxCop is following standards even if they are not 100% consistence. By this way our code looks exactly like .NET code, interfaces look as user expects, and our libraries look like .NET libraries for user.
Except of this, FxCop teaches us a lot of useful things, not only about coding standards (which look sometimes strange). I found very useful to read help pages using links from FxCop messages. I decided to follow most of it's recommendations.
3-4. Default names given by form designer comply coding standards.
Except of this, FxCop teaches us a lot of useful things, not only about coding standards (which look sometimes strange). I found very useful to read help pages using links from FxCop messages. I decided to follow most of it's recommendations.
3-4. Default names given by form designer comply coding standards.
ASKER
"3-4. Default names given by form designer comply coding standards."
I disagree vehemently with this one. button1, button2, button3 is NOT a good way to name components. The question is, should it be:
buttonOk, buttonCancel
ButtonOk, ButtonCancel
OkButton, CancelButton
okButton, cancelButton
btnOk... etc etc?
Geoff M.
I disagree vehemently with this one. button1, button2, button3 is NOT a good way to name components. The question is, should it be:
buttonOk, buttonCancel
ButtonOk, ButtonCancel
OkButton, CancelButton
okButton, cancelButton
btnOk... etc etc?
Geoff M.
>>3-4. Default names given by form designer comply coding standards.
No they do not!
They may follow case notation, but are NOT best practice for coding standards. When I evaluate code, such as when interviewing a candidate, I will immediately think less of the programmer's ability if you have textbox1, textbox2, etc.
No they do not!
They may follow case notation, but are NOT best practice for coding standards. When I evaluate code, such as when interviewing a candidate, I will immediately think less of the programmer's ability if you have textbox1, textbox2, etc.
Designer cannot give meaningful names to variables, because it has no idea what is the purpose of using them. But it gives names according to standard. This doesn't mean that we must accept them without changes.
ASKER
Of course it doesn't know what to call them, but to leave them as button1, button2 is just sloppy programming. Like mrichmon, I think less of a programmer for doing this. As part of SIL2 work later this year (albeit Delphi rather than C#) I will be auditing code and if I see that, the code will be rejected automatically.
Mrichmon, how do you label components?
Thanks.
Geoff M.
Mrichmon, how do you label components?
Thanks.
Geoff M.
ASKER
Points split but only a B as no further discussion was forthcoming :-(
I still don't know how I should be labelling components!
Thanks anyway
Geoff M.
I still don't know how I should be labelling components!
Thanks anyway
Geoff M.
I never got the email saying you responded again asking about components.
But a B?
I think the responses here mostly (with a few exceptions I bet you can guess which) addressed your question completely.
No one can really give you a 100% hands down this is the correct way answer, as that doesn't exist. Depending on where you go you will end up with different standards, whether Hungarian, Camelcase, etc.
You need to decide what the standards ou will use are and stick to it.
If you want standards used by others then try using a tool like FXCop to conform to thier standard - and uncheck the portions that contradict.
But a B?
I think the responses here mostly (with a few exceptions I bet you can guess which) addressed your question completely.
No one can really give you a 100% hands down this is the correct way answer, as that doesn't exist. Depending on where you go you will end up with different standards, whether Hungarian, Camelcase, etc.
You need to decide what the standards ou will use are and stick to it.
If you want standards used by others then try using a tool like FXCop to conform to thier standard - and uncheck the portions that contradict.
ASKER
I asked four opinions and only got decent replies to two of them. Following EE guidelines, that only really qualifies as a B. If you re-read my original question, I was only asking for opinions.
If you are really that aggrieved by a B, ask the moderators to up it to an A and I'll agree, even if it does go against EE ethos.
Geoff M.
If you are really that aggrieved by a B, ask the moderators to up it to an A and I'll agree, even if it does go against EE ethos.
Geoff M.
ASKER
So let me get this straight:
1. Use camelCasing for private properties.
2. This example should be an "enum Style" for the enum, and a "Style LineStyle" for the property.
3/4. Nobody knows/agrees.
Personally I like the T prefix in Delphi for types. Thus your class can be called TSomething and a variable instance of it called Something. Also, why do all the standards say "don't prefix types with anything" and then go on to say "prefix interfaces with an I"?!?! Contradict themselves again - though I agree with the I part of it (which is the same as Delphi).
I'll keep this discussion open for a couple more days. Thanks.
Geoff M.