{"thread":{"id":"10866","subject":"[PATCH v2] Add line-wrapping guidelines to the coding style documentation","startedAt":"2007-11-14T11:32:58Z","lastAt":"2007-11-14T11:32:58Z","messageCount":1,"participants":["Wincent Colaiuta"],"isPatch":true,"patchVersion":2,"patchTotal":null},"messages":[{"id":"59845","messageId":"1037166E-C1B1-43A9-9B12-5866632CADCC@wincent.com","threadId":"10866","inReplyTo":"A18FC90C-5874-445A-93CE-9E05D02C614F@wincent.com","subject":"[PATCH v2] Add line-wrapping guidelines to the coding style documentation","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-11-14T11:32:58Z","receivedAt":"2007-11-14T11:32:58Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"Help new contributors by providing some advice about line-wrapping; the\nadvice basically boils down to \"use 80-characters minus some slop as a\nrule of thumb\", but also \"use common sense\", and \"avoid gratuitous\nrewrapping\".\n\nSigned-off-by: Wincent Colaiuta <win@wincent.com>\n---\n\nEl 14/11/2007, a las 11:37, Junio C Hamano escribió:\n\n> Wincent Colaiuta <win@wincent.com> writes:\n>\n>> A statistician could probably make some interesting comments about  \n>> the\n>> results, but the basic trend is that, while there are plenty of\n>> examples of isolated long lines in the source tree (the longest is a\n>> 287-character line in one of the perl scripts), the frequency starts\n>> to drop off pretty rapidly once you pass 70 columns and start  \n>> climbing\n>> towards 80.\n>\n> Gaah.  287???\n\nActually, not true. The longest line in a perl script is 209 chars  \n(217 columns if you expand the leading tab), in file git- \ncvsexportcommit.perl.\n\nThe 287-char line was actually in builtin-update-index.c; this and  \nmost of the other really huge lines are usage strings.\n\n>> + - In the case of documentation, mixing excessively long and short\n>> +   lines may make the AsciiDoc source harder to read, so try to\n>> +   keep line lengths consistent.\n>> +\n>> + - When submitting patches use common sense to decide whether to\n>> +   rewrap, avoiding gratuitous changes.\n>\n> Hmph.  The last item applies only to the documentation because\n> it uses the word \"rewrap\", but otherwise applies equally well to\n> the sources (re-indenting).  So probably \"whether to rewrap or\n> reindent\" would be a good change there.\n\nUpdated patch follows.\n\nDocumentation/CodingGuidelines |   22 ++++++++++++++++++++++\n1 files changed, 22 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/CodingGuidelines b/Documentation/ \nCodingGuidelines\nindex 3b042db..3eecb64 100644\n--- a/Documentation/CodingGuidelines\n+++ b/Documentation/CodingGuidelines\n@@ -110,3 +110,25 @@ For C programs:\n    used in the git core command set (unless your command is clearly\n    separate from it, such as an importer to convert random-scm-X\n    repositories to git).\n+\n+Line wrapping:\n+\n+ - While there are no official hard limits for line wrapping, we\n+   generally try to keep shell scripts, C source files and AsciiDoc\n+   documentation within the range of \"80-characters minus some\n+   slop\".\n+\n+ - We assume that everyone has terminals that are at least 80\n+   columns wide.\n+\n+ - In practice, we try to keep lines somewhat narrower than 80\n+   columns to accommodate diff change marks [-+ ] and quoting \">> \"\n+   in emails.\n+\n+ - In the case of documentation, mixing excessively long and short\n+   lines may make the AsciiDoc source harder to read, so try to\n+   keep line lengths consistent.\n+\n+ - When submitting patches use common sense to decide whether to\n+   rewrap (or reindent), avoiding gratuitous changes.\n+\n-- \n1.5.3.5\n"}]}