Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Mar 2002 15:37:01 -0700
From:      Nate Williams <nate@yogotech.com>
To:        Mark Murray <mark@grondar.za>
Cc:        nate@yogotech.com (Nate Williams), cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/usr.bin/rwall rwall.c 
Message-ID:  <15495.60301.617215.87829@caddis.yogotech.com>
In-Reply-To: <200203072227.g27MRWRV017994@grimreaper.grondar.org>
References:  <15495.59008.192220.654176@caddis.yogotech.com> <200203072227.g27MRWRV017994@grimreaper.grondar.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> > > void main(){printf("hello world\n");}
> > 
> > > also produces correct code and runs, but creates problems during
> > > compiler and library upgrades. It his hard to read, and is
> > > unpredictable in silly ways.
> > 
> > What problems (details)?  Why it it hard to read?  It is trivial to read
> > and understand.
> 
> Who says printf is not a macro?

And if it is how would that cause problems above?

> What is the return value?

What does it matter if you ignore it?

> void main()
> {
> 	printf("hello world\n");
> }
> 
> Is much easier to read, making the one liner "hard".

*phhfft*  The first is so trivial that the second isn't any easier to
read.

> (Trivial example,
> don't belabour this point).

Ok, ignore the above sentence.

> There is non-style(9) code in the tree that is much harder to read
> before it is style.9-ified.

And there is style(9) code in the the tree that is easier to read before
it's style-ified as well.  Your point?

> > > NO! I am not. If I wanted to do that, I'd do something dumbass like
> > > indent(1) all the code.
> > 
> > It seems to me to be almost the same thing, but at least with indent,
> > bugs are introduced. :(
> 
> I guess you mean "NOT introduced"?

*Duh*  Look, I just introduced a bug in my email. :)

> > *EVERYONE* likes well-written/safe code.  Running it through lint and
> > fixing errors doesn't necessarily provide you with either feature.
> 
> Huh?
> 
> Fixing errors doesn't help make safe(r) code?

Bad wording.  Fixing 'lint/gcc' complaints doesn't necessarily make the
code safer or more well-written.  The compiler and/or lint fixing may
actually make the code harder to read, with no gain in safety.

(Note, I said *may*, not *will not*.)

Basically, I think having the changes reviewed before they are committed
is the best solution.



Nate

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15495.60301.617215.87829>