[ProgSoc] Jumpy code

Peter Brownlow roentgenation at gmail.com
Mon Oct 12 12:24:24 EST 2009


>
>
> Does anyone have an opinion they'd like to share? Should
> return/break/continue be avoided in general?
>
>
This is all from my personal experience. YMMV.

Personally, I find it much more difficult, tedious and error-prone to
understand and refactor others' code if it includes return/break/continue
statements (i.e. is what you've called "jumpy"), and the more of these
flow-breaking statements there are the harder I find it.

My reason is that I see the code as describing flows of control, so a "jump"
is an exceptional case I have to store in my head while moving on to figure
out the other cases. The fewer special cases I have to remember the better.
My job should be as easy as possible so that I can produce more work of
higher quality.
For special cases that could be expressed with or without using these
"jumpy" statements I still find it faster and less error-prone to understand
the non-jumpy one (e.g. inside a loop: "if (loop element is good) { do stuff
}" flows better for me, as opposed to "if (loop element is bad) { continue }
do stuff"). I think that this is because when I see the jumpy statement I am
either caching a new exceptional case or reinterpreting it into a more
flowing rule (i.e. the loop and its if become, in my head, "for each good
element: do stuff"). Either way, that's more work and more chances for me to
get interrupted halfway through, forget something or make a mistake.

Second, control syntax tends to be easier than return/break/continue
statements to visually spot with minimal effort, which enables me to
snapshot the flow of control in my head before I have read the nitty-gritty,
and context is always an aid to understanding details.

Third, when refactoring someone others' jumpy code I have been bitten many
times by missing a very small "if (bad) return" statement (or similar) in a
much larger block of code. I add something like "if (bad) { make it good }"
and the "make it good" is not always called, and then I have to go hunting
for the jumpy statement that I didn't see. The original author has not put
much effort into making it easier for me to come along and edit the code: 20
characters can hide fairly easily amongst many hundreds. The bigger the code
block haystack the bigger the problem finding the jumpy needle, so obviously
reducing the size of code blocks reduces this problem, but in my personal
opinion both large code blocks and jumpy code make my life harder, and 2
wrongs don't make a right.

-Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://progsoc.org/pipermail/progsoc/attachments/20091012/8cf52112/attachment.htm 


More information about the Progsoc mailing list