我想知道是否有任何其他C#开发人员会发现这是一个改进,让csc.exe
的编译器指令使空白显着变为Haskell或Python,其中各种空格创建代码块。
虽然这肯定会与C-style languages大相径庭,但在我看来,由于C#最终被编译为CIL(仍然会有大括号和分号),所以它真的只是编译器可以处理任何一种方式的解析技巧(也就是说,它可以处理重要的空格或不处理)。由于cur和分号通常是进入C#和& amp;它们实际上只是解析帮助程序(它们本身并没有赋予您的代码含义),它们可以通过Haskell / Python删除。
F#使用#light编译器指令处理此问题,您可以在 Lightweight syntax option in F# 1.1.12.3 中阅读该指令。
我希望在C#中看到相同的东西:#SigSpace或某些指令,它会指导csc.exe
像空格一样处理来源的Haskell文件(仅作为示例)。
标准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
}
}
}
重要的空白:
#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
我不是说我想在C#中使用它,但我对这些权衡是什么感兴趣。我的猜测是,大多数C#开发人员已经习惯了语法,以至于他们无法看到它是多么模仿(尽管它最终可能使代码更容易阅读)。
答案 0 :(得分:11)
如果您需要此语法,为什么不使用IronPython或Boo而不是C#?
为此实现自定义语言似乎更好,而不是尝试调整C#。正如你所说,它们都编译为同一个IL,所以没有理由改变一个好的,干净的工作语法来实现本质上是一种新的语言语法。
答案 1 :(得分:3)
作为一名主要的Python开发人员,我希望看到更多的语言采用重要的空白来划分块。
如果您搜索新闻组,您会发现很多关于C,C ++,C#,Java等开发人员的意见。我的感觉是,他们中的许多人都非常喜欢花括号。
混合风格会很痛苦。
我经常使用大括号语言,所以我可以看到双方
答案 2 :(得分:3)
您可能对Kirill Osenkov的论文Designing, implementing and integrating a structured C# code editor感兴趣。
根本的想法是,虽然大括号是定义的C#语言的一部分,但您的编辑器不必向您显示它们。 Osenkov为SharpDevelop实现了一个编辑器控件,它将支撑对表示为缩进,并使程序员更快地使用代码结构。跳转到链接文档中的第113页以查看一个很好的示例。
答案 3 :(得分:2)
没有。 Curlies消除了读者方面任何歧义的可能性。人类不区分不同类型的空白(我的意思是,只考虑一下 - “不同种类的空白”!)。人类,我的意思是我。这就是为什么我喜欢C#:)
有些语言背后有哲学,包含某些含糊不清的内容。 C#不是其中之一。
答案 4 :(得分:2)
我想不出更糟糕的事情!
特别是可以选择两者。每当你阅读别人的代码时,你必须熟悉两种符号来理解它,并且天堂禁止它们在两者之间切换 - 这真是一场噩梦!
它将消除所有的一致性,并导致许多开发人员喊出更多的WTFS。
然后是关于空白与括号的整个圣战 - 我甚至都不会评论。
答案 5 :(得分:1)
在我的整个职业生涯中一直是C#/ Java开发人员,看着带有重要空白的C#代码会让我疯狂。
如果您熟悉括号,它会使代码更具可读性,并且真正帮助您弄清楚代码在做什么。
答案 6 :(得分:0)
这不是C#,它将是一种不同的语言,如Iron Python。
答案 7 :(得分:0)
如果这是一个选项,我永远不会使用它。
具体来说,我喜欢Visual Studio解析花括号的方式,允许块折叠/展开,将花键放在花括号旁边突出显示相应的闭合/开口花括号。
人类可读性也是一个问题。它更容易区分单词之间的花括号而不是区分空白区域。
答案 8 :(得分:0)
我使用30多年前由我公司开发的编程语言。我们一直在讨论像这样的问题。任何改变,甚至是添加,都不仅会带来改进的机会,还会带来错误和误解的机会。
即使在最好的情况下,这也无法解决任何问题。您只是将一组任意代码块标识符与另一组进行交易,这会使任何增益无效(如果有任何新语法,甚至都没有建立)。
更有可能的是,你正在利用另一个众所周知的既定规则与另一个不太知名的规则进行权衡,从而引入错误和误解的可能性。即使只是将其添加为选项也会带来更大的错误机会,因为您现在可以使用2种语法来编写相同的代码,甚至可以让同一个开发团队使用。