Date: Mon, 18 Dec 2000 14:17:12 -0700 From: Drew Eckhardt <drew@PoohSticks.ORG> To: hackers@FreeBSD.ORG Subject: Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c) Message-ID: <200012182117.eBILHCh06143@chopper.Poohsticks.ORG> In-Reply-To: Your message of "Mon, 18 Dec 2000 13:11:12 CST." <20001218131112.B65143@hamlet.nectar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20001218131112.B65143@hamlet.nectar.com>, n@nectar.com writes:
> /* Case 1 */ /* Case 2 */
> if (data) vs. free(data)
> free(data);
>
>I don't see that Case 1 obfuscates anything. In some cases I find it
>clearer: Case 1 implies that maybe no memory was allocated. Case 2
>seems to imply that memory was indeed allocated.
When functions fit on one screen (where "one screen" is platform
dependant, but probably 80 columns wide (you may want hard copy
which doesn't wrap) and somewhat less than 60 lines long (given
19" monitors as a defacto standard and the font sizes required
to accomodate aging eyes that have stared at computer screens
for far too long)), you can see variable definitions and their use
at the same time, if and else clauses at the same time, the end of
for loops along with what happens to variables just after that, etc.
Such functions can be groked in less time than those suffering
from sprawl.
Anything which stretches functions out like this
if (data) {
free(data);
}
rather than this
free(data);
contributes to sprawl, and in marginal cases may be the proverbial
straw which breaks the camel's back.
if (data) free (data);
doesn't pose that problem, although it is inconsistant with most
coding standards.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012182117.eBILHCh06143>