Perry E. Metzger
perry at piermont.com
Fri Mar 9 11:00:49 EST 2007
Josh Sled <jsled at asynchronous.org> writes:
> On Thu, 2007-03-08 at 23:46 -0500, David Hampton wrote:
>> -l80 Line width of 80.
> This one I find problematic. I understand the arguments for it, and
> have made them myself. But identifiers and type names are just too long
> these days. An 80-char limit can cause frequent and unnatural
> line-breaking; I think 100-char limit is more realistic.
I'm just a lurker, so forgive me for commenting since I don't really
have a horse in the race, but my emacsen and xterms are 80 columns
wide. If you use 100 columns for code, it will be unreadable on my
displays. There are many, many people like me, and said code will be
unreadable on their displays as well. There are also those of who
sometimes actually print a section of code (SHOCKING, I know) to read
it in a nice large font, and for whom paper will not magically widen.
You can rail against how stupid this is, but it won't get you very far
with those of us who live this way. You can thus choose to make the
code unreadable by a large chunk of the developer community, or stick
to 80 columns.
As an aside, generally speaking, I think identifiers and type names
are no longer than they were in the early 1980s. I also think humans
are no smarter, so we can't deal with keeping larger blocks of code in
our heads at once than we could 25 years ago.
The biggest consideration in style choices is making sure as many
people as possible can read and understand your code, since the
original programmer is rarely the sole maintainer for long and since
after a couple of years the original programmer will have forgotten
everything he wrote anyway and will effectively be a "new
reader". That means keep functions small, keep code chunks small even
if the reader has a 25 inch monitor to read on because no matter how
large the monitor might be the reader's mind has not magically grown,
keep indentation shallow because deep means many nested levels of loop
and conditional to try to store in your limited memory at once. It
also means stick to 80 columns, both because it forces you to notice
that you're indenting too far and because it means as many people as
possible can read what you wrote without inconvenience.
More information about the gnucash-devel