From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by hurricane.the-brannons.com (Postfix) with ESMTP id 6974D78A65 for ; Fri, 8 Aug 2014 04:56:11 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta10.westchester.pa.mail.comcast.net with comcast id cBrp1o0010Fqzac5ABvK75; Fri, 08 Aug 2014 11:55:19 +0000 Received: from eklhad ([IPv6:2601:4:5380:4ee:21e:4fff:fec2:a0f1]) by omta08.westchester.pa.mail.comcast.net with comcast id cBvJ1o00n5LMg213UBvKiC; Fri, 08 Aug 2014 11:55:19 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.5.1 Date: Fri, 08 Aug 2014 07:52:52 -0400 Message-ID: <20140708075252.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407498919; bh=iy5c6Hc2g3TT2Mw12cqm7ZYoCpy6UH/+MXwooDfnsfs=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=GvtDnDIY4Y+JR/vJnvPtDhZs4RGreGo2l3Iu6VPGmh4wlh0pEB84LZItfdoq0LU7X JRiK2Qmqs2EkKzhrNWFDNHx0ug+AqJ5Mw9bvNMezQfBsYsy5aWDdqHwiSPrxsWl3Zd G8Wq5n3yQrlngrzBs269WSh0ctE4hupZEO07WSRMHjAjoy6HGAuo4hfmZHKb32nH7d yjp7BXzPhM7qyZr0Fb/Y2qOUG7blGhv1kDeVxJf/pgyqLxQxc9kshIqMzYn2P+QXMH a6CgxVLl8+2caarSUrEluMMckAYG943GypKGaXUGV8Md7PvuJ9Ud+S6dKh0q34jg6j /RXJo17g/tX/g== Subject: [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 11:56:11 -0000 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