From owner-freebsd-ports@FreeBSD.ORG Thu Jan 24 15:23:56 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CB7C2A54 for ; Thu, 24 Jan 2013 15:23:56 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 589D3F01 for ; Thu, 24 Jan 2013 15:23:56 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 445F16E59; Thu, 24 Jan 2013 15:23:55 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 08F25A427; Thu, 24 Jan 2013 16:23:54 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Michael Gmelin Subject: Re: Using bidirectional authentication in pkgng References: <20130118035721.283135fb@bsd64.grem.de> <50F9B6CC.3040303@infracaninophile.co.uk> <20130122193035.4c51be04@bsd64.grem.de> <20130123004147.GG27275@ithaqua.etoilebsd.net> <86d2wuvrjg.fsf@ds4.des.no> <20130124121942.07436be3@bsd64.grem.de> <86r4lau2wh.fsf@ds4.des.no> <20130124151629.588c33c8@bsd64.grem.de> Date: Thu, 24 Jan 2013 16:23:54 +0100 In-Reply-To: <20130124151629.588c33c8@bsd64.grem.de> (Michael Gmelin's message of "Thu, 24 Jan 2013 15:16:29 +0100") Message-ID: <86libitxit.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 15:23:56 -0000 Michael Gmelin writes: > Dag-Erling Sm=C3=B8rgrav writes: > > - Several lines are too long, and almost all your continuation lines > > are misindented. > Hm, I used an emacs mode that was supposed to indent according to > style(9) - so maybe that wasn't the right tool. Do you have a link to > an emacs mode that works like expected? (I clearly won't do these > indentations manually, they're so counter-intuitive to me that I would > mess them up badly - it's hard to work against your organization's > usual coding style and switching back and forth). Any recommended > combination of lint/indent/whatever I could use to validate the code > automatically? (defun des-knf () (interactive) (c-set-style "bsd") ;; Basic indent is 8 spaces (setq c-basic-offset 8) (setq tab-width 8) ;; Continuation lines are indented 4 spaces (c-set-offset 'arglist-intro 4) (c-set-offset 'arglist-cont 4) (c-set-offset 'arglist-cont-nonempty 4) (c-set-offset 'statement-cont 4) (c-set-offset 'cpp-macro-cont 8) ;; Labels are flush to the left (c-set-offset 'label [0]) ;; Fill column (setq fill-column 74)) (add-hook 'c-mode-common-hook 'des-knf) but Emacs will still misindent continuation lines in some cases, e.g. when a line break occurs within nested parentheses; AFAICT from the documentation, there is no way to tune that. > I just checked, all lines I added are <80 characters. Style(9) itself > doesn't specify any line length limitations, so I figured staying > below 80 is already quite conservative (or are you going really old > school and limit yourself to 72?). Since I found quite a number of > lines that are longer than that I figured it would be ok. I wrap comments at 74, and *try* to keep code closer to 74 than 80. Some of the code in http.c is so deeply nested that it is almost impossible to stay within 80 characters. This is a clear sign that the code needs to be rewritten. BTW, you'd have an easier time avoiding long lines if you used shorter function and variable names and assigned commonly used expressions to temporary variables, e.g. (matcheslen - (firstmatchdot - matches) in fetch_ssl_hostname_match(). > > - You declare variables inside blocks, and declarations in general > > are not properly sorted. > I wasn't aware that this is not allowed (it's such an incredibly > useful feature to me). s/not allowed/strongly discouraged/ > Could you point me to the section in style(9) that specifies this > (couldn't find it)? Parts of a for loop may be left empty. Do not put declarations inside blocks unless the routine is unusually complicated. > > There are issues with the man page as well - you didn't bump the > > date, sentences don't begin on new lines, and some lines are too > > long - but you get a million bonus points for updating it at all. > Do you have a good pointer to style guides for man pages/nroff? Didn't > bump the date since I figured it won't be accepted unchanged anyway. The closest we have is mdoc(7). I'm not sure where / whether the requirement to start sentences on a new line is documented, but this is actually a feature of *roff rather than a style issue; it has to be able to tell the difference between the period that follows an abbreviation and the period at the end of a sentence. For the same reason, Emacs will never insert a line break after a period followed by a single space when wrapping text. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no