"adrianc1982" wrote:
functions should have descriptive names long ones if posible and you should write 3 lines per function or less when posible.
Goodness gracious,
NO!Whoever came with such idiotic idea must been someone from the Marketing Department of the Sirius Cybernetics Corporation ("A bunch of mindless jerks who'll be the first against the wall when the revolution comes"). Prophetizing this should be outlawed.
A function should be as long, as it makes sense; as much as you - or a developer after you - can hold in their head and work with. It also depends on what is being done - there are cases in which hundreds of lines are okay, i won't preclude thousands if it was something linear and thinking free. Just like you cannot say "all roArrays should be <= 10 elements - or you are doing it wrong".
It's like arguing what's the perfect size of a coffee grind or meal pieces - it depends. But "2-3 lines" is like putting it in a blender and liquifying all to a smoothie! It's on the "too small" side, just like thousand lines is on the "too large" side, the golden mean is in the middle.
The problem with chopping to too small pieces is that you have not got rid of complexity. Complexity hitting the fan did not make it disappear per se - it gets it
smeared all around. Even if you can hold in your head all the million pieces you shattered it into, the coder after you can't - or they'll need a week charting your function calls.See discussions e.g.
http://softwareengineering.stackexchang ... od-for-youPS. and yes, comments should not restate what was said - or could be said - in code, for reasons of brevity and not running out-of-sync. But they could document why something is happening he way it is, external factors beyond the code. Say you have been told
not to do that, because it doesn't work. Your code becomes more ornate and you have to note why it can't done simpler.