新公司，代码审查的时候 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

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

[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),效率上差一些.