GOPHERSPACE.DE - P H O X Y
gophering on dusted.dk
                              _     _             
                        _ __ | |__ | | ___   __ _ 
                       | '_ \| '_ \| |/ _ \ / _` |
                       | |_) | | | | | (_) | (_| |
                       | .__/|_| |_|_|\___/ \__, |
                       |_|    ...2019-02-25 |___/ 

I used a GOTO
I've written a fair amount of C, but for some reason I've never hit
this construction so plainly, where I thought "a goto is most elegant here".
I'm not talking abbout escaping nested loops.
I'm actually just talking about escaping a single loop.
Sure, I could have used a flag, but that'd be waste of memory, and be
more code, and, I believe, make the program harder to read.
I could have used a function, but, for what? Okay, probably the compiler
would optimize it out, but I'd still get a jump in the (reading) flow.

 Here's a goto construct, using 8 lines of .c:
 
for(...) {
if(...) {
goto gotIt;
}
}
return 1;
gotIt:
life_goes_on();
 

 Here's a flag construct, using 11 lines of .c:
 
int gotIt=0;
for(...) {
if(...) {
gotIt=1;
break;
}
}
if(!gotIt) {
return 1;
}
life_goes_on();
 

 Here's a function construct, using 11 lines of .c:
 
type *getIt(...) {
for(...) {
if(...) {
return it;
}
}
return 0;
}
type* it = getIt(...);
if(!it) {
return 1;
}
life_goes_on();
 

 I'm not going to argue that any of these are difficult to follow, but I'd
be pretty okay with stating that number one is both shortest and simplest.
 
 Sure, as more complexity moves into the loop and if, a time would come where a
flag or function would make it easier to understand, then it's refactor time.

 Why am I ranting about this? I don't know, I'm no fan of goto, nor overly
opposed.. I've written an assembly language parser in basic, there were
a lot of gotos and gosubs, and it was horrid, and I'd never want to do that
if I had functions, and it shows clearly why goto should never be our, oh
wait for the pun.. GOTO flow control statement, rather our last, and while
it is probably healthy to think thrice before using it, don't dismiss all
the cases. Don't avoid things on general principle, unless it's var in js.
 
 I'm probably not too bright to begin with, so it's very possible that I've
messed up, and missed the obviously shorter, simpler, easier and eleganter
(yes, that's a word now, my blog, my English) way of doing the above construct.
But I couldn't find it.. I'll go back and apologize if I find one.

Let's remember why we program
Because we love it, because it's stimulating and fun and we can't not do it!
I'm pretty sure dijkstra wouldn't agree on everything (or anything) I've
written here, but then again, he's smart and I'm a self-proclaimed imbecile,
so that's probably why you should go with his argument and not mine :)