Why?? (prog question)

[Oliver Fromme]

Polytropon <freebsd at edvax.de> wrote:
 > Oliver Fromme wrote:
 > > [...]
 > What's bad is when several styles are mixed, e. g.

Of course.  I don't think anyone disagrees with that.

 > > I assume that every modern editor can be configured that
 > > way.
 > 
 > Even "old fashioned" ones can, take the mcedit (Midnight Commander
 > Editor) and joe (Joe's own editor) into mind. I think even the
 > simple vi can.

Uhm.  I wouldn't call joe "old fashioned".  It has a long
history, but it's not older than, say, BSD.  Would you call
BSD old fashioned?

 > > No, that won't work.  In practice you will either have to
 > > adopt the original indentation style, or reformat the
 > > code.  Just changing the tab size in your editor will
 > > break many things.
 > 
 > Maybe I expressed in an unelegant way: When tabs are used,
 > you can set the tab width to your individual preferences.

Yes, you can, and it will break the appearance of many
files.  See the stdio.h example.

 > If spaces are used, you cannot do this anymore, you have to
 > live with the spaces ("corporate guideline").

You can easily convert <n> spaces to <m> spaces.  It's
trivial to do in sed or with a vi command, or whatever.
The effect is the same as changing the tab width on a
file that uses tabs (and it can also cause a mess).
So it's no worse and no better.

I have once written a small shell script that does a
somewhat better job:

http://www.secnetix.de/olli/scripts/reindent

For example, it can be used to change the indentation
on stdio.h from 8 to 4 without destroying the alignment
of comments and other things:

$ reindent 8 4 /usr/include/stdio.h | less

It doesn't matter whether the input uses tabs or spaces.
The output will always use spaces, but of course you can
pipe it through "unexpand -t4" or similar if you prefer.

 > My two examples above, joe and mcedit: Going forth and back
 > in indentation would require one keypress per space character,
 > in opposite to one keypress per tab (which equals one indentation
 > level).
 > 
 > But again, they don't count as serious editors, do they? :-)

I don't know mcedit, but joe _does_ support transparent
handling of indentation with spaces.  I use it all the
time.  I don't have to perform more keypresses if a
file uses spaces instead of tab characters.

In fact, I think that joe is no less (nor more) serious
than vi and emacs.

 > Well, joe was my first Linux and then FreeBSD editor, and it
 > got a lot of new features (such as code highlighting). If
 > you are familiar with TP / WS key codes (^KB ^KK ^KM ^KE
 > ^KX ^TZ and so forth), it's a real powerful editor.

Yes, it is, and the keyboard functions are fully
customizable.  My own ~/.joerc is 25 KByte, and it
doesn't have much in common anymore with the old
TP / WS editors.  Things have evolved.  :)

 > Finally, I'd like to add that I've not always been such
 > a "tabbing nazi". In KC-BASIC, my first programming language,
 > I didn't use indentation (allthough it was completely
 > possible)

Well, I didn't indent in Commodore-BASIC either (used
it on PET-2001, VIC-20, C64), but that language wasn't
very structured anyway.  It didn't even support real
functions or procedures, just "GOSUB" subroutines.
And of course, limited memory is an issue:  When you
have only 3.5 KB RAM (VIC-20), saving a few spaces
can make a huge difference.

Eventually a bought a 40 KB RAM extension for my VIC-20;
I had to spend 200 DM at that time (and that was after
it had gotten cheap).  Today, 1 GB RAM is about 10 Euro.
Ugh.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

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

"[...]  one observation we can make here is that Python makes
an excellent pseudocoding language, with the wonderful attribute
that it can actually be executed."  --  Bruce Eckel