on goto
in [General Programming]
|
From: James Dow Allen on 23 May 2010 00:17 On May 22, 7:33 am, "Daniel T." <danie...(a)earthlink.net> wrote: > James Dow Allen <jdallen2...(a)yahoo.com> wrote: > > I hope my point isn't too ... er ... complicated :-) > > I think the point though is that his tool (i.e., cyclometric complexity) > is meant to measure the number of unique paths through the code in > question. If neither 'A' nor 'B' have side effects, then A && B isn't > any more complex than B I'm not bashful about using the '&&' operator but still write if (A) if (B) foo(); sometimes instead of if (A && B) foo(); because breaking up a complicated predicate may make it *more readable*. Yet the tool's statistic implies it to be *less* readable. Perhaps the coding best by the tool's standard would be for (ff = x = y = z = 0; !ff && x < xlim; ++z < zlim ? 0 : (z = 0, ++y < ylim ? 0 : (y = 0, ++x))) { if (haystack[x][y][z] == needle) point_assign(p, x, y, z), ff++; } return ff; Now perhaps no one in the thread actually argued that the tool had value, but the inference was there. The tool *might* even have real purpose in the automated analysis of *large* code samples, but the programmer's eye is better for small codes; I'd be surprised if the obviously simpler code under discussion isn't considered simpler by most programmers. > (based on the definition of complexity presented.) Oh!! I could have defined "complexity" as a count of letters with serifs. How many legs does a pig have if you call a tail a leg? Hope this helps, James
From: io_x on 23 May 2010 05:27 "James Dow Allen" <jdallen2000(a)yahoo.com> ha scritto nel messaggio news:43b08fd9-568b-4c31-98b7-4834cbe5dae8(a)s13g2000prc.googlegroups.com... >I'm not bashful about using the '&&' operator but still write > if (A) > if (B) > foo(); >sometimes instead of > if (A && B) foo(); >because breaking up a complicated predicate may make >it *more readable*. Yet the tool's statistic implies >it to be *less* readable. Perhaps the coding best by >the tool's standard would be > for (ff = x = y = z = 0; !ff && x < xlim; > ++z < zlim ? 0 : (z = 0, > ++y < ylim ? 0 : (y = 0, ++x))) { > if (haystack[x][y][z] == needle) > point_assign(p, x, y, z), ff++; > } > return ff; i find more readable these below ifs for(ff=x=y=z=0; x<xlim; ) {if(haystack[x][y][z]== needle) {point_assign(p,x,y,z); return 1;} ++z; if(z>=zlim) {z=0; ++y; if(y>=ylim) {y=0; ++x;} } } return 0; but it is one line more >Now perhaps no one in the thread actually argued that the >tool had value, but the inference was there. >The tool *might* even have real purpose in the automated >analysis of *large* code samples, but the programmer's >eye is better for small codes; I'd be surprised if >the obviously simpler code under discussion isn't >considered simpler by most programmers. .... >Oh!! I could have defined "complexity" as a >count of letters with serifs. How many legs does >a pig have if you call a tail a leg? >Hope this helps, >James
From: Daniel T. on 23 May 2010 12:08 James Dow Allen <jdallen2000(a)yahoo.com> wrote: > On May 22, 7:33�am, "Daniel T." <danie...(a)earthlink.net> wrote: > > James Dow Allen <jdallen2...(a)yahoo.com> wrote: > > > I hope my point isn't too ... er ... complicated :-) > > > > I think the point though is that his tool (i.e., cyclometric complexity) > > is meant to measure the number of unique paths through the code in > > question. If neither 'A' nor 'B' have side effects, then A && B isn't > > any more complex than B > > I'm not bashful about using the '&&' operator but still write > if (A) > if (B) > foo(); > sometimes instead of > if (A && B) foo(); > because breaking up a complicated predicate may make > it *more readable*. Yet the tool's statistic implies > it to be *less* readable. Perhaps the coding best by > the tool's standard would be > for (ff = x = y = z = 0; !ff && x < xlim; > ++z < zlim ? 0 : (z = 0, > ++y < ylim ? 0 : (y = 0, ++x))) { > if (haystack[x][y][z] == needle) > point_assign(p, x, y, z), ff++; > } > return ff; The complexity measure in question ("cyclomatic complexity" if you want to google it) is a count of the number of linearly independent paths through the source code. The only question with the above code is whether (!ff && x < xlim) represents one path or two. Once could say it denotes three paths because of the short circuit evaluation, however since there are no side effects of the entire evaluation one could argue that there are only two paths (which is my position on the matter.) So: if (A) { if (B) { // code here } // *no* code here } // code here In the case where (!A || A && !B) is true, one path is taken, while if (A && B) is true, another path is taken. Two paths means a cyclomatic complexity of 2, but some would argue that the code has three paths, even though two of the paths have identical effects. > Now perhaps no one in the thread actually argued that the > tool had value, but the inference was there. Empirical tests have shown that functions with higher complexity (based on this measure) are more likely to be buggy. Also the measure gives an indication of the minimum number of tests required to ensure full path coverage of the function in question. > > (based on the definition of complexity presented.) > > Oh!! I could have defined "complexity" as a > count of letters with serifs. How many legs does > a pig have if you call a tail a leg? There is complexity then there is readability. They don't have to match definitions. It seems reasonable that two pieces of code can have the same complexity quotient while having different readability quotients... or do you disagree with that assessment?
From: blmblm on 29 May 2010 15:30 In article <aa20c65b-4ea3-4132-a827-f3c0d653067a(a)24g2000yqy.googlegroups.com>, gwowen <gwowen(a)gmail.com> wrote: > On May 8, 1:39 am, Lie Ryan <lie.1...(a)gmail.com> wrote: > > > I've never heard of any programming languages that doesn't support > > recursion. > > Standard Fortran, prior to 1990. It was not a bad idea, given the > limited stack space on most machines, and the likelihood of stack > overflow. Especially given you can always do tail recursion by hand > (ObOnTopic: ... using goto.) That's funny; I was sure I'd used FORTRAN 77 compilers that supported recursion, though you did have to include something explicit to allow a subroutine to be used recursively. However, a quick Google search suggests that maybe this was a common but nonstandard extension. Hm! Anyway, as you say elsethread, it's been added, with so many other things. Fortran 90 and beyond are almost a different language! -- B. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor.
From: blmblm on 29 May 2010 15:36
In article <4be62644$0$14116$703f8584(a)textnews.kpn.nl>, Sjouke Burry <burrynulnulfour(a)ppllaanneett.nnll> wrote: > Nick Keighley wrote: > > On 8 May, 17:46, Tim Streater <timstrea...(a)waitrose.com> wrote: > >> In article > >> <5dd9bdc8-4dc4-4537-84a0-885c4c92f...(a)l28g2000yqd.googlegroups.com>, > >> Nick Keighley <nick_keighley_nos...(a)hotmail.com> wrote: > >>> On 8 May, 01:41, Lie Ryan <lie.1...(a)gmail.com> wrote: > > > > > >>>>> I've never heard of any programming languages that doesn't support > >>>>> recursion. > > [...] > >>> FORTRAN (in its original form), Coral-66 you had to use a special > >>> keyword to indicate a function was recursive. Some BASICs probably > >>> didn't alow recursion. But these all qualify as "ancient" (and maybe > >>> jocular!) > >> What FORTRAN are you referring to. I never saw it in any FORTRAN up to > >> 1978 (the last time I used FORTRAN). > > > > lost me. So far as I remember FORTRAN didn't have recursion. Am I > > wrong? Or are you saying even modern Fortran doesn't have recursion? > > If recursion does not exist, I will have to ditch quite a couple > of fortran programs. > There is only 1 hitch, you have to write a 3 line dummy routine, > to do the calling, so a calls b , b calls a. > fortran MS 5.1 and later. > Also Fortran77 for Riscos (arc 320 computer) And then there are systems on which this approach would almost surely fail spectacularly (as you may know -- just sayin'). In a long-ago job in which one of my responsibilities was finding and fixing bugs other people's FORTRAN, a particularly nasty one turned out to be the result of this kind of mutual recursion. If the system puts the return address for a call to a non-recursive subroutine in a fixed location, well .... I'm curious now about why A-calls-B-calls-A would work but simple A-calls-A would not. Is it a compiler issue? where the compiler won't allow the latter, but will allow the former? -- B. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor. |