January 29, 2012
On Sun, Jan 29, 2012 at 05:33:39PM +0000, Russel Winder wrote:
> On Sun, 2012-01-29 at 09:17 -0500, bearophile wrote:
[...]
> > D2 style guide should *require* D2 to be edited using a mono-spaced font, and the D2 front-end should enforce this with a "-ms" compiler switch.
> 
> Surely this is a level of fascism too far (*).  Using monospace fonts is just so 1960s, the era of typewriters and 80x25 terminals.

I always code with tab stops set to 8 and line wrapping set to 80 columns.


> Personally I am living in an era where monitors deal with proportional fonts which every experiment done shows are easier to read.

*Text* is easier to read with proportional fonts. Code is not the same as text.


> Why do so many programmers hanker for the 1960s and the necessity of monospace fonts, it seems irrational.

I am irrational.

;-)


T

-- 
I am a consultant. My job is to make your job redundant. -- Mr Tom
January 29, 2012
On Sunday, January 29, 2012 14:27:29 H. S. Teoh wrote:
> On Sun, Jan 29, 2012 at 05:33:39PM +0000, Russel Winder wrote:
> > On Sun, 2012-01-29 at 09:17 -0500, bearophile wrote:
> [...]
> 
> > > D2 style guide should *require* D2 to be edited using a mono-spaced font, and the D2 front-end should enforce this with a "-ms" compiler switch.
> > 
> > Surely this is a level of fascism too far (*).  Using monospace fonts is just so 1960s, the era of typewriters and 80x25 terminals.
> 
> I always code with tab stops set to 8 and line wrapping set to 80 columns.

That's not going to work very well with D. You tend to get far too many levels of indentation for that to fly. With static if (and potentiall multiple layers of static if), classes, templates, etc. all on top of the normal if statements and while loops and the like, and it can very quickly reach 3 - 4 indentation levels on simple code, let alone what more complex code has. It's that much worse when you use much in the way of functional-style programming and chain function calls, since then not are the lines indented a fair ways, but they tend to get long. I suspect that you'll find 8 character tabs and 80 character columns to be a frustrating combination, but you can do whatever you want.

Phobos uses 4 character tabs with a soft limit of 80 characters (on average, a line should fit within 80 characters, but it doesn't have to) and a hard limit of 120 characters (a line should _never_ exceed 120 characters). And that seems to be working fairly well for us.

- Jonathan M Davis
January 29, 2012
On Sunday, 29 January 2012 at 20:53:51 UTC, Walter Bright wrote:
>   tolf

AFAIK, only windows notepad can't handle lf nowadays. That's it?
January 29, 2012
Walter:

> What? How could the compiler possibly know what font was used in your editor?

Sorry Walter, this time I wasn't serious :-)

Bye,
bearophile
January 29, 2012
On Sunday, 29 January 2012 at 22:25:57 UTC, H. S. Teoh wrote:
> *Text* is easier to read with proportional fonts. Code is not the same
> as text.

Tried many monospaced fonts, none is more readable than verdana.
January 29, 2012
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.
January 29, 2012
On 29 January 2012 14:17, bearophile <bearophileHUGS@lycos.com> wrote:
> Denis Shelomovskij:
>
>> Am I mistaken? If no, am I missing some major spaces advantages? If no, lets use tabs.
>
> D2 style guide should *require* D2 to be edited using a mono-spaced font, and the D2 front-end should enforce this with a "-ms" compiler switch.
>
> Bye,
> bearophile


I think D should go even further than that and drop those horrid curly braces, handling all code blocks by indentation.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
January 29, 2012
On Sun, Jan 29, 2012 at 02:32:48PM -0800, Jonathan M Davis wrote:
> On Sunday, January 29, 2012 14:27:29 H. S. Teoh wrote:
[...]
> > I always code with tab stops set to 8 and line wrapping set to 80 columns.
> 
> That's not going to work very well with D. You tend to get far too many levels of indentation for that to fly. With static if (and potentiall multiple layers of static if), classes, templates, etc. all on top of the normal if statements and while loops and the like, and it can very quickly reach 3 - 4 indentation levels on simple code, let alone what more complex code has. It's that much worse when you use much in the way of functional-style programming and chain function calls, since then not are the lines indented a fair ways, but they tend to get long. I suspect that you'll find 8 character tabs and 80 character columns to be a frustrating combination, but you can do whatever you want.

I used to use 2-space indentation for this very reason. I've written Perl code with 16 levels of nesting complete with chained maps{} and other such fun stuff.

But I've since changed my mind, and have come to believe that if a function requires more than 3-4 levels of nesting, there is a fundamental design problem with it, and it should be split into smaller functions. This also helps you refactor code more easily as well as give you a reason to think about how to better express what you're trying to do, instead of just going on auto-pilot and using 8 levels of nesting just because.

Optimizing compilers like gdc will auto-inline single-use functions anyway, so this shouldn't be a problem even on the premature optimization side. ;-)

Besides, one of the things I really love about D is closures... with careful use of closures, almost any code can be reduced to 3-4 indents at the most, usually only 2-3.


> Phobos uses 4 character tabs with a soft limit of 80 characters (on average, a line should fit within 80 characters, but it doesn't have to) and a hard limit of 120 characters (a line should _never_ exceed 120 characters). And that seems to be working fairly well for us.
[...]

Well, having worked in many different projects under different managers with different coding styles at my full-time jobs, I've come to accept that when writing code for a particular project, one should simply follow whatever conventions existing code in that project uses, however ugly it may seem. For my own projects, though, I use 8-space tabs and 80-column wrapping.


T

-- 
2+2=4. 2*2=4. 2^2=4. Therefore, +, *, and ^ are the same operation.
January 29, 2012
H. S. Teoh:

> 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,

It wasn't me.

Bye,
bearophile
January 29, 2012
On Sun, Jan 29, 2012 at 11:03:54PM +0000, Iain Buclaw wrote: [...]
> I think D should go even further than that and drop those horrid curly braces, handling all code blocks by indentation.
[...]

Yeah, that way D will have much less competition to succeed (only have
to beat Python instead of out-competing thousands of other languages).
;-)


T

-- 
One reason that few people are aware there are programs running the internet is that they never crash in any significant way: the free software underlying the internet is reliable to the point of invisibility. -- Glyn Moody, from the article "Giving it all away"