Help new contributors by providing some advice about line-wrapping; the
advice basically boils down to "use 80-characters minus some slop as a
rule of thumb", but also "use common sense", and "avoid gratuitous
rewrapping".
Signed-off-by: Wincent Colaiuta <win@xxxxxxxxxxx>
---
El 14/11/2007, a las 11:37, Junio C Hamano escribió:
Wincent Colaiuta <win@xxxxxxxxxxx> writes:
A statistician could probably make some interesting comments about
the
results, but the basic trend is that, while there are plenty of
examples of isolated long lines in the source tree (the longest is a
287-character line in one of the perl scripts), the frequency starts
to drop off pretty rapidly once you pass 70 columns and start
climbing
towards 80.
Gaah. 287???
Actually, not true. The longest line in a perl script is 209 chars
(217 columns if you expand the leading tab), in file git-
cvsexportcommit.perl.
The 287-char line was actually in builtin-update-index.c; this and
most of the other really huge lines are usage strings.
+ - In the case of documentation, mixing excessively long and short
+ lines may make the AsciiDoc source harder to read, so try to
+ keep line lengths consistent.
+
+ - When submitting patches use common sense to decide whether to
+ rewrap, avoiding gratuitous changes.
Hmph. The last item applies only to the documentation because
it uses the word "rewrap", but otherwise applies equally well to
the sources (re-indenting). So probably "whether to rewrap or
reindent" would be a good change there.
Updated patch follows.
Documentation/CodingGuidelines | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/Documentation/CodingGuidelines b/Documentation/
CodingGuidelines
index 3b042db..3eecb64 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -110,3 +110,25 @@ For C programs:
used in the git core command set (unless your command is clearly
separate from it, such as an importer to convert random-scm-X
repositories to git).
+
+Line wrapping:
+
+ - While there are no official hard limits for line wrapping, we
+ generally try to keep shell scripts, C source files and AsciiDoc
+ documentation within the range of "80-characters minus some
+ slop".
+
+ - We assume that everyone has terminals that are at least 80
+ columns wide.
+
+ - In practice, we try to keep lines somewhat narrower than 80
+ columns to accommodate diff change marks [-+ ] and quoting ">> "
+ in emails.
+
+ - In the case of documentation, mixing excessively long and short
+ lines may make the AsciiDoc source harder to read, so try to
+ keep line lengths consistent.
+
+ - When submitting patches use common sense to decide whether to
+ rewrap (or reindent), avoiding gratuitous changes.
+
--
1.5.3.5
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
