|
I agree avoid too much state and too long methods. For me they have to fit on a screen or they are too big.
Methods longer than 100 lines are just C code put into an object.
|
|
|
|
|
Of the options, only two shouldn't be taken for granted - that you're not looking at poor coding practices to begin with.
Clear naming conventions (that means camel style) can be considered a step in the direction of self-documenting code. Even with that, I feel the liberal sprinkling of comments is essential: Coda nd Icecream is better with lots of spinkles.
My mind, at this point, is growing feeble. A year or two after I write some code, I would like to know what it does - or more specifically - why I did something in a particular way when a more obvious mechanism exists. To help me keep track, I have 3-level documentation with the project (aside from any rightups I have to give to my employer).
1) At the code level - very very many end-of-line comments. Some comments for blocks.<br />
2) A header for each method describing what the purpose is and a running history of fixes and changes. Sometimes the change gets a date-tag in the code, too.<br />
3) A seperate file (I usually use projectName.ver) describing the development, changes, updates, fixes, gutting-events, etc. This is useful to map new problems to changes (the Pillsbury Dough-Boy effect).
With the above 3 levels of documentation, I need not fret of current or future "senior moments."
For class libraries, when there's a quite period, I write an instruction manual in the hopes that other developers will use them.
Of all the choices, pretty much everything you need to document is in the first two - and the remainder are valid primarily in the context that the more poorly code is written, the more difficult it will be to understand/debug/enhance.
Document code for others as you would have others document code for you!
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to go away?" - Balboos HaGadol
|
|
|
|
|
Balboos wrote: Clear naming conventions (that means camel style)
I disagree that "clear naming conventions" implies camel style. Clear naming conventions means that program items are named using a pattern that conveys the scope, type, or other useful information about the item. Camel style is one such pattern, but it's by no means the only one.
Software Zen: delete this;
|
|
|
|
|
That was just a tease.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to go away?" - Balboos HaGadol
|
|
|
|
|
All Of Above.
It should have been a multiple choice question.
|
|
|
|
|
True. The first two points actually go hand-in-hand. Besides, I also don't find it good to h ave a 'Free Text Answer' for a radio button driven query. Wouldn't that be conflicting?
Vasudevan Deepak Kumar
Personal Homepage Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
Agree!
God bless,
Ernest Laurentin
|
|
|
|
|
All of the above are important for clear code. The interesting thing in a poll is seeing what people feel is the most important. Then you have to think about it a little deeper.
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|