From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28570 invoked by alias); 20 Jun 2013 22:28:38 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 28561 invoked by uid 89); 20 Jun 2013 22:28:38 -0000 X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL autolearn=ham version=3.3.1 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 20 Jun 2013 22:28:36 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1UpnLG-0002Sc-Bk from Maciej_Rozycki@mentor.com ; Thu, 20 Jun 2013 15:28:34 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jun 2013 15:28:34 -0700 Received: from [172.30.64.40] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Thu, 20 Jun 2013 23:28:31 +0100 Date: Fri, 21 Jun 2013 08:03:00 -0000 From: "Maciej W. Rozycki" To: Joel Brobecker CC: Yao Qi , Subject: Re: [PATCH 2/3] Move mips hardware watchpoint stuff to common/ In-Reply-To: <20130620172844.GE4724@adacore.com> Message-ID: References: <1369881867-11372-1-git-send-email-yao@codesourcery.com> <1369881867-11372-3-git-send-email-yao@codesourcery.com> <51B93F00.5090002@codesourcery.com> <51C305F0.90008@codesourcery.com> <20130620172844.GE4724@adacore.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-06/txt/msg00575.txt.bz2 On Thu, 20 Jun 2013, Joel Brobecker wrote: > > > If we put the prototypes into a single line, the length exceeds the > > > 74-character limit. This is the reason I moved parameter "set" to a new line. > > > Shall we keep them as what they are now? > > > > There's no 74-character limit for code, all you need is to stay > > within 79 columns. Did you apply the ChangeLog rule here? > > Actually, the last time we discussed maximum code line length, > we settled on 70 characters. > > Reference: http://www.sourceware.org/ml/gdb-patches/2011-01/msg00035.html Hmm, interesting, thanks for your input. However I find Mark's observation more focused on comments than actual code. And I tend to agree there, I find reading comments more like reading e-mail, they seem to get harder to parse as they get close to reaching the right margin and as you may have noticed not only I try to keep lines shorter in comments than in code but I try to make paragraphs have a good look as well (I sometimes use synonyms, try to substitute words or rephrase sentences if the formatting renders bad otherwise). > It's not consistent across files; for instance, it's 74 characters > in ChangeLogs. Those limits are kind of arbitrary, but I do find 79 > characters to be slightly harder to read. Jan recently opened that > discussion again, and proposed 80 characters, but that did not stick. I think 80 is dangerous. Even though CRT (let alone hardcopy) terminals are virtually gone (they often truncated rather than wrapped oversize lines, at least by default), it's still the canonical line width on many terminal emulations and I think many people stick to that. And operations on the last column can yield odd effects with some combinations of a text editor and a terminal emulation. It's even worse if the line is the last one on the screen -- some terminals havebeen unable to put a character there without issuing a line feed at the same time, making all the screen contents scroll away by one line (which is why ncurses have some hacks around the last character in the last line too and some full-screen programs avoid printing anything there). Therefore I think it's simply safer to stay away from the last character, except in justified special circumstances (e.g. owing to long statements and a syntax different to C with TCL programs I often find it hard to get good formatting results where split lines are involved). > I proposed to standardize on 74 instead, which is already the default > for some editors and the value used for ChangeLogs. But the discussion > then died. I'm not too surprised, since it's impossible to please > everybody, and controversial changes in the GDB porject have a tendency > of getting stuck. All the free software projects I have ever participated in in some way, including all the FSF projects and the Linux kernel in particular, seemed just to require code lines to fit on a single terminal line, with column #80 typically being a taboo as noted above. I've been wondering whether a rule has been written down somewhere for FSF software and checked: http://www.gnu.org/prep/standards/html_node/Formatting.html but that doesn't say anything specific. In the next step I have found out that `indent -gnu' sets the line width to 78, that may be indicative, however the page referred to above explicitly says any `indent' settings are merely recommendations for projects, not hard requirements. Personally I think a limit of 74 columns (which is a distance of 6 characters from the right margin on an 80-column terminal) is somewhat difficult to handle in practice, because you have to manually verify each individual line is not wider than that (the editor may aid you with that, but typically you need to check each line individually, by moving the cursor there). OTOH with the limit of 79 (or maybe 78) characters you can see right away by merely looking at a screenful of code if any lines are out of the limit, because the distance of 1 or 2 characters from the right margin is easily judged by the eye. FWIW and IMHO. Maciej