Significant whitespace in C# like Python or Haskell? [closed]
I'm wondering if any other C# developers would find it an improvement to have a compiler directive for csc.exe
to make whitespace significant a la Haskell or Python where the kinds of whitespace create 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 CIL (which would still have the curly braces and semicolons), it really is just a parsing trick the compiler can handle either way (that is, 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 a la Haskell/Python.
F# handles this with the #light compiler directive which you can read about in Lightweight syntax option in F# 1.1.12.3.
I'd like to see the same thing in C#: a #SigSpace or somesuch directive that would direct csc.exe
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)
开发者_如何学C {
// 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).
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.
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.
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
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.
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.
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.
That would not be C#, it would be a different language like Iron Python.
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.
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.
精彩评论