Re: My whitespace style

deeptech71@gmail.com wrote:
 > Oliver Fromme wrote:
 > > [...]
 > > That's another good reason to let the old ASCII tab die and
 > > rest in peace (or "lost in space" ...  ok, bad pun).
 > 
 > In this and other posts you only give reason to kill off the space, not 
 > the tab. If two things conflict, which is wrong is for me to decide, not 
 > you. :) Seriously, let's devise a reason why one should die.
 > 
 > Yes, it's hard to implement an editor which controls retarded mixes of 
 > tabs and spaces. But generally it's hard to implement an editor which 
 > controls retarded of any ASCII character. So let's only consider 
 > "well-formed" files. For such files, my whitespace style applies: if 
 > indentation is width-critical, use spaces, otherwise (like C source) use 
 > tabs precisely for indentation. What do you want from not well-formed files?

A space is a well-defined thing.  It behaves like any other
printing ASCII character (it is not a control character).

A tab character (ASCII 9) is not well defined.  Its behaviour
depends on the editor and its configuration, on the user's
preferences, on the terminal's capabilities, and so on.
What's worse, the behaviour of tabs can change in undesirable
ways when you move them from one environment to another.
For example, when you put source code with tabs on a web page,
it depends on the browser how it will be displayed, and it's
even possible that some browsers don't display the source code
correctly at all.  The same when sending source code through
e-mail or usenet news:  the appearance depends on the client.
Given the plethora of clients, chances are that some of them
will display the tabbed source code in incomprehensible ways.
That's not a bug in the clients, because there is no standard
for the correct rendering of tab characters.  And it get's
even worse when you try to copy&paste such source code, you
will often lose all tabs.

That's why I believe that the only control character that
should belong in source code is the line terminator.  Note
that even this is not really standardized:  There's the
newline character (line feed, ASCII 10), the carriage return
character (ASCII 13) and combinations thereof, and more.
But it's fairly simple to convert between those, there is
no ambiguity, and editors usually handle it very well.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch輎tsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M榀-
chen, HRB 125758,  Gesch輎tsf梶rer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"A misleading benchmark test can accomplish in minutes
what years of good engineering can never do." -- Dilbert (2009-03-02)
_______________________________________________
freebsd-chat@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-chat
To unsubscribe, send any mail to "freebsd-chat-unsubscribe@freebsd.org"