tags:

views:

382

answers:

9

I'm wondering if any other C# developers would find it an improvement to have a complier directive for CSC to make whitespace significant ala Haskell or Python where the kinds of whitespace creates code blocks.

While this would certainly be a massive departure from c-style languages, it seems to me that since C# is ultimately being compiled down to IL (which would still have the curly braces and semicolons), it really is just a parsing trick the compiler can handle either way (i.e. it can either deal with significant whitespaces or not). Since curlies and semicolons are often a barrier to entry to C# & they are really only parsing helpers (they don't in themselves impart meaning to your code) they could be removed ala Haskell/Python.

F# handles with the the #light complier directive which you can read about here: http://blogs.msdn.com/dsyme/archive/2006/08/24/715626.aspx

I'd like to see the same thing in C#: a #SigSpace or somesuch directive that would direct CSC to treat the source like a Haskell file in terms of whitespace (just as an example).

standard C#:

public void WhiteSpaceSig()
    {
        List<string> names = new List<string>();
        List<string> colors = new List<string>();

        foreach (string name in names)
        {
            foreach (string color in colors)
            {
                // bla bla bla
            }
        }
    }

significant whitespace:

#SigSpace

    public void WhiteSpaceSig()

        List<string> names = new List<string>()
        List<string> colors = new List<string>()

        foreach (string name in names)
            foreach (string color in colors)
                // bla bla bla

I'm not saying that I want this in C#, but I am interested in what the tradeoffs are. My guess is that most C# developers have gotten so used to the syntax that they won't be able to see how artificial it is (though it may in the end make the code easier to read).

+3  A: 

No. Curlies remove any possibility of ambiguity on the part of the reader. Humans don't distinguish well between different kinds of whitespace (I mean, just think about that - "different kinds of whitespace"!). And by humans, I mean me. Which is why I like c# :)

Some languages have philosophies behind them that embrace some kinds of ambiguity. c# is not one of them.

Rex M
I don't know of any Python developers that use different kinds of whitespace. Do you? I think this is an imaginary problem.
gnibbler
@gnibbler tabs, spaces and line breaks are all whitespace
Rex M
@Rex, you have trouble telling spaces and newlines apart?
gnibbler
@gnibbler I don't like to have different meanings to them. Separation is separation to me. Let's have a fight over it! :)
Rex M
@Rex, I have nothing against curly braces - see my answer here, I just don't understand why people feel so strongly that they *must* have them. I'd sooner choose a language to better suited to the problem I am solving. Syntax is secondary to symantics for me
gnibbler
@gnibbler I think you're taking this post too seriously mate. An absolutist position *and* a smiley face in a discussion about the relative merits of *whitespace*. I like gouda cheese better than blue. Don't read too much into it.
Rex M
A: 

That would not be C#, it would be a different language like Iron Python.

Dour High Arch
You are confusing syntax with symantics.
gnibbler
No, he's not - syntax is a large part of what makes a language.
Pavel Minaev
+10  A: 

If you want this syntax, why not just use IronPython or Boo instead of C#?

It seems better to implement a custom language for this, instead of trying to tweak C#. As you said, they all compile to the same IL, so there's no reason to change a good, clean working syntax to implement what would essentially be a new language grammar.

Reed Copsey
+1  A: 

If this was an option, I would never use it.

Specifically, I like the way Visual Studio parses the curly braces allowing for block collapse/expand, placing the caret next to a curly brace highlights the corresponding closing/opening curly brace.

Human readability is also an issue. Its easier to distinguish curly braces between words than it is to distinguish white space.

Baddie
+2  A: 

Having been a C#/Java developer my entire career, looking at C# code with significant whitespace would drive me nuts.

If you're familiar with brackets, it makes code MUCH more read-able and really helps you figure out what the code is doing.

Justin Niessner
A: 

As a mainly Python developer, I would love to see more languages adopting significant whitespace for delimiting blocks.

If you search the newsgroups, you will find plenty of opinions of C,C++,C#,Java and so on developers. My feeling is that many of them really like the curly braces.

Having a mixture of styles would be a pain though.

I regularly use curly brace languages too, so I can see both sides

gnibbler
You would, and I would not. I find it annoying, seems highly subjective,.
Ed Swangren
+3  A: 

I can't think of anything worse!

Especially having the option of the two. Every time you were reading someone else's code you'd have to be familiar with both notations to make sense of it, and heaven forbid they should switch between the two - what a nightmare!

It would remove all consistency, and lead to many developers shouting many more WTFS.

Then there's the whole holy war on whitespace vs brackets - which I won't even comment on.

Lee
+2  A: 

You might be interested in Kirill Osenkov's thesis, Designing, implementing and integrating a structured C# code editor.

The underlying idea is that while the braces are part of the C# language as defined, your editor doesn't have to show them to you. Osenkov implemented an editor control for SharpDevelop that represents brace pairs as indentation, and makes it faster for the programmer to work with the structure of the code. Jump to page 113 in the linked document to see a good example.

Iceman
A: 

I work on a programming language developed by my company 30+ years ago. We are constantly haggling with questions like this. Any change, or even addition, introduces not just a chance for improvement, but also a chance for errors and misunderstandings.

Even in the best case scenario, this doesn't solve any problem. You're just trading one arbitrary set of code block identifiers with another, which nullifies any gains (if there were any with the new syntax, which isn't even established).

Much more likely, you are trading off a well-known well-established set of rules with another, not so well-known one, introducing the chances of errors and misconceptions. Even just adding this as an option introduces a greater chance of errors since you could now have 2 syntaxes to write the same code and possibly even for the same team of developers to work with.

Dennis