|
"Pendantic "one return per function" people should be taken out back and beaten with a sack of gotos."
This rule of thumb is really about making a method functionally coherent. ie it does one thing. A lot of functions like WriteOutData() seem functionally coherent but they aren't, they are doing things like parse my input data, reshuffle it, open a file, write out my data. Its not doing one thing.
And thats what methods returning one thing are about. If your method is taking in "out" arguments (to use c# vernacular) and modifying them inside then its really returning more than one value and this probably means your method is doing more than one thing.
There are examples where multiple return values do work, but for me they are usually really simple methods like
bool Double.TryParse(object inputValue, out double result)
it really has 2 return values, 1 the bool if it is a double and 2 the result.
but generally i don't find this is the case.
|
|
|
|
|
Sadly, in the time of design patterns, rich frameworks, reflection and increasingly dynamic typing, clear and well structured functions are becoming a rarity.
|
|
|
|
|
Eh. When have they ever not been?
The only difference now is that we have even more excuses for our poor writing.
|
|
|
|
|
I think part of the problem is that with the emphasis on object-oriented design in recent years, people have forgotten the lessons that have been learned about function-oriented design.
I see "object-oriented" code that has 500-line methods. As a method's length increases, its complexity increases faster than linear, as the number of possible interactions between the method's statements increasing quadratically. Ideally a method should fit on half a screen. If it’s too long, break it up into cohesive subroutines. A method’s structure should be so simple it’s self-documenting.
|
|
|
|
|
Alan Balkany wrote: As a method's length increases, its complexity increases faster than linear, as the number of possible interactions between the method's statements increasing quadratically.
And of course, this is somewhat applicable to the design of objects themselves: too much state and too many methods results in object definitions that are near-impossible to actually read and understand.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
