|
The comments are a bit much. I am not one of these "the code itself should be the comments" people, but if I find I need to do something out of the ordinary to make the code work, I will write an extensive comment along with the code. I KNOW I won't remember why I did that weird thing one month, much less six months, from now.
I will also comment some trivial changes if they come from a client edict that is the opposite of what they requested just a few weeks ago. That way when they ask for it to be changed back in a few months and complain that WE broke the code I can point to the date and say we changed it per your instructions.
I like having the variables all at the top of a function, but then I am old (pre-DOS 5 and the MS C 5.1 compiler). I don't like having to hunt for a variable declaration. Pascal also likes to have the variables defined before the code too. Shoot, COBOL has it's own section for the things.
|
|
|
|
|
My Team and me defined a Standard way of coding for our stuff, pretty lot of Basic rules in there.
Comments -> As much as needed as less as possible.
Pretty dmn good because a XML commentblock can explain the whole method and can be used in extracting a documentation out of your code.
variable declaration -> Classinternal starting with _ and lower letter / incoming externals starting with capital letter
Declaring the variables at the top of the method lets you make it a Region block if there are a lot so you can collapse that Region and don't get bothered by all the declarations
and yeah what i do and love a lot -> regioning #Region "dumbShit" //Code// #endregion
that gives me the possibility to comment the Region and tell everyone what to find in here, thats a plus for getting faster through the code and to the desired line (imo)
just some tips from out Styleguide 
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
Ideally, every coding standard rule will have a rationale as to what benefit the rule brings.
Variables should be defined as close to their first use as possible in general. If they are re-used several times, I always redeclare them every time in a new {} block within the method to not accidentally re-use a value from the previous block.
Those comments are silly, you are exaggerating there, right? If not, the comments are such that you could possibly generate them with a tool (think of e.g. GhostDoc). It would even be a nice exercise to write such a tool! 
Edit: code comment should mostly explain why something is being done, not what is being done, because the what is mostly self explanatory, or can be found out using debugging. The why is very hard to find out.
Wout
modified 13-Feb-14 10:40am.
|
|
|
|
|
I'm not joking in the least about the commenting standards. If it were allowed, I would paste an untouched, large block of code, or even share a file, just to put it out there.
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
I am the programming department of my company, and I still adhere to point 2 almost religiously. It goes with the idea of self-documenting code: if I come to a piece I'd written some time earlier and need to remember the type and initialized value for PersonId, I know where to look. I can look at the top of the code block much faster than I can pull up and use a search tool.
As for point 1, I find that commenting "obvious" code is useful: what may be obvious today, when writing it, will not be so obvious when I have to revise the code four years later. My personal standard, though, is to make comments meaningful.
|
|
|
|
|
Gregory.Gadow wrote: I'd written some time earlier and need to remember the type and initialized value for PersonId, I know where to look. I can look at the top of the code block much faster than I can pull up and use a search tool.
Ctrl-click.
Wout
|
|
|
|
|
The problem with comments is that they are often not changed in sync with code updates. Another one is that meaningful comment today is often meaningless tomorrow. I am trying my best creating meaningful comments and this is an art and continuous learning.
Similarly I like important declarations at the top but I declare "utility" variables at the point of use.
|
|
|
|
|
Member 10088171 wrote: The problem with comments is that they are often not changed in sync with code updates. Another one is that meaningful comment today is often meaningless tomorrow. I am trying my best creating meaningful comments and this is an art and continuous learning
The problem with that entire statement however is it means that either code reviews are not occurring at all or that they are not being taken seriously.
If code reviews are done correctly then an incorrect comment should not show up.
|
|
|
|
|
There are no good uniform standards for commenting code (no intelliSense either) and despite best efforts issues with code comments are missed even by best reviewers. One of the more practical approach is using asserts and exceptions instead of comments. When meaningful comments are necessary I also add time stamp showing comment/code updates.
modified 13-Feb-14 15:46pm.
|
|
|
|
|
Member 10088171 wrote: and despite best efforts issues with code comments are missed even by best reviewers.
So are code bugs.
But reviews are on-going and the next go around is another chance to correct it.
|
|
|
|
|
The comments I add are generally for myself, especially if it's a method, control or a class I've never used before I find it useful to help me understand the implementation, especially if I know I will be using it again.
I don't add the obvious <c style="color:green;">// Add two numbers // Return obvious value but I might add the <c style="color:green;">// Add X and Y here or the later result will have a phase offset type comments.
I should add that I don’t recall the last time when someone stopped by or emailed with a request for an explanation as to how my code works or how to use it. (They may question the methods but not madness.  )
It was broke, so I fixed it.
|
|
|
|
|
I find both these standards odd.
I've been using RCG (Ravi's Commenting Guidelines™) for 20 years and they have served me and my teammates well. The guidelines are simple:- Strip out all code within blocks (except block delimiters - i.e.
if, do, for, while and switch code boundaries). - The remaining code and comments should clearly represent the method's psuedocode. If it doesn't, you need to add comments.
The coding standard about declaring all local variables at the start of a method is complete nonsense, IMHO. To maximize readability, local variables should be declared on first use within the block to which they're scoped.
This would cause me to rewrite your example method thusly:
private MyClass MyMethod()
{
int count = 0;
foreach (MyFileObj file in _myFileCollection) {
if (file.Name.Length <= 20) {
file.CopyTo(@"C:\SomePath\" + file.Name);
count++;
}
}
MyClass someObj = new MyClass();
someObj.FileCount = count;
return someObj;
}/ravi
|
|
|
|
|
That's an interesting concept, and I may try and adapt that style of commenting. It's simple to understand and I believe it may work nicely. Even if they don't want to change it, I may adapt it for my personal coding standards. Thanks for the input, Ravi.
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
When Code Complete was first published there was actually a chapter dedicated to this. The idea was that you would design your code with comments. It would go something along these lines...
step 1 was to write comments of how the code would work.
You could in theory then have a review meeting of just those comments. This in turn causes you to get a better understanding of what you are trying achieve.
step 2 was to add the code
-(int)add: (int)a b:(int)b
{
return a+b;
}
More importantly is that if you did step 1 properly then in theory someone else could do step 2 just by implementing your comments.
we did something similar at my first programming job out of college (20++ years ago) and it helped in slowing things down to get you thinking before writing. I don't follow it to the same detail today but I do find at times when I am working on something a bit complex to follow similar steps.
think of it like a mental dump of what you are thinking at the time you write the code. we have all asked the question when reading someone else's code.
What were they thinking when they wrote this piece of code?
I would take the time to learn more of how and where these standards started. there is generally a wisdom or history behind things like this and knowing that can help more than the actual standard itself.
you want something inspirational??
|
|
|
|
|
Very informative. I appreciate it. As previously stated, my manager has extensive experience with multiple languages. And I'm almost certain it came from quite a long while ago. Also, they have a lot of contractors (myself included) come through here. So I'm thinking the extensive commenting style may be in place to more or less protect future contractors and such from becoming easily confused. Who knows, I could be wrong.
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Matt U. wrote: These are just a few examples.
The examples you gave are excessive.
The declaration of variables at the top is actually a hold over from C programming.
|
|
|
|
|
But C# is not C. Is it necessary? I've learned throughout the life of this thread that it doesn't matter. It isn't necessarily good or bad. But does it benefit in any manner when coding in C#?
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Matt U. wrote: But does it benefit in any manner when coding in C#?
whether it benefits in any manner is only a question that can be answered by those who created the coding the standards you are speaking of. from a language perspective though it makes where the variables are defined if you referring to code performance getting improved.
you want something inspirational??
|
|
|
|
|
Matt U. wrote: But C# is not C. Is it necessary?
Of course not. I was merely providing a historical source for why someone would do that.
If you feel feisty you might ask if that is such a good idea why neither C#, Java nor C++ language creators didn't require it.
Matt U. wrote: But does it benefit in any manner when coding in C#?
It might make someone more comfortable. Or it might might have made someone more comfortable 10 years ago but that guy has retired now (or gotten a different job.)
|
|
|
|
|
I understand your point and I appreciate the insight. I'm just dealing with it, I have no control over it. It was simply against just about everything I've ever read/been told. But you live and you learn, right?
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Just to play devil's advocate a little, it is not necessarily the standard about commenting that is at fault, but the standard of commenting.
private void Process(MyFileObj myFile)
{
if (myFile != null)
{
myFile.StripBadData();
_myFileCollection.Add(myFile);
}
}
Certainly if someone really wrote code with names like 'myFileCollection' they'll need comments 
Oh, and the thing you missed completely was a method comment which should have explained what 'process my file' means in business terms - as processMyfile is too generic in all but the smallest of applications.
MVVM # - I did it My Way
___________________________________________
Man, you're a god. - walterhevedeich 26/05/2011
.\\axxx
(That's an 'M')
|
|
|
|
|
A very good point indeed.
You might even extend that to the trivial example of commenting a statement like
i++;
For one you may want to comment on why you chose to use post-increment rather than the more efficient preincrement. Or, better yet, you might comment on why you need to increment this variable at this precise moment - or what it is counting anyway! 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
I see very little - if any - benefit in declaring all local variables at the start of a method. To the contrary, it's bound to cause problems:
1. Variables that are being used much later may not have to be allocated at all, depending on the flow of control. You may end up spending resources and processing time for the initialization (and release) of data you never need! This is specifically true if you make a sanity check on the method arguments (which you alwys should) and go for a premature return.
2. When you maintain the code, it's often useful to see how a local variable has been initialized. This gets harder when the variables are grouped a long way up, and you can't see at a glance whether it's being changed between the declaration and the spot you're about to edit.
3. You shouldn't keep a hold on resources that you no longer need: the only way to reliably and maintainably (is that a word?) free up the resources required by a variable is declaring it within a code block. I even sometimes use a code block as a means to denote a specific variable's lifetime! You (or your manager) might consider this just as a'nice to have' feature, but it quickly becomes a necessity when you program concurrent threads using locks. There's no way in hell you're going to keep your locks over an entire method!
P.S.:
4. How do you do exceptions? I suspect your manager has never implemented a catch block, did he? 
5. Why do you think C++11 has been changed to end the lifetime of for loop counters at the end of the loop?
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
modified 14-Feb-14 6:11am.
|
|
|
|
|
I too am on a project (about a million SLOC) that forces outdated coding rules that stem from the 1970's. The project has been ongoing for almost 17 years. I have tried to change the rules to reflect more modern thinking but the tech lead won't change claiming that consistency trumps everything including common sense, and that "the customer wants it that way" even though the customer developers don't follow their own rules.
One thing that was not mentioned about function-top declarations - it wastes processor time and stack space (for those of us who develop embedded systems with constraints on such things). Why should a class object be unnecessarily declared and created at function top and destroyed upon function termination when it is only used in the very rare case of an error?
Following are justifications for function-top declaration and initialization used by our project, and my responses to them.
Justification: Uninitialized access errors are easy to catch, either by a good compiler, by proper testing, or by a memory access testing tool.
Response: Meaningless. A good compiler, proper testing, or a memory access tool will catch uninitialized access errors regardless of where the variable is declared. Furthermore, declaring and initializing a variable close to where it is first used reduces the likelihood of an uninitialized access error.
Justification: Default initialization often does not incur a large performance penalty.
Response: Maybe for simple bool or int types. But unnecessary creation and initialization of class objects, and the associated destruction of said objects, when multiplied by thousands of functions in the system, can begin to impact performance and memory usage.
Justification: Placing all declarations at the top of the block makes them easy to find.
Response: Placing declarations close to first use makes them easier to find! This may have been true back in the 1970’s when programming was done with punched cards, but today, any editor can find a variable in seconds.
Justification: In some cases, variables must be initialized within a sub-block (e.g. a variable given different values in each branch of an if/else construct), in which case the variable must be declared before initialization.
Response: The phrase “variable must be declared before initialization” implies that the variable must be declared earlier in the code, which may or may not be true, depending on the context. It is obvious that the developer must declare the variable in the next higher scope if the variable has use beyond the if/else construct. But if the variable has meaning only within the confines of the if/else construct, there is nothing wrong with the following construction which also emphasizes the short-lived nature of the variable:
if ( itemCount > 0 )
{
int i = itemCount;
…
}
else
{
int i = MAX_INT;
…
}
Justification: Maintenance often extends the usage of a variable beyond the area in which it was originally expected to be used.
Response: So? If that happens, the declaration is moved out to the next higher block scope. Furthermore, maintenance often deletes all code that references a variable, leaving a function-top variable declared but never used. A compiler may catch that if its warning level is set high enough, otherwise it will be missed and left hanging around in the code. However, if variables are declared close to first use, chances are that when the code that uses it is deleted/moved, the declaration will be deleted/moved as well.
An additional argument to be made for any { } block declarations is that over time, as the program is maintained, a variable initialized at function-top may have its value updated prior to when it was first used in the original code. For example (fictitious), when first written, myVar is function-top initialized at line 10 and first used at line 95 (85 lines away from initialization). Over time, a maintenance cycle used myVar at line 40 but failed to reinitialize it prior to its later use. A review didn’t catch it and neither did testing. The code failed in the field; the customer is angry. A scoped-down declare/initialize would/may have precluded this problem.
Variables should be initialized to a meaningful value. That's why they should not be declared and initialized until there is a meaningful value to use. Often times at function-top, you don't know what a meaningful initialization value is so it is initialized to essentially a meaningless value such as 0. In that case you might as well initialize it to a random value for all the good it does.
modified 30-Apr-21 21:01pm.
|
|
|
|
|
With respect to your first point, this is not good.
I can tell you what the code is doing by reading it. Why is it doing that is the question the documentation should answer.
The hardest part about good documentation is what I've called the "philosophical documentation." In other words, describe what you think the code is doing, and why you took this approach. Try to let a future developer (yourself included) get into your mindset when building this code.
About the variable declaration, it depends. If it is truly just declaring method-scope variables, that's probably not so bad.
If, however, the variables you declare require some potentially costly construction, then it's smarter to delay that until necessary. Your method might exit before hitting that constructor in some code path and save that cost, for example.
I agree there is something to be said for the idea of 'closeness'. I feel like it makes the developer continually think about scope, but it's probably not such a huge deal.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
