linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Sottek, Matthew J" <matthew.j.sottek@intel.com>
To: <dri-devel@lists.sourceforge.net>
Cc: <linux-kernel@vger.kernel.org>
Subject: RE: [Dri-devel] Re: [PATCH] CodingStyle fixes for drm_agpsupport
Date: Mon, 11 Aug 2003 13:21:22 -0700	[thread overview]
Message-ID: <A98078D7EF5BEA4D8D8FD797FFBBC75F0453FCEA@fmsmsx402.fm.intel.com> (raw)


> if (!pointer) {
>	return (whatever);
> }
>
>
>because it's consistent, and guaranteed safe from stupid
>parsing errors that can waste days of debug time when
>someone decides to add to it.
>("its just a little change that cant hurt anything", ha ha)

I've always been an "Always use brackets" evangelist for two
reasons.
1) The time it takes to write the code fragment is noise
compared to the amount of cumulative time that everyone else
will spend reading it over it's lifespan. This is more true
in open source than it ever was in the closed source world.
Making the code explicit saves everyone time in the longrun.

2) There are some very real ways that bracketless code will
get broken. Either someone adds a line that didn't notice the
lack of brackets or, someone accidentally uses a multi-line
macro.

i.e.
   if(foo)
     DEBUG_PRINT("Foo!\n");

works great for 100 years until someone recodes the DEBUG_PRINT
macro to be 2 lines. The Linux kernel often has plain looking
functions or variables that end up being macros (and may only
expand to multi-line on some platforms) which could easily get
you into such a situation.




             reply	other threads:[~2003-08-11 20:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-11 20:21 Sottek, Matthew J [this message]
2003-08-12  7:11 ` [Dri-devel] Re: [PATCH] CodingStyle fixes for drm_agpsupport Ryan Anderson
2003-08-12 12:05 ` Peter "Firefly" Lund
  -- strict thread matches above, loose matches on Subject: below --
2003-08-11 15:59 davej
2003-08-11 16:40 ` Larry McVoy
2003-08-11 16:58   ` Jeff Garzik
2003-08-11 17:04     ` Larry McVoy
2003-08-11 17:15       ` Jeff Garzik
2003-08-11 17:23         ` Larry McVoy
2003-08-11 17:53           ` Jeff Garzik
2003-08-11 17:59             ` Larry McVoy
2003-08-11 19:09               ` [Dri-devel] " Philip Brown
2003-08-12 12:07                 ` Peter "Firefly" Lund
2003-08-14 14:21       ` Eli Carter
2003-08-14 14:47         ` Larry McVoy
2003-08-14 18:43           ` [Dri-devel] " Philip Brown
2003-08-14 18:59             ` Randy.Dunlap
2003-08-14 20:16             ` Larry McVoy
2003-08-14 20:21               ` Eli Carter
2003-08-14 20:22                 ` Larry McVoy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=A98078D7EF5BEA4D8D8FD797FFBBC75F0453FCEA@fmsmsx402.fm.intel.com \
    --to=matthew.j.sottek@intel.com \
    --cc=dri-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).