Date: Thu, 24 Jan 2013 17:00:14 +0100 From: Michael Gmelin <freebsd@grem.de> To: Dag-Erling =?UTF-8?B?U23DuHJncmF2?= <des@des.no> Cc: freebsd-ports@freebsd.org Subject: Re: Using bidirectional authentication in pkgng Message-ID: <20130124170014.57c5fa1a@bsd64.grem.de> In-Reply-To: <86libitxit.fsf@ds4.des.no> 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> <86libitxit.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 24 Jan 2013 16:23:54 +0100 Dag-Erling Sm=C3=B8rgrav <des@des.no> wrote: > 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. Hm, so this will probably get me again, but thanks for the mode, it will certainly help. >=20 > I wrap comments at 74, and *try* to keep code closer to 74 than 80. >=20 > 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. Ok, is that only for libfetch or for all of kernel (just for future reference). >=20 > 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(). That's true, I'm just used to really long identifiers from work and wanted to make sure it's relatively easy to read the algorithm (well, the lack of temporaries makes it harder to read again I admit). >=20 > > > - 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). >=20 > s/not allowed/strongly discouraged/ Ah ok. I don't have many of those though. >=20 > > Could you point me to the section in style(9) that specifies this > > (couldn't find it)? >=20 > Parts of a for loop may be left empty. Do not put declarations > inside blocks unless the routine is unusually complicated. Thanks. >=20 > > 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. >=20 > DES Thanks for the detailed explanation. So do you think you could fix these style issues yourself, or should I give it a shot (I'm certain I will miss *some* of those issues but it will definitely get better). Cheers, --=20 Michael Gmelin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130124170014.57c5fa1a>