This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/3] Move mips hardware watchpoint stuff to common/
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Yao Qi <yao at codesourcery dot com>, <gdb-patches at sourceware dot org>
- Date: Thu, 20 Jun 2013 23:28:24 +0100
- Subject: Re: [PATCH 2/3] Move mips hardware watchpoint stuff to common/
- References: <1369881867-11372-1-git-send-email-yao at codesourcery dot com> <1369881867-11372-3-git-send-email-yao at codesourcery dot com> <51B93F00 dot 5090002 at codesourcery dot com> <alpine dot DEB dot 1 dot 10 dot 1306171650220 dot 16287 at tp dot orcam dot me dot uk> <51C305F0 dot 90008 at codesourcery dot com> <alpine dot DEB dot 1 dot 10 dot 1306201624110 dot 16287 at tp dot orcam dot me dot uk> <20130620172844 dot GE4724 at adacore dot com>
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