edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Karl Dahlke <eklhad@comcast.net>
To: Edbrowse-dev@lists.the-brannons.com
Subject: [Edbrowse-dev] [patch] Parenthesize assignments used as a truth...
Date: Fri, 08 Aug 2014 07:52:52 -0400	[thread overview]
Message-ID: <20140708075252.eklhad@comcast.net> (raw)

if(t = strchr(line, '@')) {

I have to admit I am a bit hesitant about adding in the extra parentheses

if((t = strchr(line, '@'))) {

and not because of any screen reader.
Rather the parentheses add almost no new information.
They don't make clear the order of operations.
There is no parsing ambiguity.
The line can only run as it runs.
Unlike some of the lines with many operators,
especially the shift and booleans, where the C precedence is really
quite counterintuitive.
Or the ?: with other stuff going on.
I can see adding parentheses to those for clarity.
But to me lines like this seem perfectly clear.
And 2 extra chars, or perhaps 4 after you run indent,
well, if the line is inside some blocks,
4 more chars could push you over 80 and then the damn indenter cuts the line in two,
and then you're reading the logical line of code across two physical lines.
Now that is annoying.
Oh I know, at this point you tell me I have too many
nested blocks, and yeah you might be right,
but it is what it is.
There are a couple of places where it's almost criminal what indent does.

if(z ==
23 ||
y ==
37 ||
q == 1 &&

etc all tabbed over to the right.
Makes me wish I'd stayed with my original 4 space indent instead of the linux kernel
standard 8 space indent.
Or maybe it's what I deserve for nesting 5 blocks.
Anyways I'm a little off topic.
I'll probably hang on to this patch and not push it now,
unless everyone else unanimously thinks I should.

Karl Dahlke

             reply	other threads:[~2014-08-08 11:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-08 11:52 Karl Dahlke [this message]
2014-08-08 18:07 ` Adam Thompson

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=20140708075252.eklhad@comcast.net \
    --to=eklhad@comcast.net \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    /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).