完全是不同的风格（太好区分了（233

不愧是学姐，对 indent layout 一把梭

如果我是解析器的作者，一定很头疼规范里允许这种多行参数列表

不过也不是没有道理，如果允许
someCall(1,
2,
3)
那才舒服了呢

函数式的风格，连 inline val 都没有。
纯纯的嵌套调用，求值顺序全赖语言内部参数求值策略

可惜这样的话每行代码的信息量是很低的……
而且再严格，lambda: 也是可以命名的

顺便提一句，这样不会 SQL 注入吗

为什么不用 ORM

只要能够让自己的意图结构化，那就结构化

只要能上到过程式编程，就别用汇编+宏
只要能用 OOP，就别用过程式里各种开销大的虚方法和约定俗成命名式“方法”

很早的时候，以前我写c的时候，推崇无论何时何地，任何环境，都能手写代码，这样写代码的能力才是你的能力，你才不是ide的搬运工

肯定啊，如果写 Haskell 在纸上也是够用的

两边都不能忘，程序猿要不止一门语言才好

这也是「戴着枷锁编程」的一种体现

规范化自己的定义，提升抽象层次。
从非结构化（汇编）到过程式（C,Basic） 就是一种提升

虽然能用的 hack 会越来越少，但程序的规范性、可维护性会越来越好

从手动管理内存到 GC/Rust 式 linear type system
虽然许多人反而感觉不自在或者纠结代码的“速度”
但程序也是越来越安全了

这里，最后一条是上文。

我不止是群员或“对线者”，同时也是回答问题的人

1. 无所谓，反正这种冲突导致的后果顶多是我以后会重视“消息是群管理的，不是我的”这一条了

以后我尽可能把自己重视的东西多转发，到自己的地界去。

2. 怎么样都可以，随你们看
不过我说的是 Telegram 平台上的文档

不多说了

1.我们尊重你写的文字,我们没有对所有群组试图采取相同的配置,所有的配置均可被更改,有配置问题可以联系群管理员2.文档在逐渐完善

现在起码有两个群在评论这个人

大家的观点出奇的一致