Compare source code

[Tim Harig]

On 2010-11-04, Mark Wooding <mdw at distorted.org.uk> wrote:
> Tim Harig <usernet at ilthio.net> writes:
>
>> I use simple comments that are not effected by white space.  I don't
>> waste my time trying to make comments look artistic.  They are there
>> to convey information; not to look pretty.  I really detest having to
>> edit other peoples comment formatting where you have to re-align
>> everything if the length of any of comment lines change.
>
> I view source code as primarily a means of communication with human
> readers, and only secondarily as being machine readable.  I therefore
> think it's worth the effort to make source code readily legible, for
> example by making effective use of horizontal and vertical whitespace.
> A long time ago, I spent a little while studying graphic design, so I
> try to keep an eye on this sort of thing.

I agree that it should be clean, ledgible, and easy to parse; but, I can
that I can achieve this without making too many assumptions about
whitespace.  Think of it like the way HTML is *supposed* to work.  Ideally,
the web designer should stipulate the basic layout of the page; but,
details such as how wide the display is are better left to the browser to
figure out based on the actual conditions that it needs to display the
page.

> I'm interested in line length for two reasons: firstly, because I
> believe that there's an optimum line length for easy and rapid reading,
> which is probably a bit less than 80 columns; and secondly because I
> find that I make more effective use of the available space on my screen
> if I have several narrow columns rather than a few wide ones -- since
> most lines in source files are short, a wide column ends up being mostly
> empty on the right hand side, which is wasteful.

Don't get me wrong, I am not arguing against the eighty column stylistic
limit.  I totally agree with it within reason.

What I am arguing for is choice on how the code is displayed -- not how it
is actually written.  By using tabs, I can choose the trade-offs myself
when reading the code rather then being confined to how the writer made
their decision to view it.  Assuming that I have sufficient screen space,
I might choose a wider indent even though it might make the document wider
then 80 columns *when viewed*.  Other times, I may resign to view at the
shorter column width so that it fits in my window without side scrolling.
Either way, its my choice; and, when I am finished editing the file,
even if it exceeds 80 columns at my chosen column width, the file will
not exceed 80 columns, at the origional column width, in the actual
source as it is *written*.

Adjusting tab stops is merely for my viewing pleasure and it gives
everybody the choice to view it their way without effecting the code.  That
is why I prefer tabs.