无聊问下代码风格的事

• 資深大佬 : ooops

  尝试说服他们，超过两个建议换行。说服不了就按它们的来

• 資深大佬 : renmu

  我是写 py 的，列表选择 1，字典选择 2

• 資深大佬 : cmdOptionKana

  三个元素以内并且 80 个字符以内用 1，超过则用 2

• 資深大佬 : Chase2E

  风格 1 的是来搞笑的吗？。。

• 資深大佬 : zhanggang807

  我的风格(java)，超过 120 列(就是宽度)之后折行再接着行写，一直顶到头是不行的
  类似于这样的
  /**
  * All possible chars for representing a number as a String
  */
  final static char[] digits = {
  ‘0’ , ‘1’ , ‘2’ , ‘3’ , ‘4’ , ‘5’ ,
  ‘6’ , ‘7’ , ‘8’ , ‘9’ , ‘a’ , ‘b’ ,
  ‘c’ , ‘d’ , ‘e’ , ‘f’ , ‘g’ , ‘h’ ,
  ‘i’ , ‘j’ , ‘k’ , ‘l’ , ‘m’ , ‘n’ ,
  ‘o’ , ‘p’ , ‘q’ , ‘r’ , ‘s’ , ‘t’ ,
  ‘u’ , ‘v’ , ‘w’ , ‘x’ , ‘y’ , ‘z’
  };

• 資深大佬 : chenqh

  这个随便把，

• 資深大佬 : jfcherng

  幾乎都使用 2, 並且結尾必加逗號（ php-cs-fixer 自動加）

• 主 資深大佬 : moxuanyuan

  @chenqh 风格 2，我一目就看完所有内容，风格 1，我还要从左到右看一次才看得完。。

• 資深大佬 : Cuo

  风格 2, 读起来更方便.

• 資深大佬 : jowan

  如果团队没有要求 那就谁能说服谁就听谁的
  如果遵循了某种规范 比如 PSR-2 你这种情况就请选择 2
  可以参考那些遵循 PSR 的框架 看他们写的代码风格就行了
  你这种就跟 Laravel 的配置一样 比如 Model 里面的$fillable Http 里面的 Kernel

• 資深大佬 : eason1874

  短就 1，长就 2，图片里这么长我肯定 2

• 資深大佬 : xuyl

  我选择 2，但不用 array()，用[]

• 資深大佬 : fewok

  屏幕能显示完，为啥要换行呢？
  举个例子，换行的写法，来 10 个变量，还得滑屏才能看到后面，完全不直观

• 資深大佬 : Mogamigawa

  柯里化走起

• 資深大佬 : jdhao

  太长就需要换行，我选择 2

• 資深大佬 : rioshikelong121

  2

• 資深大佬 : hyy1995

  害，就这么点元素，爱咋写咋写了。。。如果里面几十个元素，你怎么写都丑

• 資深大佬 : imswing

  2

• 資深大佬 : stevenshuang

  数量不多 1，多的情况就是 2

• 資深大佬 : onfuns

  肯定是 2 了，git 规范也是这种，如果 1 再加个变量，那么 diff 的时候一眼看不出来，而 2 的话只变动了一行，可以明显的看出来。

• 資深大佬 : Dylaan

  2，[]

• 資深大佬 : xiangyuecn

  怎么好看怎么来，一行能解决又非常容易阅读的就没必要断成很多行，滚滚轮也是需要花力气的

  比如：
  if （短小绣花针）{
  code

  和

  if （短小绣花针）
  {
  code

  公司是按代码行数付工资吗

• 資深大佬 : tabris17

  简单，以后 KPI 以代码行数计算

• 資深大佬 : no1xsyzy

  关于代码风格，pick one instantly and keep it permanently

  我是总体倾向风格 2 的
  但如果 1. 内容不是特别多特别长的，并且 2. 不是列表而是元组，可以接受风格 1

  我解释下 2.，就是说这些字段间有某种内在联系，而不是单纯的枚举或者并列。
  比如构成一个字典用的键值（“`dctdata=dict(zip([…],lstdata))“` 中 […] 的部分可以在一行内没问题）
  或者是（迫于格林斯潘第十定律）需要写伪 Lisp 时 “`html=[‘html’, [‘body’, [‘h1’, ‘Hello World!’]]]“`
  或者描述某种顺序 “`[first, second, last]“`

• 資深大佬 : icylogic

  这有啥好操心的……统一定一个 format 的规范然后让 ide / pre-commit hook 负责这个就好了啊……

• 資深大佬 : no1xsyzy

  @onfuns git 友好需要最后也加逗号
  否则一个 branch 里改动最后一行内容，另一个 branch 里最后新增一行（原最后一行需要增加逗号）
  就可能 merge conflict。

• 資深大佬 : guanhui07

  三个元素以内并且 80 个字符以内用 1，超过则用 2

• 資深大佬 : yim7

  我喜欢 2，这样添加新元素很方便，直接换行

• 資深大佬 : no1xsyzy

  @icylogic 我跟你说，我给自己设计的规范是不能 lint 的……
  我在 Python 下，单双引号的使用完全区分，单引号表示 “符号”，双引号表示 “字符串”。自动化方案无法做到的这个分析的。

• 資深大佬 : mixure

  管好自己就成。

• 資深大佬 : kiritoxf

  我们是尽量一行，但是超过 120 后要换行。

• 資深大佬 : qiaoweizhen

  2，变量采用小驼峰，array 改成[]，数组最后元素加逗号。2 的原因主要是 git 增减某一个元素的时候很容易对比

• 資深大佬 : moyupoi

  肯定 2，除非懒了，不想维护的代码用 1，不过得多懒…

• 資深大佬 : moyupoi

  而且代码前面不要用 tab 直接空行，初学者才直接按 tab，学着用两个空格空行，看看代码规范，多看大神写的源码就知道该怎么做了

• 資深大佬 : hauzi

  [ ]

• 資深大佬 : avenger

  不要在风格上纠结浪费时间。php-cs-fixer 解千愁

• 資深大佬 : laravel

  当然是 2 了
  $arr = [
  “what”,
  “the”,
  “fuck”
  ];

  不用 golang 的风格，我浑身难受

• 資深大佬 : bnm965321

  用 black/prettier 之类的工具自动格式化，不要在这方面费劲了

• 資深大佬 : xh520630

  @moyupoi 认真的吗?
  PSR-2 :
  2.4. 缩进
  代码 必须 使用 4 个空格来进行缩进

  大神都是用 2 个空格???

• 資深大佬 : moyupoi

  @xh520630 指的就是 4 个

• 資深大佬 : loudefa

  风格 2 啊，还有你这 php 咋还用 array，不都是 [] 了么，没升级版本？

• 資深大佬 : Kisesy

  说真的如果按图中来看，我喜欢 1，因为我觉得横着看眼睛很舒服，如果是大量竖着的数据，我会

• 資深大佬 : lifesimple

  折中一下 每行三个 然后换行

• 資深大佬 : darksword21

  图片这么多肯定使用 2

• 主 資深大佬 : moxuanyuan

  @mixure 关键我有时候需要改他们的代码，这时候就很难受

• 主 資深大佬 : moxuanyuan

  @loudefa 习惯。。。

• 資深大佬 : ben1024

  用 phpcs 强制规范统一下，控制下自己手动格式化操作的欲望

• 資深大佬 : yolee

  编辑器限制 80 列，超出必须换行。

• 資深大佬 : bnm965321

  用 black/prettier 之类的工具自动格式化，不要在这方面费劲了

• 資深大佬 : d892fc

  宽度 80，超过 80 要换行

• 資深大佬 : shiran3f

  2。
  风格 1，我看见一次说一次

• 資深大佬 : linda102

  2

• 資深大佬 : leosirius666a

  太长换行不是常识吗

• 資深大佬 : chotow

  受不了下划线的变量，我要改成 otherFieldDeal ！

• 資深大佬 : chenliangngng

  我们是 5 那样的

• 資深大佬 : lemon6

  我用的 2

• 資深大佬 : Sapp

  @fewok 你的屏幕能显示完不代表别人就能， 比如你 1080p 的屏幕，给你一行是显示不少，但是视线是不是还要移动？ 这就还好，换一个用 13 寸 macbook 的人呢？ 他还要动滚动条才能看到

• 資深大佬 : icylogic

  @no1xsyzy

  1. 印象中单双引号这个大部分 formatter 不怎么管（ black 除外），一般 format 的时候会直接略过不处理（ as-is ），这个和你的风格并不冲突；
  但你主题中的这个问题大部分 formatter 都可以统一解决，一个 column 限制就够了

  2. 而且规范从来就不是用来约束某一个人，个人的代码风格和品味一直随着时间和能力改变，自己一个人写的项目从来不会有人关心是按着什么规范写的。
  但既然你们都在同一份代码上工作，你是这么用引号以及长列表的，你的同事呢？你如何保证同事这么用？如果你保证不了，你同事的代码也许全是单 /双引号甚至相反的使用习惯，那你们阅读彼此的代码时也会难受啊？同事哪天改你的代码改成人家自己的“个人规范”了，你们打一架吗……规范就是用来提前避免这些的啊。（比较激进的 black 全给你 format 成双引号了）

• 資深大佬 : zhyt1985

  风格 2，代码量是按照行数计算的

• 資深大佬 : zhyt1985

  用风格 1 的估计用的都是超宽的显示屏

• 資深大佬 : 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

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

• 資深大佬 : Sapp

  @fewok 强行杠，不用回复了，你这样的没法交流，七寸屏都说出来了，用 13 寸 macbook 的一大把，用 7 寸写代码的我从来没见过也没听过

• 資深大佬 : karnaugh

  ①单个的时候习惯用 2
  ②如果是多个的话字段少用 1 可以更整洁点
  ③但是如果字段多的话一格式化还是会变成 1。。。那就只能写完一按减号收起来眼不见心不烦
  举例：
  ①
  let user = {
  name: ‘111’,
  phone: ‘222’,
  age: ‘333’
  }

  ②
  let userList = [
  { name: ‘name1’, phone: ‘222’, age: ‘333’ },
  { name: ‘name2’, phone: ‘222’, age: ‘333’ },
  { name: ‘name3’, phone: ‘222’, age: ‘333’ },
  { name: ‘name4’, phone: ‘222’, age: ‘333’ }
  ]

• 資深大佬 : anytk

  2，对版本管理更友好一些，diff 更容易看出

• 資深大佬 : fewok

  @Sapp 接受不了反驳就别 @别人，随意定义他人言论，卖萌嘛？互拉黑吧。
  再说 7 寸问题，7 寸手机没有 13 寸 macbook 多？ 17 寸以上显示器没有 13 寸 macbook 多？
  手拿 13 寸 macbook，就要全世界照顾 13 寸，惯习惯了？

• 資深大佬 : SenXie

  我是写 python 的，用 black 格式化，格式化成啥样就是啥样，再也不用操心到底用啥格式了，反正没得选

• 資深大佬 : linxl

  当然是 2. PSR 规范.

• 資深大佬 : RickyC

  都认同. 因为都能看清
  我应该这么写
  $asda_faf_asd=[‘asda’,’asda’,’asdads’,’asdas’,’asdas’];