无聊问下代码风格的事

[moxuanyuan]

公司连我在内 6 个码农。。。

5 个都是习惯风格 1。。。

只有我一个是风格 2。。

你们用哪种风格？

[qwertyzzz]

代码格式化下 看编辑器格式化成哪种

[akira]

风格 2， 太长的代码在服务器上面不好看 不好改

[THESDZ]

代码可读性考虑都是 2，反正编译完以后没区别

[miv]

风格二，第一种看起来麻烦，第二种一目了然

[cxh]

说服他们遵循 psr 规范，php-cs-fixer 格式检测，说服不了就按他们的来，哈哈哈

[oakland]

用自动化工具可以处理吧？ git 提交的时候自动格式化

[no1xsyzy]

@icylogic 我是说不能被 IDE 或 hook 自动化
我的规范是种合理且极端的情况。单双引号是两种基本可互换的词法结构，但我却要求其具有语义。这需要的是 Review，靠程序是做不到的，上那些所谓 “人工智能” 的 Review 更不行（至少 RNN 肯定不行）。
我提出这点用以例证：如果没有 Review，实际上所谓代码风格的存在就是幻象，松散的规定会导致 A. 风格有歧义，严格的规定会导致 B. 无法变通反而代码可读性更糟糕的情况。
而我对于 “不是列表而是元组” 也是语义上的要求。

详细地针对 1. 进行论述：
就算对 column 进行限制仍然导致 A. 风格有歧义，就像 #5 那样，仍然可能存在多个元素一行的情况 —— 不要说限制单行单元素，那样的话就是 B. 无法变通，比如使用一维表示二维数组，那样显然仍然按照二维方式书写更好；或者是分几类的，比如枚举 alphanumeric，一行数字一行小写字母一行大写字母，不然还需要做列表拼接或者 flat。

[no1xsyzy]

@icylogic BTW，我对于词法语法层面的 “代码规范” 是感到不自然的。
代码规范是为了阅读方便的，但现在大部分**编辑器**都有代码高亮功能的情况下，词法语法方面进行规范对可读性是没有帮助的。
还有一些 “规范” 竟然是为了 git 的方便。为了一个不完善的工具的方便！
我说的不完善不是使用者的 “抱怨”，也不是（王垠所说）创作者的 “改进方向”，更像是经济学家的 “历史的必然”。但因为历史的扭曲而继续扭曲不符合理性，很难想象这是所谓 “软件**工程**” 的一部分。

[a1562619919]

2，1 想看完整代码可能得滑鼠标太累

[cominghome]

短就 1，长就 2

[icylogic]

@no1xsyzy

我没理解错的话，你说的重点是，你对代码风格的要求，细到了现有大部分工具都无法完美解决的地步，这是事实。然后你实解决的方式就只能是靠你自己去人工 Review 了，如果你们团队就是全靠你来 Review，而且你有话语权和精力一直做这个事，我当然没有任何意见。

我只是给你提供一个大部分团队（就我所知）都能接受的方案，即达成一份所有人能接受的规范，然后用一套自动化工具达到 90%的代码风格（可读性）需求，然后所有人忘掉这件事去做开发。

我们也遇到过自动化工具不能完美解决所有需求的问题，一些不重要又难开发的需求我们就放弃了，剩下的需求我用一些 ast 库补完了工具来满足。我们做 Review 时的 checklist 排除了所有 formatter，linter，sanitizer 能查出来的项，重点放在接口，安全，性能，架构（对于大一点的改动）。

PS. 之前说 column 是因为所有 formatter 都会支持，有些工具是能提供更细的选项的，比如制定函数传参是不是换行，dict 定义能不能换行，以及对于用户需要自定义格式的 region 提供关闭 formatter 的功能（比如手写矩阵的时候）

[fewok]

@Sapp 换个反驳的例子吧，这两例子太好反驳了。
移动视线这种，又不是死鱼眼，转转眼球，即保持眼球湿润，还能活动颈椎，多赞。
再说 13 寸 macbook，万一有人用 7 寸显示器，13 寸 macbook 的人要不要照顾下 7 寸显示器的呢？

再举几个反驳 2 的例子。
1、拿着 20 年前的规范定义现在的显示器，1/5 宽度都用不到，剩下留着照镜子？
2、100 行完事的代码，非要拉出 500 ～ 600 行，按行数给钱？
3、一屏幕显示完的逻辑，非要滑几屏幕，太直观难以体现能力？

[dobelee]

这个长度决定就好。

[shuangyeying]

5 个码农三到五年工作经验，楼主可能一到两年经验，有这个疑问很正常。因为最近的 IDEA 一按快捷键就一行变多行，然后觉得不错也就默认认可了。可能我也不知道我说了什么。

[publicccc]

短地一行，长的选择样式 2。
楼主这个长度当然选择样式 2.

[no1xsyzy]

@icylogic 说来我已经忘了最初我想说什么了（说到底大概我只是想说下我的规范有多神奇）
这些能自动化的，确实不叫规范也不叫风格，也就是 format lint 还有更多更多 xxer 里的 xx
大概都能叫 convention 吧
（后面关于词法语法规范不自然，就是突然意识到了自己的感觉是啥）
主要还是 pick one and forget it

PS. 总感觉免不了出现图灵完备的换行与否要求，不过那都无关紧要了

[no1xsyzy]

我突然意识到结合看似不兼容的几种想法，我足以给出一个兼容的最终结论了
第零条，一切的格式、规范、风格、结构、形态…… 统称 “视觉表现”。它影响的是 “可读性”，因为执行起来没区别。
此处也不例外，编写者应当选择在阅读此段代码的过程中对于程序逻辑理解更清楚的一种。
那么核心在于，以何种 “视觉表现” 编写的话，逻辑是清晰的？
这设计到这一序列的内容物的清晰程度。
风格 1 将内容紧实到一行，它容易引起这一序列的 “整体感”。
风格 2 将内容分散到多行，它看上去更像是独立的个体，形成 “模块感”。

对于将数组看作一个整体的，会更倾向于第一种。
对于将数组看作个体的集合的，会更倾向于第二种。

人们常说，一本书是先越读越厚，然后越读越薄的 —— 对于代码风格应该也一样，逐渐倾向第二种，然后再重新倾向第一种。

实际上，我最近对同一个事物建了三次模正好类似 1、2、1 的形态…… 但第一个 1 和最后一个 1 是不同的。
前者是粗略粗糙；后者是精炼简洁。
前者是对其组成的不理解，只得以整体考虑；后者是已经清楚明晰，不必单独考虑。

[redbuck]

装个代码格式化工具吧，纠结这种没有意义。

还有加不加分号，tab 还是空格缩进，4 个空格还是 2 个空格，争这个真是浪费生命，早点下班不好？

[shifttacn]

这个还好，不过我一般是风格 2，还要配上相同格式的备注。。。。
最不能忍的是极简代码，能省则省，可读性可维护性都特别差。也不知道在秀什么优越感

[kooze]

你都说是“风格”了，无所谓好坏。风格问题。