indent style for D

[H. S. Teoh]

On Sun, Jan 29, 2012 at 12:36:18PM +0100, Trass3r wrote:
> >http://www.d-programming-language.org/dstyle.html in regard to
> >indent-style, can someone shed some light what is recommended
> >practice for it within D community?
> 
> Everyone thinks his way is the best.

You know, I'm starting to take seriously bearophile's (I think it was
him?) half-joking proposal that all code must be written on a single
line, and whatever editor/IDE/what-have-you that you use to code will
pretty-print everything for you. That way, everyone will see the code in
their own favorite style, and nobody will have pointless flamewars over
this subject ever again (thereby giving more time for more important
things, such as vim vs. emacs flamewars :P).

I mean, if you think about it, at the most fundamental level, whether
you use spaces or tabs or what-not, it's all *visual formatting* done in
a format that's essentially conveying *semantic information* to the
compiler. It's just like the <font> tag in HTML (that we finally got rid
of after years of pain).

And let's face it. A space character is intended to represent an
inter-word space. It's not supposed to represent *indentation*. That
privilege is reserved for the tab character. But unfortunately there is
no consensus on how wide a tab is supposed to be.

But all of this is missing the point. Code is essentially a
tree-structured thing, consisting of nested blocks. Why should we use
ill-suited representations as tabs and spaces for nesting blocks? There
should be a dedicated code-editor (or vim/emacs mode, or IDE
configuration, or whatever), that parses the damn code and displays the
nesting structure in whatever way the user wants to see it. Whether you
want to see your blocks like this:

	if (a < b) {
		a = b;
	} else {
		b = a;
	}

or

	if (a < b)
	{
		a = b;
	}
	else
	{
		b = a;
	}

or even

	if (a < b) { a = b; } else { b = a }

or worse:

	if (a < b) {
		a = b;
		}
	else {
		b = a;
		}

(I kid you not, I know at least one person who actually writes code like
that) ... really shouldn't require painful reformatting of the entire
source code.  You should be able to load a "style sheet" into your
editor that automatically parses the code and pretty-prints (or
ugly-prints) it in your favorite style.

And not only so, when you type, it automatically formats blocks for you
with no further effort. You type "if(a<b){" and it automatically inserts
newlines and indents, AND if you hit backspace, it doesn't "erase the
tab character" or such nonsense; it removes the current block and moves
your cursor back to the end of the "if(a<b)" line.  Plus, it
automatically inserts spaces after the "if" and around the "<" if your
stylesheet specifies so. IOW, you should be able to type your code with
absolutely no spaces except where necessary to separate tokens, and the
editor should format it appropriately.  It should be *impossible* to do
any manual formatting whatsoever. The editor should take full
responsibility for that.

AND if you send your code to somebody else, they will always see it in
their own favorite style.

Furthermore, moving formatting to the editor will FINALLY let you handle
side-by-side comments in a sane way. The editor can display code in two
columns, one for code, and one for comments associated with each line of
code. You can collapse/expand comments as necessary, or change the
widths of the columns, and the editor automatically positions everything
correctly (including line-wrapping and paragraph formatting for long
comments). The editor takes full responsibility for how to represent
comments in the file.

There will be dedicated keys for moving between code/comment columns, so
that you can edit code freely and have the associated comments
automatically flow around it.


T

-- 
"Uhh, I'm still not here." -- KD, while "away" on ICQ.