|
Coding standards with my employer are strange based on everything I've ever known, everything I've ever read, everything I've ever been told. They are set in their ways and I don't think anything could change their mind on these internal standards. Here are a few:
1. Excessive commenting -- practically every operation in code has a preceding comment. No matter how descriptive the code is, and no matter how simple the operation may be, there is a comment such as the following:
private int Add(int a, int b)
{
return a + b;
}
private void Process(MyFileObj myFile)
{
if (myFile != null)
{
myFile.StripBadData();
_myFileCollection.Add(myFile);
}
}
2. Variable declaration -- this may not be so bad, so please correct me if I'm wrong. But I've never seen it done this way. According to their standards, all variables in a method must be initially declared at the top of the method, before anything else is done:
private MyClass MyMethod()
{
int count = 0;
MyClass someObj = null;
foreach (MyFileObj file in _myFileCollection)
{
if(file.Name.Length <= 20)
{
file.CopyTo(@"C:\SomePath\" + file.Name);
count++;
}
}
someObj = new MyClass();
someObj.FileCount = count;
return someObj;
}
The "MyClass someObj" isn't referenced until the very end of the method. Why should it be declared at the very top of the method? Maybe I'm missing something? I've never declared objects until the time I need them.
These are just a few examples. There are some other things I don't really agree with, but I can't change any of them.
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Coding Standards are the first step in an organization to removing code quality. My personal experience suggests that code reviews become about fiefdoms and pet "issues" of enforcing the standards instead of about the code, errors in the logic, mismatched to requirements, etc.
Also, when you don't have standards it is a lot easier to read other peoples code. (You can intuitively know who wrote it; most people make the sames types of errors over and over as well) And, oddly enough, without standards but with code-review and team work the code base naturally coverages. I personally keep standards to something regarding actual quality.
That said, I usually declare all variables at the top of a method. And always only have one return in a method, preferring if-statements over multiple returns. Bottom-line is as you experience things you will learn what works best for you.
|
|
|
|
|
I'm quickly beginning to understand your thinking on the subject. I kind of felt that way about it already. And the more I think about it, the more it annoys me. However, I will say that our manager and the lead developer both offer assistance to clear up code, to write more efficient code, etc. So I suppose it could be much worse.
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Wow, so much to hate here.
First, code standards make it easier to read the code (if they make sense). You don't need a lack of standard to tell who wrote it. Besides your source control can tell you who wrote the code.
Second, keeping variable declarations at the top and avoiding multiple exits of a method make code harder to read. And the whole if thing? Code quality is (generally) inverse to the number of if statements a coder uses.
But I would find a new place to work as quickly as possible. The code standards show that this organization has not embraced the C# way of doing things.
|
|
|
|
|
Declaring all variables at the begining of the method is an old c++(i am not sure if it comes from c) standard closely connected with the variable block of sight. In c# i dont believe there is such thing.
Today i was sooo close of declaring such variable
bool bResultBecauseMyBossDoesntLikeMoreThanOneReturnInTheMethods = false;
next time ask your boss if you need to put a comment to the line
i++;
Sometimes i wonder... why does they want us to comment everything like the next "programmer", who will manage this will be a monkey.
Microsoft ... the only place where VARIANT_TRUE != true
|
|
|
|
|
That makes sense. I'm pretty sure my manager is the guy who set the coding standards. And if I'm not mistaken, he has a background in C++ as well. He has quite an extensive list of areas in which he's knowledgeable, so that is probably where it comes from.
And that's my point. You're supposed to write code with readability and maintainability in mind, right? Well, if that's the case, you shouldn't have to comment every single operation. The more complex operations, yes, I completely understand. Sometimes, even if you think a complex piece of code is readable, it may be better for the next person if you comment and summarize what's going on. But to comment on a "return" statement? Or an increment statement? That seems a bit ridiculous.
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Argonia wrote: (i am not sure if it comes from c)
It does. But I prefer leaving it away in C# and C++ code, since I don't feel like it'd give me any benefits in these languages.
Clean-up crew needed, grammar spill... - Nagy Vilmos
|
|
|
|
|
I use the declaration of the variables at the beginning of the method in my c++ coding, the code is read more easily and its more tidy, especially when you use complex stl structures and interators to them. One more reason is reuse of the variables which served their main purpose - for example a string used for XPath, or string used for middle string result or something like that.
In my c# code i dont use that rule... i get yelled for doing it and putting prefixes on the variables showing their type 
Microsoft ... the only place where VARIANT_TRUE != true
|
|
|
|
|
Argonia wrote: Declaring all variables at the begining of the method is an old c++(i am not sure if it comes from c)
It is from C.
|
|
|
|
|
jschell wrote: It is from C.
It's in Pascal, which AFAIK predates C. Which isn't to say that both didn't pick it up from some other language.
|
|
|
|
|
John Nurick wrote: It's in Pascal, which AFAIK predates C. Which isn't to say that both didn't pick it up from some other language.
I seriously doubt that.
First at least Wiki reports that development and C and Pascal both initially started in 1969. And certainly seems possible that Pascal wasn't terribly successful early on. Whereas C was actually being used in 1972.
And C was proceeded by B and that came from BCPL.
Of course C++ was derived from C. And in terms of where variable declarations occurred, C++ and Java would have had more influence on C# than C. Pascal wasn't in the picture.
One might suppose that a Pascal programmer went directly to C# but it is more likely that either Java or C++ was the precursor.
|
|
|
|
|
It's from COBOL.
You had a DATA DIVISION (variables) and a PROCEDURE DIVISION (executable code) ...and a few other divisions.
The PROCEDURE DIVISION followed the DATA DIVISION and one could not mix elements of one with the other.
|
|
|
|
|
Gerry Schmitz wrote: It's from COBOL.
You are missing the point....
The question is why C# coding standards might have been insisting that declarations be at the beginning of a method.
And it is much more likely that that is holdover from C, perhaps going through C++, than it is that it came from COBOL.
One then might wonder why C had it. And it is possible that it came from COBOL. But it also possible that it was just easier to write BCPL, and then B and C that way.
|
|
|
|
|
Do this next time:
private int Add(int a, int b)
{
return a + b;
}
|
|
|
|
|
Matt U. wrote: 2. Variable declaration
I do declare all my variables in one block at the beginning, maybe it comes from COBOL - I'm still thinking in sections...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
Matt U. wrote: foreach (MyFileObj file in _myFileCollection)
Whoops - you didn't declare the MyFile file variable at the top of the method! 
Matt U. wrote: someObj = new MyClass();
someObj.FileCount = count;
Now how is anyone supposed to understand that code with the single comment you've provided? Surely it should be:
someObj = new MyClass();
someObj.FileCount = count;
There, isn't that better? 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Well, I don't think their standards apply outside of the work environment. 
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Richard Deeming wrote: Whoops - you didn't declare the MyFile file variable at the top of the method!
Tsk. Tsk. In that case it's obvious then that foreach isn't allowed.
IEnumerator<MyFileObj> enumerator;
MyFileObj file;
using (enumerator = _myFileCollection.GetEnumerator())
{
while (enumerator.MoveNext())
{
file = enumerator.Current;
}
}
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chinese Proverb]
Jonathan C Dickinson (C# Software Engineer)
|
|
|
|
|
Well, I'm going to have to dock you points for not commenting every line of that code. Without the comments, how is anyone supposed to understand it?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
someObj = new MyClass();
someObj.FileCount = count;
You missed an opportunity for a comment there. I'm sorry but I'd have to ding you on a code review for that.
I have very few coding standards in place - my biggest ones are "be consistent" and "don't let your methods get too big". I don't get bothered about brace style (life is far too short to worry about how someone formats brackets). As long as the team can come to a consensus about how they write their code then I'm only really concerned with the logic. I've seen far too many faddy standards come and go to want to jump onto a particular standard now.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
