10 Commandments
-
Hmm... I've checked a few of recent functions. Observations: It's C++, which has a notable overhead mostly for error handling. However, in most cases I don't see any benefit of breaking them up. One of them, quite simple by this project's standards, is 62 lines, there are 14 opening/closing braces, 6 full-line comments helping understand the code flow, and 11 empty lines to group "logic blocks" (each of the full-line comment is preceded by one). Breaking up the functionality (finding a best match) into three logical pieces was possible (Check A, Check B, Generate Diagnostics), but that would expose a lot of context. With the additional boilerplate, documentation and definition of the functions' contracts, I'd say I'd end up with worse code. Of course, being a C++ programmer, I could write that code in 25 lines, but you really don't want me to :rolleyes:
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server.When I maintain someone's code, I will prefer to see CheckA(); CheckB(); GeneralDiagniostics(); Seeing that I may get an idea of what the method is doing even though I may be new to the team. However, it may become worse if you are passing lot of parameters around. The thing I like about such rules of enforcing maximum lines is programmers are made to think and when they think good solutions may emerge. The eventual aim is to have fewer methods and fewer classes in other words "less code". Less code less bugs.
-
Hmm... I've checked a few of recent functions. Observations: It's C++, which has a notable overhead mostly for error handling. However, in most cases I don't see any benefit of breaking them up. One of them, quite simple by this project's standards, is 62 lines, there are 14 opening/closing braces, 6 full-line comments helping understand the code flow, and 11 empty lines to group "logic blocks" (each of the full-line comment is preceded by one). Breaking up the functionality (finding a best match) into three logical pieces was possible (Check A, Check B, Generate Diagnostics), but that would expose a lot of context. With the additional boilerplate, documentation and definition of the functions' contracts, I'd say I'd end up with worse code. Of course, being a C++ programmer, I could write that code in 25 lines, but you really don't want me to :rolleyes:
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server.peterchen wrote:
but you really don't want me to
May be if you apply factory pattern, your code may get simpler.:)
-
I have been asked to work on our Code Review Procedure. This sort of thing: Pascal casing used for type and method names Camel casing used for local variable names and method arguments ... A single file should only contribute types to a single namespace. Avoid having multiple namespaces in the same file. Avoid files with more than 500 lines (excluding machine-generated code). Avoid methods with more than 25 lines. ... Never hard-code a numeric value, always declare a constant instead. ... I have the feeling it is missing what really make maintenance go bad. Things like re use existing classes, don't duplicate code, separate logic, data access, and display. Can anyone point me to some documents with good recommendations of this type. The idea is to minimize defect and certainly not to alienate the programmers (including me).
I would echo the posters who suggested that the enforcement of coding guidelines should be largely automated with FxCop and StyleCop. That said, you still need a reference for learning the guidelines, and Design guidelines for Class library Developers[^] on MSDN provides a complete set that is likely to be compatible with FxCop and StyleCop, and which is updated with each new release of Visual Studio.
-
Tab characters (\0x09) should not be used in code. All indentation should be done with 4 space characters.
Why?
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
-
Mustafa Ismail Mustafa wrote:
counter-intuitive to break it up to several methods.
That is where I normally take opinion of someone else. Someone, figures out a clever way, usually. The best way to break a method is in chunks of logic. The bad way is to do the following:
void Method()
{
Portion1();
Portion2();
Portion3();
} -
I agree with most of them, but one that really bugs me is:
for (int i=0; i<100; i++) { DoSomething(i); }I prefer:for (int i=0; i<100; i++) DoSomething(i);or:for (int i=0; i<100; i++)
{
DoSomething(i);
}With the last one, who knows what future statements may need to be added... Another one that bugs me is stating that 4 spaces should be used instead of Tab, sorry, Tab tab tab ;P
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon "Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
Why even have a main body inside the for loop? Why not:
int i = 0; while (i < 100 && ReturnTrue(new MethodInvoker(delegate { DoSomething(i++); }))) ;
:rolleyes:
-
Tab characters (\0x09) should not be used in code. All indentation should be done with 4 space characters.
Why?
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
Because tabs are ambiguous. When viewed with tabs set to, say, 5 spaces, the comments might be misaligned. The IDE can handle spaces like tabs (more or less), so probably best to use those.
-
Tab characters (\0x09) should not be used in code. All indentation should be done with 4 space characters.
Why?
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
So the code looks "good", even if your colleague has different tabs setup. I don;t agree with this theory, but I canunderstand it. Iain.
I have now moved to Sweden for love (awwww).
-
Tab characters (\0x09) should not be used in code. All indentation should be done with 4 space characters.
Why?
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
Why are you asking me? I didn't write them! :) Actually, this is one that I tend to agree with. My reasoning is possibly no longer valid with advances in IDEs/Editors (smart tabs etc.) but historically the different editors used to treat tab characters differently. Some defaulted to 3 spaces, some 4 and some to think of a number. Additionally some of them were fixed at that setting whilst others allowed the user to set the value. The result of all this goodness could be that your code looked a dogs breakfast when viewed in different editors. Now if you are particular about how your code is laid out when working on it, and I am, using spaces gives more consistent results across the various editors.
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”
-
When I maintain someone's code, I will prefer to see CheckA(); CheckB(); GeneralDiagniostics(); Seeing that I may get an idea of what the method is doing even though I may be new to the team. However, it may become worse if you are passing lot of parameters around. The thing I like about such rules of enforcing maximum lines is programmers are made to think and when they think good solutions may emerge. The eventual aim is to have fewer methods and fewer classes in other words "less code". Less code less bugs.
Rama Krishna Vavilala wrote:
Less code less bugs.
Now that is very debatable! It's a nice ideal but is simply not true. As peterchen said in one of his posts in this thread <paraphrase>as a c++ programmer he could write using less code, but would you want him to?</paraphrase> <aside>I originally typed that in as "he could write using less cod", now that IS something to aim for. :-D </aside> One of the few (IMHO) major problems with c/c++ is the opportunity for obscure bugs in such compressed code.
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”
-
Rama Krishna Vavilala wrote:
Less code less bugs.
Now that is very debatable! It's a nice ideal but is simply not true. As peterchen said in one of his posts in this thread <paraphrase>as a c++ programmer he could write using less code, but would you want him to?</paraphrase> <aside>I originally typed that in as "he could write using less cod", now that IS something to aim for. :-D </aside> One of the few (IMHO) major problems with c/c++ is the opportunity for obscure bugs in such compressed code.
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”
Henry Minute wrote:
compressed code
compressed code != less code. Also, by less code means less human written code. More code you write more likely bugs. Actually, it is not just something I made up. Studies (cited in Code Complete book which I do not have with me now) indicates that defects per 1000 lines of code increase as the code size grows. It is logical in the sense that it is difficult to handle code as it grows. Some steps to generate less code: 1. Use code generators (including C++ templates, generics) 2. Use standard tested libraries (as opposed to rewriting code) Also less code means the, less you have to look at. So you can quickly figure out is something is wrong. Obviously, if something is obscure it defeats the purpose.
-
Rama Krishna Vavilala wrote:
void Method() { Portion1(); Portion2(); Portion3(); }Amateurs. It should be:
void Method() { Portion1(); Portion2(); Portion3(); }Wjousts wrote:
void Method() { Portion1(); Portion2(); Portion3(); }
A clear violation of the DRY principle! You should really have a loop that calls
InvokeMethodon Portion{i}. -
When I maintain someone's code, I will prefer to see CheckA(); CheckB(); GeneralDiagniostics(); Seeing that I may get an idea of what the method is doing even though I may be new to the team. However, it may become worse if you are passing lot of parameters around. The thing I like about such rules of enforcing maximum lines is programmers are made to think and when they think good solutions may emerge. The eventual aim is to have fewer methods and fewer classes in other words "less code". Less code less bugs.
The problem with that is that these methods share state, and the code would be more like some var x, y, c, d; CheckA(x,y,c,d); CheckB(x,y,c,d); GeneralDiagniostics(y,d); where the data is of no interest to anyone else. I could put the stuff in a class, but what for?
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server. -
I have been asked to work on our Code Review Procedure. This sort of thing: Pascal casing used for type and method names Camel casing used for local variable names and method arguments ... A single file should only contribute types to a single namespace. Avoid having multiple namespaces in the same file. Avoid files with more than 500 lines (excluding machine-generated code). Avoid methods with more than 25 lines. ... Never hard-code a numeric value, always declare a constant instead. ... I have the feeling it is missing what really make maintenance go bad. Things like re use existing classes, don't duplicate code, separate logic, data access, and display. Can anyone point me to some documents with good recommendations of this type. The idea is to minimize defect and certainly not to alienate the programmers (including me).
As others have said, use automated tools for things like code formatting where possible. Making these rules clear is definitely a good idea though. However, what about the actual coding itself? What coding principles will you follow? SOLID? TDD? DDD? What about testing (must they be written? What types - unit, integration, acceptance?) What framework will you target, and what features? Are you happy if everyone uses "var" everywhere in C#, or should it be used only where necessary? Optional parameters? Shortcut initialisation syntax? What level of developer do you target? Are esoteric but clever techniques acceptable, or must all code be written so that a graduate dev new to the language can follow? I think you may need to 2^5 commandments for this one.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
Why even have a main body inside the for loop? Why not:
int i = 0; while (i < 100 && ReturnTrue(new MethodInvoker(delegate { DoSomething(i++); }))) ;
:rolleyes:
because there is no
Parallel.Whileyet? :)Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
Prolific encyclopedia fixture proof-reader browser patron addict?
We all depend on the beast below.
-
Why are you asking me? I didn't write them! :) Actually, this is one that I tend to agree with. My reasoning is possibly no longer valid with advances in IDEs/Editors (smart tabs etc.) but historically the different editors used to treat tab characters differently. Some defaulted to 3 spaces, some 4 and some to think of a number. Additionally some of them were fixed at that setting whilst others allowed the user to set the value. The result of all this goodness could be that your code looked a dogs breakfast when viewed in different editors. Now if you are particular about how your code is laid out when working on it, and I am, using spaces gives more consistent results across the various editors.
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”
IDEs than can't handle tabs with a selectable width should be eradicated. The one big problem with tabs is HTML insists on them representing 8 spaces. See PRE tags in a regular HTML page (I mean, beware CodeProject pages, as they tend to subtly change what you type!) :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
Prolific encyclopedia fixture proof-reader browser patron addict?
We all depend on the beast below.
-
Rama Krishna Vavilala wrote:
Less code less bugs.
Now that is very debatable! It's a nice ideal but is simply not true. As peterchen said in one of his posts in this thread <paraphrase>as a c++ programmer he could write using less code, but would you want him to?</paraphrase> <aside>I originally typed that in as "he could write using less cod", now that IS something to aim for. :-D </aside> One of the few (IMHO) major problems with c/c++ is the opportunity for obscure bugs in such compressed code.
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”
Rama Krishna Vavilala wrote:
Less code less bugs.
I'm with Rama on this. With a nuance: less code, unless at the expense of readability, means less bugs. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
Prolific encyclopedia fixture proof-reader browser patron addict?
We all depend on the beast below.
-
IDEs than can't handle tabs with a selectable width should be eradicated. The one big problem with tabs is HTML insists on them representing 8 spaces. See PRE tags in a regular HTML page (I mean, beware CodeProject pages, as they tend to subtly change what you type!) :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
Prolific encyclopedia fixture proof-reader browser patron addict?
We all depend on the beast below.
Luc Pattyn wrote:
The one big problem with tabs is HTML insists on them representing 8 spaces.
I do so little with HTML that I wasn't aware of that. I'll try to remember against the day I take the plunge into Web development. I'll probably forget though. :( What were we talking about?
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”
-
Pascal Ganaye wrote:
Never hard-code a numeric value, always declare a constant instead.
Yikes! What about
if errors.Count() > 0? Surely I don't need a ZERO_ONLY_ZERO constant? :~I'd say use a named constant anytime you can come up with a good functional name for it. Example: in C you might enumerate the days in a week, maybe they range from 0 to 6, maybe from 1 to 7. I don't want to know, just define FIRST_DAY_OF_WEEK and LAST_DAY_OF_WEEK, then do
for ( day = FIRST_DAY_OF_WEEK; day <= LAST_DAY_OF_WEEK ; day++ )
and it is obvious what the loop will do; with numbers you would have to worry about consistency throughout the app. And yes, there are several situations that don't warrant a symbol, as in your example. Zero is a rather special value. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
Prolific encyclopedia fixture proof-reader browser patron addict?
We all depend on the beast below.
-
I'd say use a named constant anytime you can come up with a good functional name for it. Example: in C you might enumerate the days in a week, maybe they range from 0 to 6, maybe from 1 to 7. I don't want to know, just define FIRST_DAY_OF_WEEK and LAST_DAY_OF_WEEK, then do
for ( day = FIRST_DAY_OF_WEEK; day <= LAST_DAY_OF_WEEK ; day++ )
and it is obvious what the loop will do; with numbers you would have to worry about consistency throughout the app. And yes, there are several situations that don't warrant a symbol, as in your example. Zero is a rather special value. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
Prolific encyclopedia fixture proof-reader browser patron addict?
We all depend on the beast below.
I actually do use contstants for very similar things to your example. Anywhere the number's meaning is not evident to another programmer.