Date: Mon, 18 Sep 1995 22:33:01 -0600 From: Nate Williams <nate@rocky.sri.MT.net> To: Terry Lambert <terry@lambert.org> Cc: davidg@Root.COM, hackers@freefall.freebsd.org Subject: Coding style ( was Re: why is this not a bug in namei?) Message-ID: <199509190433.WAA24091@rocky.sri.MT.net> In-Reply-To: <199509190326.UAA09176@phaeton.artisoft.com> References: <199509182328.QAA03738@corbin.Root.COM> <199509190326.UAA09176@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes:
[ Terry's coding style ]
> According to a Bell Labs study, human beings are capable of keeping 5 to
> 9 items in short term memory simultaneously. That would be why phone
> numbers are 7 digits.
>
> I'm not even taxing the low end of the study participants.
What this has to do with you using goto's I have no idea.
> On the other hand, if I want block profiling without having to rewrite
> the compiler, then I have to add a block start on function entry and
> one on every function exit. If there is one function exit, then I
> have to add one.
Again, what this has to do with you using goto's I have no idea.
> This "anti-goto-political-correctness-bullshit" has to go. Anyone who
> thinks a for loop generates prettier assembly than an label/if/goto
> had better read more compiler output.
Huh? I am in *complete* agreement with David here. I have looked at
*thousands* if not *millions* of lines of code in my years in
programming. Although there are times when gotos are necessary AND they
improve readability, they are the exception rather than the rule. When
I see two gotos in a single function it is my opinion that the author
has not spent the time to write the code in a readable manner. Now,
there may be a completely valid reason for it, but it will take a lot
for me to believe that. :)
A rule enforced in all software houses I've worked in. "Programmers who
use gotos will be publically ridiculed"
> At least with a goto instead of a break, I have an explicitly defined
> location where my instruction pointer will end up. This beats trying
> to find where a break exits a loop all to hell.
>
> > It goes a long way toward obscuring the code flow and makes it difficult
> > to read.
>
> I supposed changing code that looks like:
>
> if( error = func()) {
> [cleanup]
> return( error);
> }
>
> Into:
>
> error = func();
> if( error) {
> [cleanup]
> return( error);
> }
>
> Has a function other than to make gcc quit whining about assignments
> in if statements (and to make the FreeBSD vs. 4.4BSD diffs larger)?
That's irrelevant since CSRG is no longer, and 4.4Lite2 is the *last*
release of BSD code from them. Who'd have thought Lite2 would even be
released?
> It doesn't seem to make it easier to read.
Nor does it make it any harder to read. However, I prefer the latter
vs. the former simply because any compiler worth it's weight in salt
will cause the exact same code to be emitted for both. I also find I am
more likely to check the error status more thoroughly in the second case
since it's not so complicated, AND I have the error state saved so I can
do multiple checks w/out getting overly complicated.
> A goto is a tool for handling an exceptional conditions. And that's
> where goto's are use in my code.
>
> The alternative is negative comparison code blocks, ie:
>
> if( !(error = foo()) {
> [real code]
> } else {
> [error code]
> }
I prefer this to using gotos simply because my mind is tuned for
parentheses, not goto statements. It's a matter of what you are used to
seeing.
Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509190433.WAA24091>