Prev: FAQ Topic - Why does my code fail to access an element? (2010-06-15)
Next: Using __proto__ seems to be slower than applying prototype properties manually
From: Garrett Smith on 14 Jun 2010 19:47
On 6/1/2010 7:44 AM, Thomas 'PointedEars' Lahn wrote:
> Garrett Smith wrote:
>
>> David Mark wrote:

[...]

> Therefore, AISB, it would be a good idea that code being reviewed should be
> marked as quotation if possible, to clearly distinguish it from comments and
> code suggestions; if the original code has not been discussed in the thread
> previously, then as third-party quotation with `|'. Many newsreaders
> provide the capability to do that automatically. (And no, I do not think
> that the limited capabilities of the buggy Web interface of the Google
> Groups archive should define the posting guidelines for any newsgroup.)
>
>> and is harder to read than it would be, had it been formatted to< 72
>> character width.
>
> Let x be the length of the longest line in a posting except the new-line
> character (sequence), that which you mislabeled "character width". Then
> insisting on x< 72 is utter nonsense, far from reality: very few people
> would write code like this (not even you), that would waste a lot of disk
> space and add bogus LOCs. 72<= x<= 80 is reasonable. x<= 80 is
> necessary since a newsgroup, especially a technical one, may be read from a
> standard issue virtual terminal, and there is of course the basic
> readability aspect of not having too many characters in one line (think of
> newspapers and books).
>

SO you're saying that this:-

| Code should be formatted to a maximul line length. For newsgroup
| code, it should not exceed 72 chars.

- should be changed to 80 chars?

Will any newsreaders automatically rewrap the lines to fewer characters?
What about when replying? For example, I am concerned about:

this.is.a.very.looooong.code.line(/asdfqw[\b\n\u0020asdfgzxc13579]?/);

Becomes:
> this.is.a.very.looooong.code.line(/asdfqw[\b\n\u0020asdfgzxc13579]?
> ?/)

Becomes eventually:
>>>> this.is.a.very.looooong.code.line(/asdfqwer[\b
>>>> \u0020asdfgzxc13579]
>>>> )?/)

If the suggestion is to format to 72-char width, the code is less likely
to be wrapped by a reader.


> Further, you cannot reasonably blame David (or anyone else) for not
> rewrapping each and every LOC in *other's* code when making their *review*.

Code should be formatted before posting to the NG.

When the code is obfuscated from the beginning or when it uses tabs or
very long lines, it makes it hard to read. Reformatting being painful
provides motivation for the person doing reformatting to want to
reformat the least amount necessary and if everything posted is
reformatted, it can have the effect or reducing the amount of code
posted. This in turn has the effect of making the reader focus on just
that chunk.

When code has been reformatted, the one posting the code should mention
that it was reformatted.

Reformatting can have the effect of making poster look at the code again
before posting.

> The (qooxdoo) authors should have wrapped earlier and used proper (multi-
> line documentation) comments in the first place; IMHO, that the code is
> wrapped when posted to a newsgroup is good indication that it has never been
> seriously peer-reviewed before.
>

It is their choice to use whatever formatting they like and to even
publish code minified or with tabs, if they want.

Code that has no spaces, as minified code found on google groups, or
code that has been formatted with tabs, such as jQuery, should be
reformatted before posting.

> When I had quoted from qooxdoo code¹, I had to trim the indentation to that
> it would fit into a line of max. 76 characters (that is where I draw the
> line in Usenet, as it has served me well in the past). Still, I needed to
> place one word in a comment on the next line and add the `//'. While that
> makes it easier visible that this line belongs to the comment, it also moves
> the rest of the lines one forward, thereby changing the line numbers to
> something different then used in a possible source code reference. And that
> was only one occurrence.
>
> This should be taken into consideration when defining posting guidelines for
> this newsgroup. (It should be obvious that such rules cannot be enforced
> here, only lived by regulars providing a good example.)
>

The formatting section is a formalized summary of suggested conventions
for posting code. It's intended to help communication by improving the
quality of the post.

[...]

Garrett
From: Dr J R Stockton on 16 Jun 2010 14:37
In comp.lang.javascript message <hv6f27$26f$1(a)news.eternal-
september.org>, Mon, 14 Jun 2010 16:47:23, Garrett Smith
<dhtmlkitchen(a)gmail.com> posted:

>On 6/1/2010 7:44 AM, Thomas 'PointedEars' Lahn wrote:
>> Let x be the length of the longest line in a posting except the new-line
>> character (sequence), that which you mislabeled "character width". Then
>> insisting on x< 72 is utter nonsense, far from reality: very few people
>> would write code like this (not even you), that would waste a lot of disk
>> space and add bogus LOCs. 72<= x<= 80 is reasonable. x<= 80 is
>> necessary since a newsgroup, especially a technical one, may be read from a
>> standard issue virtual terminal, and there is of course the basic
>> readability aspect of not having too many characters in one line (think of
>> newspapers and books).
>>
>
>SO you're saying that this:-
>
>| Code should be formatted to a maximul line length. For newsgroup
>| code, it should not exceed 72 chars.
>
>- should be changed to 80 chars?

Ignore the oaf.

Seventy-two characters is the Usenet standard for ordinary text, to
allow for multiple quoting within 80 characters, which is the limit for
signatures.

Code and data for Usenet should normally be written within 72
characters, but may need to be wider. It is then important that the
posting agent does not wrap it unintelligently. A well-written posting
agent will allow lines (but not by default) up to the Usenet maximum,
which is at least large.


>Will any newsreaders automatically rewrap the lines to fewer
>characters? What about when replying?

Good newsreaders will allow their users the readers to adjust such
things, per article, while reading.


> For example, I am concerned about:
>
> this.is.a.very.looooong.code.line(/asdfqw[\b\n\u0020asdfgzxc13579]?/);
>
>Becomes:
>> this.is.a.very.looooong.code.line(/asdfqw[\b\n\u0020asdfgzxc13579]?
>> ?/)
>
>Becomes eventually:
>>>>> this.is.a.very.looooong.code.line(/asdfqwer[\b
>>>>> \u0020asdfgzxc13579]
>>>>> )?/)


In many cases, simple changes to the code will reduce line length :

T = this.is.a.very.looooong.code.line // no more
T(/asdfqw[\b\n\u0020asdfgzxc13579]?/);


>If the suggestion is to format to 72-char width, the code is less
>likely to be wrapped by a reader.

After quoting, code is not executable without repair anyway, so wrapping
after considerable quoting is unimportant. One can generally locate for
use the original posting of the code.

--
(c) John Stockton, nr London UK. replyYYWW merlyn demon co uk Turnpike 6.05.
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes precede replies. Snip well. Write clearly. Mail no News.
 | 
Pages: 1
Prev: FAQ Topic - Why does my code fail to access an element? (2010-06-15)
Next: Using __proto__ seems to be slower than applying prototype properties manually