我十分希望 coffee 能出个非缩进带 end 的版本！

额 -_-|||

可以直接用 python

就不要在这种细枝末节的地方折腾了。。。

#1 楼 @huobazi ＋10086，顺便 Fuck Haml，恨死这玩意了

我觉得强制缩进是最让人囧的事情了。为了易读性，可以提倡缩进，但是靠缩进来表示逻辑，这有点。。。

强制缩进真心不习惯

感觉 haml 还挺好的，用的还挺爽的

- -。个人不怎么喜欢强制缩进的编程语言，但对于 sass,haml 之类的无所谓

缩进是多么反人类的事情。。。 有些 lib 在 coffee 下就不得不写成类似

$('#banner-slides').slidesjs(
  {
  width: 710
  height: 353
  navigation:
    {
    active: false
    }
  pagination:
    {
    active: true
    }
  play:
    {
    active: false
    effect: "slide"
    interval: 5000
    auto: true
    swap: false
    }
  }
)

黑细长，可读性真的不一定有提升，还有像写回调函数的时候，很容易失误缩进错，而且这种问题报的错误都很抽象，不好定位

#10 楼 @jasl 花括号可以全去了。

#11 楼 @Rei 是的，强制缩进最大的价值就是用格式简化了语义，这个是有意义的。 看看 lisp 就知道，括号之所以很多，是因为没有换行作为语义。而有了缩进语义，我们就可以简化作用域关键字了

#11 楼 @Rei 去掉就更容易因为缩进产生歧义了...像我贴的那段不注意看很不好分清到底是个 json 还是一串实参...

$('#banner-slides').slidesjs(
  width: 710
  height: 353
  navigation:
    active: false
  pagination:
    active: true
  play:
    active: false
    effect: "slide"
    interval: 5000
    auto: true
    swap: false
)

我看着没问题啊，而且即使用花括号也是这样排版

$('#banner-slides').slidesjs({
  width: 710
  height: 353
  navigation: {
    active: false
  }
  pagination: {
    active: true
  }
  play: {
    active: false
    effect: "slide"
    interval: 5000
    auto: true
    swap: false
  }
})

Lua 同样坑 end 和缩进：

function a(x)
return x + 1
end

print(a(3))

找到过一个无 end 的 Ruby 版本，不是原生，编译过程挺烦的 https://rubygems.org/gems/endlessruby 超想有个强制缩进的版本，括号和缩进造成语义重复，不应该强制人重复

#6 楼 @serco 心情几乎一样，但我是觉得逼人写跨行的括号让我有种受迫的感觉 写了一大串我认为括号不好的理由 https://github.com/jiyinyiyong/cirru-eval/issues/3

#10 楼 @jasl 换过来因为习惯了缩进，我对于括号的感觉也类似.. 括号超容易出错.. 关于缩进错误，我觉得是缩进线提示不够明确导致的.. 而括号编辑器已经做了提示

#17 楼 @jiyinyiyong 所以像缩进这种很看习惯的事情，语言不应该强制开发者如何如何的....像刚才我举得那个例子 我就是有强迫症看着不爽，但反过来@Rei 觉得可以接受，这种事情是好是坏真的说不清楚的

#15 楼 @jiyinyiyong 居然真有无 end 版，哈哈

#18 楼 @jasl 而且开发环境和编辑器的差异也让问题更复杂 不过对于纯文本编辑来说，我是坚持减少跨行括号是很重要的

#19 楼 @veggie 我找了好久的 只是没法说完美。毕竟 Ruby 就是 Ruby,

Should I be able to stand whitespace-sensitive languages I might as well go learn [whitespace](http://en.wikipedia.org/wiki/Whitespace_programming_language\)()

#22 楼 @blacktulip 2333，这个凶残 - -。

#20 楼 @jiyinyiyong 编辑器和开发环境差异。。。这不就是在吐槽强制缩进么...配置不当的编辑器怎么区分 tab 和空格...用括号就没这个问题

写惯了 slim，真有这种感觉。。。

回归 ERB 和 SCSS 了 :D

#24 楼 @jasl 呃.. 用空格就不会有问题啊.. 说起来代码里用 Tab 越来越难理解了 我的意思是，我使用编辑器的，别人可能要用 IDE, 那 IDE 来说括号自动排版方便多了

#22 楼 @blacktulip 混用 Tab 和空格的下场..

#28 楼 @jiyinyiyong 制表和空格在没有充分配置的环境下很容易混淆，然后就会产生问题，毕竟制表和空格都是语言允许的缩进方式，但是混用就有可能有问题，这个是缩进语言的硬伤啊，都强制开发者缩进了。。再强制编辑器如何配置，就有点。。引用个刚学的词“BDFL” “仁慈的”终生大独裁者

#29 楼 @jasl 正如喜欢括号的人有自己关闭括号的方式，用缩进的也是 制表符在 Github, Sublime Text, Vim 可能各有不同的宽度，我们都尽量杜绝的 因此两个空格缩进是非常习惯的做法. 至少对我来说，缩进就是一种语义，破坏语义就跟故意少写括号一个性质 代码对于程序员要易于维护，对于机器要严谨。用了括号就乱写缩进我想本身就存在问题

#30 楼 @jiyinyiyong 谁说两个空格缩进是非常习惯的作法的...看看Python coding style先，虽然空格缩进用的最多，但是用 tab 同样多，而且明确指出了混合用就是坑，以至于解释器要花费精力解决这个问题 另外即使使用空格缩进，Python 也提倡 4 空格，而不是两个，你的习惯可不是国际惯例 你说制表符的宽度不同，但是实际表达的意义却是相同的，从文本上都是‘\t'，而你用四空格还是两空格可在文本上的意义就不同了，这对计算机来说可不是严谨

另外 再进一步扯一句，根据王垠的文章所述，Python 分析缩进花了词法分析器大量的精力，这对机器可是额外的负担，而用句尾用分号断句的语言在这方便又有先天的优势

Ruby 的 do...end Basic 的 begin...end 还有 c-style 的{}还有 lisp 的 () 都有自己的问题，缩进也一样，这只是一个个人品味问题，事实上，我也可以说出其他风格的不是来，但我觉得意义不大，没有讨论的必要

#30 楼 @jiyinyiyong 而且默认设置下，制表符默认就等同于 4 个 tab 的宽度，任何编辑器都一样，没有可能一说 用了括号同样也要有缩进，没有合理缩进的程序员不应该作为同事存在 不举 coffee 的例子了，我对 coffee 有些误解，刚才写了一些代码，了解了，但仍然有槽点

$('#banner-slides').slidesjs(
  width: 710
  height: 353
  navigation: active: false
  pagination: active: true
  play:
    active: false
    effect: "slide"
    interval: 5000
    auto: true
    swap: false
)

如果不慎插入一个逗号呢？这种失误是有可能的，缩进同样一致，但是表达的含义变了，而且有可能不报形参数量不同的错误，而使用大括号就能避免这种错误发生

#32 楼 @jasl 嗯，Python 4 空格，2 空格在 coffee 也只是推荐，没有标准 我没有可以遵循的法则来比较两者优劣，所以很大程度是自己使用当中的考量 缩进的符号用对了计算机都是能理处的.. 我不想多讨论计算机处理这个是否严谨，跳过 :P

词法分析不懂.. 因为网上简单的解析器都不支持缩进，导致我现在到没学会，, 有路过的高人讲解一下么，Python 真的性能消耗在缩进的处理上？ 实现缩进的语言不止 Python, 解析缩进很难么..?

不好意思代码我之前理解错了.. 这个写法我也觉得容易混淆，, 如果是我习惯这样写：

options =
  width: 710
  height: 353
  navigation: { active: false } # 避免混淆
  pagination:
    active: true # 或者这样, 不过不打算两种混用
  play:
    active: false
    effect: "slide"
    interval: 5000
    auto: true
    swap: false

$('#banner-slides').slidesjs options # coffee 参数部分像 Ruby 容易花, 简化

#33 楼 @jiyinyiyong 这事得召唤 @luikore

#33 楼 @jiyinyiyong #34 楼 @jasl

缩进处理对性能一点影响都没有，更何况第一次跑完就生成 pyc 了不用处理缩进了

coffee 里不慎多插了逗号也不会造成错误... 不合法的写法编译期会给你提示的 如果用 js, 最后一项多了逗号就会导致 ie 7 挂掉...

#35 楼 @luikore 真绕三！

#36 楼 @jasl ...我语言组织能力不好...

coffee 就是习惯后就不再担心这类事情了...

#37 楼 @luikore 我还一直在犹豫要不要 @ 楼上，, 讲得好细

..不过 lz 为啥不直接 python。。

#39 楼 @jjym 先入了 ruby on rails，一切都习惯了，目前真没觉得有必要再上 python，可能未来需要处理非 python 不可的任务时也会试试吧

end 和两个缩进看得我蛋疼 Ruby 集优美的语法和看来像一坨屎一样的代码于一身 python 的代码看起来就优雅多了

#41 楼 @2forVendetta end 有 end 的好处，松本有论述为什么选择 end 而不选择强制缩进。你无非不习惯而已。。。在我不习惯 python 的眼里，python 感觉也很屎。刚开始学 js 的时候满眼的大括号，还真是头疼死我了。习惯了就都好了。

#42 楼 @mingyuan0715 讲解一下 Matz 怎么说的不？看看能不能说通我们转投 end :P

#43 楼 @jiyinyiyong

http://www.ruby-forum.com/topic/108457

http://www.haskell.org/haskellwiki/Wadlers_Law

if indent:  #{
    # I am not joking
#}

入乡随俗，别在意那么多(:з」∠)

#44 楼 @blacktulip 英语好难懂... 虽然摘了一遍

1

Python style block by indentation is an interesting idea, but it works badly with

• tab/space mixture
• templates, e.g. eRuby
• expression with code chunk, e.g lambdas and blocks

So I'd rather be conservative here.

2

Note that the Haskell folks have managed to evolve a language in which python-like spacing can be used to mark the extent of discrete code chunks, but so can traditional braces.

I admit Haskell syntax is much better than Python's. But I am not yet sure if it can be applied to Ruby.

3

imho: indentation should not define semantic;

Agreed.

suggestion: make 'end' optional if code block contains only one statement;

I'm not sure if we can define syntax for above suggestion.

while cond
   puts a
puts b     # delimit by indentation or else??

or maybe

while cond: puts a  # should be in same line

4

I admit Haskell syntax is much better than Python's.

Matz, you must be joking... Python is much easier to read than Haskell.

To rephrase, "Haskell INDENTATION SYNTAX is much better than Python's". Clear?

5

What do you think about OPTIONAL block indendation in Ruby?

I am not positive for general block-by-indentation idea. If one REALLY loves the idea, Python always waits for you.

But I sometime want "end"-less single line structure (in normal order), e.g.

if foo then bar  # pseudo syntax; you may require delimiters

not

bar if foo

especially when I write very small code chunk. Not knowing what syntax it should be.

6

imho: we need special terminator anyway, now it is 'end', could be another; suggestion: introduce ';;' terminator for 'implicit blocks (not started with class/module/def/do/begin), ie:

For your information, 1.9 once had exact same syntax you've proposed for a short while. I have a time machine. The idea was abandoned since it caused serious unreadability.