IWETHEY v. 0.3.0 | TODO
1,095 registered users | 1 active user | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New No way!
I want to limit the depth of my blocks.
I often will have a series of tests at the
top of a loop that will cause them to "continue".
Your way forces tracking of many begin/end pairs
for no reason.

No continue needed?

I've been pumping my own water fer years. Who needs that them there newfangled indoor plumbing?
New Yet Another Way To Do It
Scoop out the body of the block into a function. That does not nest deeply.

Then structure as jb4 suggested.

Disadvantages: function call overhead and one layer of indirection. Advantages: separating "what" from "why" often leads to better modularization.

Cheers,
Ben
To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act
- [link|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20|Nebraska Supreme Court]
New Warning! Possible religious war pending
which I do not want to get into here.

In the concrete example you gave, there is no additional scoping, so your objection is moot.

In response to you're other complaint (the many checks at the top of the loop), you could put the checks into the loop condition itself (with appropriate and'ing); that would not only remove additional begin/end pairs, but would improve your scoping as well.

As far as the "for no reason" is concerned, I've had many instances where indiscriminate breaks/continues have so shattered the flow of the block that you no longer can determine the conditions that got you to a point towards the bottom of the loop, for all the trap-door exits to the block. For me, I consider readibility of the code to be a most sufficient reason. Don't you?
jb4
shrub\ufffdbish (Am., from shrub + rubbish, after the derisive name for America's 43 president; 2003) n. 1. a form of nonsensical political doubletalk wherein the speaker attempts to defend the indefensible by lying, obfuscation, or otherwise misstating the facts; GIBBERISH. 2. any of a collection of utterances from America's putative 43rd president. cf. BULLSHIT

New Nah, this is more important
> In the concrete example you gave,
> there is no additional scoping, so your objection is moot

Coding style should apply to the general case. It is something
that will be applied again and again. Your objection to my objection
is moot.

> you could put the checks into the loop condition itself

A check often includes a series of intermediary steps. I don't
put that kind of logic in a loop condition if I can avoid it.

> indiscriminate breaks/continues

"Indiscriminate" applies to all programming constructs. I don't
like "ELSIF" due to people's "indiscriminate" use. Kill it.
Sounds silly, ehh?

Well placed break/continues allow well structured easy to read
code for me. Targetted "next" allows deep loop jumping in a clear
manner, without the pain of intermediate flag variables cluttering
it up.

So yes, I agree reability is most important.
Adding to the depth of nested IF statements
would push me to add functions, which then slow
down both my perception of the code and the code
itself.

I really love Perl's

next if ($something);

and

next unless ($somthing);

syntax. Good thing Ruby has it.
New Some older languages had those constructs
I remember something like
\n   exit with { }\n

in one of those late-70's languages-du-jour that were coming up about one every week. Never got a chance to use it.

A next if () or next unless (), used judiciously might well aid in readability. However, you haven't addressed the (in)ability to track the conditions that got you to a certain place in the code if there are a large number of trap-doors in the block above it (including those next if () or next unless () constructs).
jb4
shrub\ufffdbish (Am., from shrub + rubbish, after the derisive name for America's 43 president; 2003) n. 1. a form of nonsensical political doubletalk wherein the speaker attempts to defend the indefensible by lying, obfuscation, or otherwise misstating the facts; GIBBERISH. 2. any of a collection of utterances from America's putative 43rd president. cf. BULLSHIT

New That doesn't need to be addressed
Other than to note that if you have complex conditions for deciding when to do X, the resulting code has a minimum associated complexity. There is nothing wrong with what you call "trap-doors" and what I'd call "guard clauses". There is a lot wrong with having a lot of them - however you try to implement them.

There is a simple principle for analyzing the complexity of code that structured programming has taught for 3 decades now. Take a block. Add 1 for every decision, be that a loop, if, unless, case in a case statement... If you come to the end of the block and have a count over 10, that block of code is complex and is likely to become a source of trouble. Consider breaking it up, refactoring, redoing the logic, etc. (This is a rule of thumb. Sometimes no good rewrite is available. Flag the potential trouble-spot, check it carefully and move on.) Definitely don't stuff anything extra into that block - you don't want necessary complexity to become lost in a sea of extraneous material.

If I was at home I'd give you the name of the person who first came up with that complexity measure, the paper it appeared in, and a reference to the place in Code Complete that I read it. I'd even give you where it appears in both the first and second editions. Unfortunately I have no copies of Code Complete at hand, so I'm limited to just giving you the coding rule and the knowledge that I got it from Code Complete.

Cheers,
Ben
To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act
- [link|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20|Nebraska Supreme Court]
New If I didn't know better ...
... I'd say it looks like Ben is getting tired of having to pull out the references after three iterations of talking past each other.


FWIW if something sounds right to me, I don't need the reference. If it sounds wrong, the reference isn't likely to help. (Much.) Counter-intuitive study results notwithstanding.
===

Implicitly condoning stupidity since 2001.
New Good thing that you know better then :-)
Incidentally the measure that I described is due to Tom McCabe. The usual list of key words are, if, while, repeat for, and, and or (or equivalent). The rule of thumb is that 0-5 decision points means that your routine is probably fine. 6-10 indicate that you perhaps should simplify. 10+ is a danger sign.

In both editions of Code Complete you'll find this advice in the Control Structures and Complexity subchapter. In the first edition this is at pp 394-396. In the second edition, pp 456-459. Both versions cite 2 studies (McCabe 1976, Shen et al. 1985) that indicated that complexity and low reliability of code are strongly correlated.

He also reports on a 1989 paper from Hewlett Packard. They used this principle for organizing code on two programs, one at 77,000 lines and the other 125,000 lines. The post-release defect rates rates per thousand lines were 0.31 and 0.02 respectively, both substantially below the norm at HP. (I calculate that this means 24 bugs and 2 bugs.)

In the second edition he claims that his consulting company in the last few years has achieved similar results from this technique.

So not only does this allow you to measure where the bugs are likely to appear, it also allows you to reduce your overall defect rate.

I'd like to update this advice with the point that I think that at least some method calls should be included as "decision points". Depending on the coding style, not all - just the ones that you're likely to actually use polymorphism on. (Simple accessors don't count.) This is just my thinking on the topic though, see [link|http://www.perlmonks.org/?node_id=298755|http://www.perlmonks.org/?node_id=298755] for more detailed discussion.

Cheers,
Ben
To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act
- [link|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20|Nebraska Supreme Court]
New You forgot:
caseof/case, each of which adds a complexity count. So if I have a case construct for handling the digit keys on a keypad, for example:

\nswitch (keystroke)\n{\n    case 0:\n    case 1:\n    case 2:\n    case 3:\n    case 4:\n    case 5:\n    case 6:\n    case 7:\n    case 8:\n    case 9:\n        do_something_trivial(keystroke);\n        break;\n\n    default:\n        do_something else(keystroke);\n}\n


In this section alone, you have a complexity of 11, which by the "rule of thumb" is too complex and must be simplified. Oh well, the best laid plans....
jb4
shrub\ufffdbish (Am., from shrub + rubbish, after the derisive name for America's 43 president; 2003) n. 1. a form of nonsensical political doubletalk wherein the speaker attempts to defend the indefensible by lying, obfuscation, or otherwise misstating the facts; GIBBERISH. 2. any of a collection of utterances from America's putative 43rd president. cf. BULLSHIT

New Rules of thumb are rules of thumb
And will always break down somewhere.

But in this case I think that that code sample is clearer when written as:
\nif (keystroke < 10)\n    do_something_trivial(keystroke);\nelse\n    do_something else(keystroke);\n

Conversely if your list was a list of, say, random item IDs that got special treatment, then that case statement, written that way, would indeed be a complex thing. I'd strongly prefer to have you give me some context about what the commonality between the items is. If need be by hiding the list in a function with a descriptive name like gets_ira_tax_break_1234(item).

Cheers,
Ben
To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act
- [link|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20|Nebraska Supreme Court]
New That'd be the Cyclomatic Complexity
Of which there are two major variations. Unfortunately, the swiss chese that often populates my cranium cannot off the top of my head describe the differences...it's off to Google....
jb4
shrub\ufffdbish (Am., from shrub + rubbish, after the derisive name for America's 43 president; 2003) n. 1. a form of nonsensical political doubletalk wherein the speaker attempts to defend the indefensible by lying, obfuscation, or otherwise misstating the facts; GIBBERISH. 2. any of a collection of utterances from America's putative 43rd president. cf. BULLSHIT

     VB - NO CONTINUE STATEMENT!! ARRGG!!! - (broomberg) - (38)
         Basic was invented that way - (ChrisR) - (16)
             Has had "continue" for many years - (broomberg) - (15)
                 In VB 6 you have - (lincoln) - (1)
                     Exit loop is there - (broomberg)
                 Or you COULD... - (jb4) - (12)
                     In other words, give a "break"! :) -NT - (a6l6e6x)
                     No way! - (broomberg) - (10)
                         Yet Another Way To Do It - (ben_tilly)
                         Warning! Possible religious war pending - (jb4) - (8)
                             Nah, this is more important - (broomberg) - (7)
                                 Some older languages had those constructs - (jb4) - (6)
                                     That doesn't need to be addressed - (ben_tilly) - (5)
                                         If I didn't know better ... - (drewk) - (3)
                                             Good thing that you know better then :-) - (ben_tilly) - (2)
                                                 You forgot: - (jb4) - (1)
                                                     Rules of thumb are rules of thumb - (ben_tilly)
                                         That'd be the Cyclomatic Complexity - (jb4)
         Answer: - (FuManChu) - (17)
             VB is not a Programming Language, it's a Product. -NT - (ChrisR) - (16)
                 So if I WAS to fight, again, what are my alternatives? - (broomberg) - (15)
                     Rython ror Rerl ror Reecee-ell ror a rombo of rall rhree ; - (folkert) - (7)
                         TCL - Never!!!! - (broomberg) - (6)
                             Careful what you ask for... - (folkert) - (2)
                                 I see you ignored the previous. Barry - (folkert) - (1)
                                     Who says? - (broomberg)
                             Come on, TCL and BASIC are as far apart - (Arkadiy) - (2)
                                 Lisp is not procedural?? - (ben_tilly) - (1)
                                     Parenthetically speaking that is. :) -NT - (a6l6e6x)
                     C# is a better match - (ChrisR)
                     ObCRC: Delphi - (Another Scott) - (2)
                         I just pitched C# - (broomberg) - (1)
                             You just described all of MS' programming languages. - (static)
                     Python wins on several of those axes - (FuManChu)
                     Sounds exactly like... - (jb4) - (1)
                         Oh, what's the use?! "Nobody is as blind...", and so on. :-( -NT - (CRConrad)
         Side effect - (JayMehaffey)
         FWIW, VB.Net 2005 will have it -NT - (altmann) - (1)
             ObLRPD: It'll be in the next release.... -NT - (jb4)

Owner/Operator rig.
167 ms