新公司，代码审查的时候 leader 修改了一些我个人觉得真的没必要的地方

[fyxtc]

for k, v in pairs(icons) do （一些调用） end

for 里几行代码，然后把 v 改成了 item。。。。改成 icon 我也服气一点啊。。。（这里的 kv 真的是习惯了，如果是 python 的话我就会写 for icon in icons:）

一个初始化图片 uri 的方法名：initSkinImage => initSkin.......

随机显示一些按钮的文本方法名：randSelectLabel => randomOptions

一些变量名： GROUP_INDEX = "group_index" => GROUP_INDEX = "gi" USER_STATUS_DATA = ” user_status_data" => USER_STATUS_DATA = "u_sd"

一个调用我是拆开的 a.do1() a.do2() => a.do1().do2()

更新用户状态方法名 updateUserRes => updateUserResponse

最不能忍的是这个。 image.setVisible(true) => image.show()

show 的内部实现就是调用 setVisible,两个方法都是框架自带的 照这种改法，现有代码里的所有 setVisible 调用处都该改了

其他有些地方是命名是修改得好的，比如 title => titles, enterStartView => enterReadyView

但是像上面那些的真的有点不太能接受。。。唉

补充一句，好多人说风格问题，可是我真的除了那个 res 的缩写之外（这个是我的错，就算缩写也应该是 resp ），其他的修改完全看不到有任何属于能被风格所定义的修改范畴啊！ 又不是什么驼峰大括号 abc 这样的。。。希望你们能先好好看看修改的部分可以吗。。。

谢谢大家的回复，可能是一周内我这个小模块需求就添加了三次（注意是添加），本身自己就算是挺用心的在重构了，所以这些小问题的修改确实影响到了一点自己的情绪。大家说的话我也都看了，我也会选择适合自己的解决方法，谢谢大家

最后一条附言
首先反驳一下那些说 show 比 setVisible 好的，考虑一下要通过某个数据状态来更新显示显示状态的情况
setVisible(isFin)还是 if isFin then show() else hide() end
就知道为什么我习惯写 setVisble 了。没有说 show 不好，只不过 setVisble 也没有不好，所有改动没必要

最后：leader 很好，很 nice，对事不对人，我个人观点依然觉得那几处（除了 res ）之外依旧是无关紧要，我也认为 review 是很好的，但是我更偏向看到一些代码性的修改：比如修改了某个算法，提高了性能，或者修复了某些隐藏 bug 之类的。而不是在已有代码就存在我被修改的调用（刚搜了下 setVisible: 204 matches across 56 files)和一些冗余的使用 temp 而不是用 a,b = b, a 交换的情况下。这样显得修改建议并没有那么有说服力，反而有点画蛇添足？

最后的最后，大家周末愉快~ 明天约妹子看电影了，紧脏。。。。

[yippees]

据说一般喜欢抓考勤卫生什么的领导都不能算多好的··
这种检查法不知道几个人一天代码输出有多少
难道是传说中一天 20 行？

[widewing]

又不用你花力气，改了就改了呗，可能 leader 觉得这样比较合规一点吧

[sylar1015]

形式主义，实施简单
不用思考如何把人力利用在有用的事情上

[fyxtc]

@yippees leader 人还是不错的，就是在代码命名上有点过于较真了，缩写也要被说一顿：为什么要缩写
我：...... 而且命名风格上不可能做到完全统一的，我个人觉得只要做到表达出了方法的目的，然后阅读代码的人没有太多障碍 就可以了。。。唉 而且这还是在一周之内提了三次新需求之后我自己已经重构了几次了，还要这样改我的代码命名，心态真的有点崩

[liyer]

一个 leader 带 10 人团队
是让 leader1 人去适应 10 人的不同风格
还是让 10 人统一到 leader1 人的风格

[leaves615]

5 楼点到位。

[AMOC]

姑且认为这个 leader 是个强迫症，而你是新去的，他就直接改了。

那么问题来了，这 leader 别的方面呢？是全方位完美主义者，还是只改这似乎无伤大雅的东西？

[AMOC]

@liyer
一个 leader 带 10 人团队
是让 leader1 人去适应 10 人的不同风格
还是让 10 人统一到 leader1 人的风格
---------------

+1

[yanaraika]

可能前几次 code review 比较严格。之后就不怎么管了

[fyxtc]

@widewing 我可能对自己的代码还是比较看重的吧，也比较在意别人随意动我的代码，如果是写得不好，或者有问题，那当然没话说。关键是，这种类似的问题，原代码就存在，原代码里我还看到了一个冗余的 temp 交换值，直接 a,b = b, a 不就好了。唉。。。算了

[yadgen]

我觉得很多人都有这样的强迫症吧，觉得是好的可以吸收，不好的可以提出来，不被采纳可以避而不见。

[fcten]

假如我接手代码，看到 updateUserRes，我会以为是 updateUserResource。
并不是说缩写不好，而是必须有统一的代码规范。
所以，统一命名风格并不是无关紧要的事情，除非你写的代码是一次性的。

[fds]

羡慕有代码审核的 ;p

[AMOC]

@fcten 多 nice 的 leader 啊，你去看看隔壁的 [孙岩] ，2333333333333

[fyxtc]

@liyer 你说的点我理解。首先一些函数的命名本来就存在主观的理解，initSkinImage => initSkin 和 randSelectLabel => randomOptions 能说后者的命名风格和前者存在什么区别吗？ 而且首先代码里就存在的大量的同义调用，比如 setVisble(true)而不是 show，也存在大量的可链式调用的非链式调用。我个人觉得这两个点完全不存在风格问题，不属于风格定义的范畴，而是特意去注意：诶，这个可以这样。

[smilenceX]

一个语言一般都有自己的命名风格，还是统一一下比较好
一般来说 k,v 这种没毛病，但我还没见过哪个语言的 [变量]名全部大写字母，难道不是常量才这么用吗？
image.setVisible(true) => image.show() 这个问题，我觉得一个框架没有理由单独把另一个函数调用这一行代码封起来，仅仅是为了改个名字。要么是其中一个函数被标记为 obsolete，要么是为了实现某个接口，建议了解一下

我觉得你们 leader 不应该自己改，而是要找你们讨论一下这个事。

[fyxtc]

@fcten 嗯，这个是我写的不好，按理说缩写也应该是 resp

[fyxtc]

@smilenceX 不是改名字，是增加一个选择，增加了可以链式调用的方式（ ps:我的例子里不需要链式

function Node:show()
self:setVisible(true)
return self
end

[fyxtc]

@smilenceX 那个是常量，我打错了，不好意思
@yadgen 老哥你说的对，很受用，谢谢

[wangxn]

我也不喜欢缩写。rand、res 这些也省不了多少字符，徒增理解成本。

[acidsweet]

代码是给机器运行，但是却是给人读的

[likuku]

@fyxtc 缩写...容易歧义。“随机”，你用了缩写 rand，但这个也是 “渲染” 的意思，被改为 random 很合理。

[felinx]

是他直接改你代码还是要求按这个改？

如果是前者，那么他不会做 leader 得在学几年怎么当 leader，如果是后者，只不过是统一内部习惯而已，没有很严格意义的对错好坏，适应下就好。

[blankme]

@likuku
渲染是 render

[epkT6QJ3RSaz6AnJ]

5 楼+1

[fyxtc]

@acidsweet 除了 res 那个确实是我的问题，其他的我并不觉得会让人觉得不好读

[githubhaoliu]

updateUserRes 我一般简写为 updateUserRes 可能还是会被你 leader 改掉。。[逃]。。

[githubhaoliu]

updateUserResp

[moshao6]

5 楼+1
适应过程，慢慢就好。

[cppgohan]

感觉楼主提到的一些改动 kv, do1().do2() 有点儿矫枉过正的嫌疑.

Bob 大叔 Clean Code 书中说的, "single letter names should only be used as local variables inside small methods – length of the name should correspond to the size of its scope" 我觉得挺合理的.. 另外 temp 交换值这个应该很不 pythonic 吧, 确实更应该改.

不过我觉得 leader 能重视统一风格是好事, 我工作中遇到的代码, 我倒真希望能有人把风格和命名统一一下, 真的没辙.. 代码基有快 10 年历史吧, 连基础的 tab 和 space 都没统一过.. 个别文件的编码格式也不统一, 更别说代码组织风格了..

[cunkouwdy007]

我觉得吧，更重要的不是来 V 站讨论，而是直接跟你的 leader 讨论，不同公司有不同的处理办法，交流下各自的想法不更好

[yopming]

GROUP_INDEX = "group_index" => GROUP_INDEX = "gi"
updateUserRes => updateUserResponse

这就有点互相矛盾了，到底要缩写还是不要呢

[kzzhr]

送他一本代码大全

[lance6716]

你可能是对“风格问题”的认识太狭义了 比如 SkinImage 词语重复（ skin 当然是图片啊），常量一般用简短的字符串或者数字

[huskar]

觉得不妥的地方和 leader 讨论，提前做好功课：列举出你的写法有什么好处，哪些开源项目使用你的写法等。

leader 能这么细致的 code review，应该也会乐意和你讨论。

如果你只会说“我习惯这样写”或者“这样写也没错”，那就乖乖按 leader 的风格来，为团队改变自己的习惯。

[vincenttone]

1. 改回来
2. 无视
3. 换组
4. 离职

实际上工作中要求修改代码的情况还是有一些的，特别是我放飞自我脑洞大开起名字的时候，一般这种我也懒得管了，这东西见仁见智；而且我自己的代码过几天我自己都不认识，也很可能会被我自己重构掉，所以现在代码的质量肯定不是以后的你认为比较好的；还有就是我一般不会让 leader 帮忙 review，不然会有不必要的调整，或者要分享设计，作为一个打工者，可以选择高调也可以选择 低调，哪些符合你自己的性格又符合你的利益呢？作为工程师所谓的骄傲或者自我意识之类的东西，那些东西实际上都是为了写出更好的代码？还是为了平添对别人的不满或者让自己陷入不利的境地呢？

个人认为如果你的代码写的好，设计也不错，除非 leader 想拿你刷存在感，不然不会改你代码的，这也适用于其他人（或者代码审查和修改程序）。

[imn1]

这个看是什么情况
我以前在公司写 PHP 的时候都是用一些通用的变量名，而不是指代意义的变量名，也不用短变量名
但在家就刚好相反，越短越好
原因就是在公司我写的，八成都是模块，class，function，基本上要给别人调用，或者别人要加入模式，抽象化使用
别人原封不动使用的也有，修改重用的也有。所以……

你这个情况，我感觉公司有一套标准，你不妨问问 leader 是否如此

[nanau2016]

你的 leader 一定是个日本人

[zn]

@yopming
我感觉，GROUP_INDEX = "group_index" => GROUP_INDEX = "gi"
这种改法，很可能是这些常量是做 key 用的，所以短一点能省内存。

[xiaket]

我觉得你的 leader 改得都挺不错的啊... 只有我一个人是这个感觉吗?

[ackfin01]

每个人都觉得自己是对的，事实上不一定。正如你觉得你对着，他觉得他对着。
这没有意义。即使你真的错了，你也意识不到，因为你的认识让你觉得你对着。
所以，真正有意义的是，去思考为什么别人会这么认为，思考自己是不是有不足的地方，吸收好的，摒弃不足的。
才会成长。

[pynix]

领导很闲。。

[MrJing1992]

能有 leader 帮你审代码改代码，而且有几处我觉得改得挺好的。不喜欢就跟他说吧

[ShineSmile]

@pynix 同意，而且很负责任。
@zn 头像好评

对语言不是很了解，而且没看到上下文。
变量名就是个标识。最初工作的时候也揪住这些不放。
现在只要稳定，没有逻辑上的错误都 OK。

[youxiachai]

image.setVisible(true) => image.show()

这个其实没啥问题的...这个其实属于一个经验问题....

理解这个问题,我是觉得你不应该这个 show 实现了什么.而是这个 show 带来了什么想法...

如果能理解这个的话.其实都很好说,

其实,有些人的习惯.一般而言是不怎么喜欢直接调用框架的方法.而是在上面包一层定义

[salamanderMH]

领导这么空，当然改这种东西，无关痛痒，关键把活干好

[captainjack]

有就不错了，我们都没有，公司也不算小，开发小 200 人

[rming]

leader 要更多的包容，可能是他风格如此吧

[sonyxperia]

这也太细了，变量名称也没有不规范，这都改的话有点吹毛求疵了

[wangxiaoaer]

@fyxtc 年轻人，一定要搞清楚一件事：在公司，你写的代码所有权不是你的，公司有权利派人去改，这个人可以是你的领导，也可以是你的同事。

[wxl1380610]

他这么做是他的风格吧 ，你要想你的代码 ，以后会有可能是他要维护处理的，出了问题，第一挨骂的是他， 他对你风格有意见 ，又不好说你 ，给你改下 ，让你明白下他的命名规则 ，让你慢慢适应它，或者他自己多做一些，方便他后期改 ，5 楼说的有道理 ，这样改应该比直接说你好一些吧 ，比如我们现在人少，这种问题很严重 ， 不定义好规则，一个人写的代码，另外一个人很难改 ，这个到后期是个挺大的坑吧 。

[aftereclipse]

首先团队有没有明确的编码规范，有的话楼主有没有遵守，没有遵守 leader 帮你修改无可厚非，有遵守，leader 瞎改一通你尽可以鄙视他。假如没有明确的编码规范，楼主有没有阅读项目历史代码，或者公司历史代码，从中可以窥探出一些编码规范，你自己写的代码有没有遵守历史的编码规范（这里有可能编码规范不符合楼主审美，也不符合有些官方语言的编码规范，但是为了维护代码的可读性，后续维护的继承性，使用历史编码规范是必须的）。如果都没有规范，都是胡乱自定义，那么楼主也不用吐槽了，怎么写都是对嘛。最后说一句，推荐使用官方的的编码规范，或者使用大公司的编码规范（例如 alibaba，google 的），团队在于分工和协作，讲究代码的可读性，后续维护的继承性（就是你走了，别人能填你留的坑），很多时候是由于历史原因导致的编码规范一直会沿用，它不一定符合你的审美。

[wxl1380610]

@imn1 同意你的说法 ，自己一个人 怎么写无所谓 ，但是你要给其他人用，尽量不要简写 ，oc 的代码风格是能多长就多长，我认为是合理，因为很多人都是不写注释的 ，就是写注释 ，也不可能写那么细吧 ，对于 leader 考虑的是 ，如果你离职了，怎么才能快速接手或者让别人快速接手你的工作 。

[Sirormy]

我觉得挺好

[galaxyyao]

愿意看下属各种风格千奇百怪的代码，还能耐着性子一个个指出纠正的技术领导，我还是挺佩服的。
其他不论，禁止随意缩写这点绝对是必要的。就一个 Random，有缩写成 r 的，缩写成 ran 的，缩写成 rand 的。又不是多长的单词；一个 Response，这个人缩写成 res，那个人缩写成 resp，还有人缩写成 r 或 rsp，写全会死么。

[happinessnch]

#5 +1

这事不是错， 是没有融合，

产品生命周期越长，对质量要求就越高，对代码风格，设计思路自然会有着相应的高的要求（当然维护成本和新人的学习成本也会增加，未必是好事）。

所以，如果 leader 定位是准的，你们产品需要高质量代码，对一些细节有要求我个人觉得没有问题。
如果，产品本身是重迭代，轻质量的创新型软件，他这样要求就未必合适，纯属个人洁癖或者定位不准，会影响迭代效率。

另外，面向对象代码设计命名在一定程度上代表着设计思路，
你的设计肯定不是错的，但是 leader 对一致性要求高，希望
一个团队写出的代码，像是一个人写出来的，所有的接口统一，命名一致，
这种要求可以理解。

别人看着也会感性上觉得，这个团队写出的东西质量一定很好。
建议楼主多想想，这样修改的设计思路是什么，早点融合进去。

[hellojl]

如果你的 Leader 给 code review 之后只是提出了这些命名的问题，那么只能说他闲的无聊。如果这只是其中的一部分，那么你 Leader 看的还是挺细的，对于一个新人做这么细的 code review，也能看出来他挺在意团队整体的代码风格，cr 能做到这种程度的 leader 不多

单说命名，个人觉得你 Leader 比你的好。如果实在 review 阶段提出来的，你觉得有问题可以直接说，也可以就代码风格这部分跟他沟通一下，双方交流一下想法，比在 v2 上抱怨有用得多

[xianxiaobo]

我也觉得领导挺好的。。。

[wysnylc]

一天 20 行当然有功夫审查,一天 400+让他审查去,看都看懵他

[yizheshiyang]

"image.setVisible(true) => image.show()"
这里很明确是设置可见,用 show 明显更好....
lua 调用其它语言,传参需要转一下(lua_toboolean),效率上差一些.

[miki6180]

你们没有统一代码规范么==

[memorycancel]

一切以实现更好用的产品为目标和前提，每人负责一个模块，只要模块间能够顺畅运转即可。

[pandaMao]

@AMOC 还真是没有对比就么有伤害 2333

[fyxtc]

@yizheshiyang emmm，声明一下，这里的 show 也是要调用到 c++，可以看#18，而且你说的这句话说服力不是很大，首先 show 并不明显更好，按照你的语言表述“设置可见”个人觉得明显是前者更符合这一唯一目的，而且还能形成对比，暗示之前是 false 的。这么说吧，等你需要碰到类似 image.setVislble(isFin)这样的情况，你应该就能理解我了（写过 cocos 的可能更容易理解我的表述）。再考虑到的是团队中已经存在大量的 setVisible(true/false)了，所以。。。。 我说这个是见仁见智的问题，真的完全属于无关痛痒且没有任何实质差别

[Yvette]

这么好的领导还有什么好吐槽的。别人，特别是比你厉害的人（一般技术岗的领导比组员要厉害这个应该没问题吧），做的事情如果有不理解，那就是要学习的东西，完全没必要发脾气…

最近放假在复习 C++，发现语言设计者会想方设法增加一些看似无用实则给可读性添加工具的东西，比如 constexpr 的应用，以及函数原型等等。当然有的人愿意说成是代码风格的问题，Google C++ 不也是「代码风格」么。

我觉得好的工程师写代码可读性永远应该是第一位，在语言本身的加持下与这个性能要求并不矛盾。因为代码是设计出来给人类看的，机器可不会认代码，它只会做加减法。

[randyzhao]

我觉得没毛病

代码规范本来就没有绝对的对错

但是团队就是用来融入的

放宽心，不能太矫情

不然，单干好了。

[grantonzhuang]

变量和函数的命名，应该体现业务逻辑，和具体的实现无关。
第一个 item 我觉得 icon 确实比较好。其他的我觉得你 leader 改的都很好。
这里不谈其他的，就说这几处改动。

[islandev]

我感觉 你能 遇到 还给你 review 代码的老大 是 挺幸运的
别抱怨了
PS:我感觉你 tl 说的挺有道理的

[wingyiu]

没卵区别，可有可无的修改。

[laoyur]

@likuku rand 是渲染？…… render 表示：那我是啥

[seaswalker]

这种无伤大雅的改了也就改了

[fyxtc]

@islandev 我觉得老大人也很好，是很 nice 的人，有点地方改的也很好。因为我自己也是重视命名的，所以 review 的话我还是更偏向希望能看到一些建设性的修改，比如性能优化或者隐藏 bug 这样的

[pexcn]

leader 肯定有强迫症+完美主义+洁癖，这样的人写出来的代码很棒

[juneszh]

觉得没有必要 是因为你没当过 leader

[Miy4mori]

我觉得改的都有理有据，把你的歧义缩写都改了，太好了，等哪天你读到各种歧义的缩写的时候你就懂了。

[akira]

这样的 leader 不错啊，够细心。 而且修改的点 也都不错啊。 如果对某个修改的点有意见，最好还是问 leader 为什么要这样修改.

>>> 一个调用我是拆开的 a.do1() a.do2() => a.do1().do2()
明确调用顺序。不过个人更倾向做个 do3 , 里面 do1 do2

>>> 更新用户状态方法名 updateUserRes => updateUserResponse
消除缩写歧义. Res 一般是 resource 的缩写吧.

>>>最不能忍的是这个。image.setVisible(true) => image.show()
明确函数定义，去除不必要的参数。

[asionbo]

我觉得我学到了-_-!

[zhea55]

image.setVisible(true) => image.show()

setVisible 命令式编程，机械口吻。

show 清晰明了。


这样的领导哪里找？

[327beckham]

我觉得我学到了，以后每次你领导帮你改代码的时候，你能不能都发出来让大家看看，这样大家都能一起学习进步

[ofooo]

楼主还在硬撑。我也觉得学到了。以后尽量不缩写。。。。。

[southsala]

团队应该配合好，自己项目可以自己发挥。

[kslr]

换做是我也会忍不住改的

[l00t]

闲得蛋疼吧。除了少数几个，别的都是改得毫无必要。

要统一团队变量命名风格，那先出规范。在没有规范，存量代码也都没改的情况下，搞这些东西纯粹是瞎折腾。

如果这种并没有什么歧义只是写法有细微差别的变量名都接受不了，那还看不看别人的代码了? 还看不看别的项目的代码了？

[l00t]

@liyer #5 当然是一个 leader 去适应 10 个人的风格啊。不然就天天给 10 个人改变量名吧，还不得累死。

[fuxiaohei]

setVisible => show。希望代码如文章，挺好的。

[zealinux]

你们 Leader 真好。
说实话，真是有点羡慕。

[yingfengi]

5 楼正解。

[ChangQin]

羡慕+1

[zilan]

@yopming

GROUP_INDEX = "group_index" => GROUP_INDEX = "gi"
updateUserRes => updateUserResponse

前者是因为定义时候就已经包含了其表示的意义，实际的值完全可以简短一些。
后者是因为 Res 这里有些简写有些全写，不如都全写，而 Res 的缩写可能有歧义。两者对应是不一样的


这些改动都挺好的，不只是要不要适应 leader 的问题。

[sfz97308]

你 leader 做的这些修改没问题，既然你本身已经有代码规范的意识并且有还不错的习惯了，试着理解一下这些修改的原因可以让你再提升一步。

[Keyes]

就我觉得 Leader 改得挺好的吗

[fulvaz]

就像是 stepCurrent 和 currentStep 两种命名都没错

但是如果混着写, 线上出了 bug, 你可能就就要去搜索两遍, 甚至可能会改错

那就没完没了了, 我站 leader

[Microi]

准确直观简单，我觉得很好。

[fyxtc]

@ofooo 没有硬撑啊哈哈，res 是不好，已认识到
@zhea55
@akira
@fuxiaohei

反驳 show 的观点，请见最后一条附言

[poorcai]

我觉得改得挺好的啊

[Jex]

这个 Leader 是个自我感觉良好的 SB

[jadec0der]

贴个我司日常 code review 回复…改变量名，方法名，注释，都是很正常的事

很多觉得公司没有大牛指导的人，真遇到人指导他写代码就会嫌烦…

[twotiger]

改的还能接受,改成链式调用不好说,具体看你是什么场景了
以前领导也给我 code_review,内心是有一点拒绝的,后来离开那家公司了,现在还挺怀恋的
我建议:
1.不同意的地方,说出来,和他讨论,我相信他能做你的 leader 总归有优秀于你的地方
2.把他设计的亮点,记录下来,不同意的地方,也记录下来,以后自己做领导了,就按自己的方法
3.受不了就离职

[jorneyr]

更新用户状态方法名 updateUserRes => updateUserResponse
服了你和你们头啊，这 2 个都不能表现出更新用户状态的意思

[jorneyr]

一些变量名：GROUP_INDEX = "group_index" => GROUP_INDEX = "gi" USER_STATUS_DATA = ” user_status_data" => USER_STATUS_DATA = "u_sd"

个人觉得修改的没有原来的好