From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 40FB178AE0 for ; Fri, 8 Aug 2014 11:08:40 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id f8so2903220wiw.3 for ; Fri, 08 Aug 2014 11:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=kEwXbmd/FMJjK9ElRiTgor3fkWjlaXWHtceBKDrrsiU=; b=hmokp6RR5d6Ro6he5cViaI/lLOQJu6j0TCKPdfr6k5bj8/Z/fMpO+XFxqWioJzd2al J1a2HR0CE9TZe1mDjN11BNrZOQHqt9d4LuwyRXNr9dqoiZgJFcwT9YrhEflCl1S26L1z v7l7s4ixhqkHzAvqeociIGojb9OazIDQ+0Jf2o4LarQcHeVs9kZSSHW2kxhxOPc28rAO hAFyVHdFIQdQxWKlWqqKsmnnE1nrC7FDxjb6ssYc53JPqNu51OLS6p9/QT/u+FoqtnPR tlBSoiMnFkWnix6SB/xg20zOYyLHZ9SEdZi+zsB5mOGFtbc6Fm41cRsOFMCMbi3VEX33 uu7w== X-Received: by 10.194.109.71 with SMTP id hq7mr5530867wjb.114.1407521266830; Fri, 08 Aug 2014 11:07:46 -0700 (PDT) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by mx.google.com with ESMTPSA id i8sm9566588wib.6.2014.08.08.11.07.45 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 08 Aug 2014 11:07:45 -0700 (PDT) Date: Fri, 8 Aug 2014 19:07:43 +0100 From: Adam Thompson To: Karl Dahlke Message-ID: <20140808180743.GB5637@toaster.adamthompson.me.uk> References: <20140708075252.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dc+cDN39EJAMEtIO" Content-Disposition: inline In-Reply-To: <20140708075252.eklhad@comcast.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Edbrowse-dev@lists.the-brannons.com Subject: Re: [Edbrowse-dev] [patch] Parenthesize assignments used as a truth... X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 18:08:40 -0000 --dc+cDN39EJAMEtIO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 08, 2014 at 07:52:52AM -0400, Karl Dahlke wrote: > if(t =3D strchr(line, '@')) { >=20 > I have to admit I am a bit hesitant about adding in the extra parentheses >=20 > if((t =3D strchr(line, '@'))) { >=20 > 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. I agree, but if we want to get rid of warnings then we may as well. > 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 l= ine in two, > and then you're reading the logical line of code across two physical line= s. > Now that is annoying. Yep. > 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. I'd rather have lots of nesting than lots of functions created for the sing= le purpose of removing nested blocks. > There are a couple of places where it's almost criminal what indent does. >=20 > if(z =3D=3D > 23 || > y =3D=3D > 37 || > q =3D=3D 1 && >=20 > etc all tabbed over to the right. > Makes me wish I'd stayed with my original 4 space indent instead of the l= inux kernel > standard 8 space indent. > Or maybe it's what I deserve for nesting 5 blocks. I've always prefered a 4 space indent (well actually I've only started indenting since I had to start doing Python 3 years ago and even now someti= mes I forget), but at least 4 spaces is enough for me to notice the difference in indentation and not so much that 5 blocks has eaten half my braille display, not to mention trying to count 40 spaces with a screen reader or what happe= ns when I use a 40 cell braille display. At any rate it's better than a 3 (yep that realy is 3 and not a typo) spaces as used at the last place I worked. That basically came as the worst of both worlds between those who wanted 2 = and those who wanted 4 space indentation, and was decided way before my time th= ere. Getting indent to do that was... fun. I think I (and those who reviewed my code) ended up accepting some seriously mangled indentation in the end. > 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. I'd say push it on the basis that we're looking for a clean compile and it'll probably save having this discussion in a few months time. Cheers, Adam. --dc+cDN39EJAMEtIO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJT5RHvAAoJELZ22lNQBzHOcbMIAInGaknKjzGjxaqoJg80zlQu ZJFSLqJ62w2WnWatvQtKh4WQOUW89hOhksg+1qZ6cpVokvbJbQcqePmXMt5mwbuh LTv29F2edo/kPF81pWNYsVy0J11C1c1lv10921QIm/rR+z2qOzXfm4Ad4n50qIZ8 HCpLZ18B65gsCgf04USEqzg19wdoUfCnuozZ2d+cEJLSY6Tjk4ZuEtoF15W6Qe09 F1BdF349vWAjB10EyrY8gVUEtSLx5LihpXTmLQI0yeuJ+XhmvEJw2Tzugiub+QJB 7iEm4mGPy/f/Jwv4tDTtrK/VY6mqV8JVhxNpEMSiJcxts9hyODUbjkSdkXifpfM= =bGrw -----END PGP SIGNATURE----- --dc+cDN39EJAMEtIO--