Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.swapon.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!mit.eternal-september.org!.POSTED!not-for-mail From: Richard Newsgroups: comp.lang.fortran,comp.lang.c Subject: Re: Is goto Still Considered Harmful? Date: Wed, 19 Mar 2014 17:05:10 +0100 Organization: http://www.ieee.org/ Lines: 47 Message-ID: <8738ienphl.fsf@gmail.com> References: <1lie1rb.1p06hnd8hxbwaN%nospam@see.signature> <2kohi99ifn8opluhqi8rovcp59n050hu00@4ax.com> <5329A488.9070105@verizon.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mit.eternal-september.org; posting-host="21e90e1db10e3ae7152ebae3a1adfe2b"; logging-data="18733"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19NfKF7W0dM0ReOjfSh+/oqoNxjizzk/5A=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:IwMeBuPdrJJP41zO9I7PDVzCdX8= sha1:9xNBQm1mPposZ0R5IZ4/DZ820v8= Xref: csiph.com comp.lang.fortran:41009 comp.lang.c:42012 James Kuyper writes: > On 03/19/2014 08:08 AM, BartC wrote: >> "James Kuyper" wrote in message >> news:lgbvcl$tca$1@dont-email.me... > ... >>> I would guess that "whenever I get a chance" refers to when maintenance >>> is needed for other reasons; that's the same rule I use when determining >>> whether to make stylistic improvements to working code. And it's pretty >>> plausible that any code that old is indeed difficult to maintain because >>> of its spaghetti shape. >> >> If it really was spaghetti code, then yes. >> >> But if the gotos were used sensibly to construct missing control >> statements, Idiots will tell you that's not possible. As someone with years assembler not only is it done, it must be done or, yes, its hard to maintain. > > Such code can still be hard to maintain - there's a legitimate reason > why those control statements were added to later versions of Fortran. Its just as hard if not harder to keep in your head the multiple ways a function can fall through to a single return statement. It's nonsense to insist on one return statement. if(c) then { prepare_stuff(; return INITIAL_SETUP_COMPLETE; }else if(d){ return ALREADY_DONE } return BLAH; Simple but sometimes we need to keep it simply. A lot of time maintaining live code bases we need to step through code and explicit returns like that make it a LOT simpler to follow. Too much theory over practice with no reference to real development and maintenance tools makes a pretty shitty and useless team member. -- "Avoid hyperbole at all costs, its the most destructive argument on the planet" - Mark McIntyre in comp.lang.c