flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Left Right <olegsivo...@gmail.com>
Subject Re: Code formatting for patch submissions
Date Mon, 27 Feb 2012 21:46:31 GMT
A bore in me says: 80 characters limitation isn't related to CRT
technology, it comes from terminals, which inherited this limitation from
analogue devices - typewriters. In the olden days, if you submitted the
manuscript to print, the A4 contained exactly 72 characters in a line typed
on typewriter. It could be even an ISO standard or something. This,
including the width of the margins would make up for 80 characters.

Nowadays some find this limitation out of date, however, it is rooted in a
research into Roman-German family of languages and the optimal number of
characters of an optimal size the human would be likely to digest. This has
been altered many times, and the civilization plagued by computer-generated
texts has lost the battle between the ugly and beautiful :) And, if you are
on a Mac, then the line 100 characters long of the same font, same size
looks _entirely_ different than it looks on PC. Now add to that that some
people use different fonts to render the code, and some particularly
anathemas use variable-width fonts to render the code (Bjorne Straustrup
for instance)!

There are still things that are limiting the code width to 80 characters:
1. Book publishing. If you want your code to retain it's original view in
the book, trust me, 80 characters, and not a single one more!
2. Sending code via e-mail. E-mail systems were invented in between Fidonet
become extinct and just couple million years before the dinosaurs become
extinct. They still wrap text at precisely 80 characters, so if you want to
send your code intact, 80 characters and don't you dare to add more.
3. Mergetools and people that use them. Them people who use them like to
see 3 screenfulls of code at one time [theirs] [merged] [mine]. Having to
scroll the screens yields a lot of yielding at those unaware of 80
characters per line limitation.

I'm not arguing the 100 characters limitation, it's only that I will
probably, instinctively wrap lines before they are that long.
I would, however, be happy if the curly brackets following package
declaration were allowed to not to create an additional indent, because it
creates 12 spaces before you started to write _any_ code at all (which, for
example, according to Linux code guidelines is already too late for you to
write any code). :)
I saw that this was randomly done in some files in the SDK. I'd be in favor
that would be made into a rule.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message