January 29, 2012
I like the look of 8-space indents, but I don't see how I could pull it off if I use object-oriented features. I use 8-space indents if I code C, and it seems to work really well. But when you have a class, and then maybe even an inner class, you practically start with 2 levels of indentation, and that's where half your "page" (screen) is blank space!

What is a solution to this, apart from using 4-space indentation? To not indent class declarations is kinda one.
January 29, 2012
On 29 January 2012 23:30, Matej Nanut <matejnanut@gmail.com> wrote:
> I like the look of 8-space indents, but I don't see how I could pull it off if I use object-oriented features. I use 8-space indents if I code C, and it seems to work really well. But when you have a class, and then maybe even an inner class, you practically start with 2 levels of indentation, and that's where half your "page" (screen) is blank space!
>
> What is a solution to this, apart from using 4-space indentation? To not indent class declarations is kinda one.

The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.  :o)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
January 29, 2012
Le 30/01/2012 00:44, Iain Buclaw a écrit :
> On 29 January 2012 23:30, Matej Nanut<matejnanut@gmail.com>  wrote:
>> I like the look of 8-space indents, but I don't see how I could pull
>> it off if I use object-oriented features. I use 8-space indents if I
>> code C, and it seems to work really well. But when you have a class,
>> and then maybe even an inner class, you practically start with 2
>> levels of indentation, and that's where half your "page" (screen) is
>> blank space!
>>
>> What is a solution to this, apart from using 4-space indentation? To
>> not indent class declarations is kinda one.
>
> The answer to that is that if you need more than 3 levels of
> indentation, you're screwed anyway, and should fix your program.  :o)
>

Well, not to mention that this sentence first apply to C. Because if you apply that in some programming languages, you'll be screwed up pretty quickly (even in D even if it isn't the worse at this game).
January 30, 2012
On 01/30/12 00:03, Iain Buclaw wrote:
> 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.

http://delight.sourceforge.net/

I was going to suggest making the compiler enforce using black-on-white, instead of white-on-black, for all D soure code, but was afraid somebody would still not get it... :)


artur
January 30, 2012
On Sunday, January 29, 2012 23:44:25 Iain Buclaw wrote:
> On 29 January 2012 23:30, Matej Nanut <matejnanut@gmail.com> wrote:
> > I like the look of 8-space indents, but I don't see how I could pull it off if I use object-oriented features. I use 8-space indents if I code C, and it seems to work really well. But when you have a class, and then maybe even an inner class, you practically start with 2 levels of indentation, and that's where half your "page" (screen) is blank space!
> > 
> > What is a solution to this, apart from using 4-space indentation? To not indent class declarations is kinda one.
> 
> The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.  :o)

That doesn't hold for D. There are too many ways to legitimately end up with several levels of indentation. Templates, static ifs, version blocks, struct/class declarations, if/else, while, etc. 3 or 4 levels of indentation is not necessarily uncommon at all.

C has so few things that result in new blocks to indent, that the 3 levels of indentation rule has some merit there. But in OO languages (and especially in D with its additional conditional compilation features), that just doesn't fly.

- Jonathan M Davis
January 30, 2012
More practical than requiring all source files to be saved without formatting:

- Upon opening a file, the editor looks for a style sheet in the same directory. If there is no such style sheet, it automatically deduces the style from the code, falling back to the local preferences.

- Then it acts as you propose.

- And when saving, it automatically formats the source code in the deduced format.
January 30, 2012
On 1/29/2012 5:03 PM, Iain Buclaw wrote:
> 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.
>
>

There are huge swaths of unused unicode values, including a rather large chunk reserved for custom user-implementation.

Clearly we need to redesign the language to use custom symbols that make sense, instead of the archaic typesetting symbols we use now and have a unique set of programmer symbols.

We can even solve the space vs tab problem once and for all, by making a whitespace key and removing the obsolete buttons to make room for all the new ones (which would be tab, spacebar, and enter).

January 30, 2012
On 30/01/2012 01:13, Sean Cavanaugh wrote:
<snip>
> Clearly we need to redesign the language to use custom symbols that make sense, instead of
> the archaic typesetting symbols we use now and have a unique set of programmer symbols.

It's already been tried (APL).  OK, so maybe the "that make sense" aspect doesn't apply there.

> We can even solve the space vs tab problem once and for all, by making a whitespace key
> and removing the obsolete buttons to make room for all the new ones (which would be tab,
> spacebar, and enter).

Having to switch keyboards might have been another reason people hated APL.

Stewart.
January 30, 2012
On 29/01/2012 19:26, Marco Leise wrote:
<snip>
> Then again "tabs for indentation only" is a simple rule, that would have turned the tabs
> into spaces in this example - if editors supported it.

But when alignment spaces begin at the beginning of the line, or immediately after the indentation tabs, they can easily be mistaken by editors for indentation and changed to tabs.  It depends on how intelligent the software is.

void qwert(int yuiop, string asdfg, immutable(int)[] hjkl,
           Object zxcvb)

Here, the lines of parameters are aligned.  However, a naive editor might mistake the alignment spaces for indentation spaces and turn them into tabs.

void qwert(int yuiop, string asdfg, immutable(int)[] hjkl,
	Object zxcvb)

Here, there is a fixed indentation.

But one possibility for editors is to work on the principle that it's an indentation tab/run of spaces iff the syntactic structure ({}, control statements with a single statement as body, possibility [] used for array initialisers) dictates that there should be an indentation tab there.  While not perfect, it would still IMO be better than the current mess many editors are in.

Stewart.
January 30, 2012
On 1/29/2012 2:41 PM, Kagamin wrote:
> 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?

So far, I've seen no issues with standardizing on LF line endings.