和 mentor 代码习惯不一样，好头痛

[Ainokiseki]

校招生一枚，入职半年了，和 mentor 一起负责项目的某个模块，代码自然是两个人互相 review 。
mentor 之前在某大厂，看起来是比较资深的那种，再加上前期对项目不熟，小透明基本上是 mentor 说啥是啥。
review 的时候 mentor 的代码只要功能 ok 那就好，但是 mentor review 我的时候就有点不走心，有些地方没看懂就写 comment ，还有些地方我的设计本来 ok 的，他又要按他自己的习惯来改。
我理解这项目最开始是 mentor 写的，可能看着自己创造的东西被别人改来改去总会不舒服？至少我是无数次幻想着哪天 mentor 不在了我要把现在的代码按我的风格从头到尾重构一下 hhhh
可能 mentor 觉得我菜吧，但我觉得我只是经验不足，好歹哥们也是名校出来的，开发工作难度也就那样，要是功能缺陷那让我改我没话说，但只是代码习惯不一样就被要求改就很烦

[diagnostics]

@diagnostics 换句话说，你 mentor 的代码更好抽象，对于以后的扩展也方便。

当然这个案例是这两个属于不同一个业务的，假设相同业务那么就不行

```
function methodA() {

for i:=0;i<len(array-1);i++{
// do sth normal
}
}

function methodB() {
// do sth special for array[len(array)-1]
}


```

[iyaozhen]

你硬要比较的话，你 mentor 的”习惯“更好，思路更加清晰明确

[Pastsong]

> 至少我是无数次幻想着哪天 mentor 不在了我要把现在的代码按我的风格从头到尾重构一下
太自大了，劝你最好别有这想法

[neochen13]

mentor 的好，你明显是看不上你 mentor 的水平……

觉得看起来差不多，然后发贴来寻找认同

其次就是你想重构所有代码，坦白说，这是有巨大风险的

如果你真的这么做了，能承担的了后果吗？太以自我为中心了

[monmon]

如果这个 Array 的长度是 1w ，你的代码给人的感官上有 9999 次 if(special) 的判断，虽然有 CPU 分支预测实际运行效率差异不大，但是这是可以人为避免的多余逻辑，另外代码终究是给人看的。

[jjwjiang]

年轻人还是谦逊一点好；

一个简单的例子是，将来这个 if 需要查库，你的代码直接修改将会产生严重的性能问题以至于需要重构，而你 mentor 的代码完全不会有这问题。

[WytheHuang]

我个人可能倾向于你 mentor

[fzdwx]

mentor 的好，少了 n 次判断

[otakustay]

除了那个 len(array) - 1 会少循环一个元素外，整体我认同你 mentor 这个代码。把正常处理和特殊处理分开，逻辑表达上也更清晰

[pigspy]

你 mentor 的明显好
一段代码只干一件事

[suiterchik]

各有各的优劣吧
* 你的写法对未来业务逻辑的变更会方便一些，比如现在只是对最后一个元素处理，那未来可能会对命中某些逻辑的元素处理，那么这种情况下你的代码改起来会容易一些
* mentor 的写法少一些 if 判断，能带来一些性能上的优化，不过编译器和 JIT 估计会优化掉，所以可能性能上差异不会特别大

对于这种影响不大，属于代码风格方面的差异，那就遵循公司整体的代码风格吧，同一种风格利于长期的维护和迭代。对于有性能风险（跑得快不快）、维护性风险（后期逻辑好不好变更）、稳定性风险（挂了会不会影响其它逻辑）等，那么就对等沟通，对事不对人呗

[gimp]

同认为你 Mentor 的代码好。

你的写法把特殊逻辑放在通用的循环中处理，首先是增加了无效判断，其次代码耦合度更高。

[zjj19950716]

你的好， 空 array 不会报错

[visper]

无所谓了,能跑就行,都差不多,不在乎这种性能.

[abc1310054026]

除开一些有比较高性能要求的项目，都应该按规范行事。规范带来的统一能够极大提高项目的可维护性。自己的偏好可以体现在自己的项目里，遵守规范是专业性的体现。

[nevermoreluo]

youtube 上有个 CodeAesthetic ，感觉可以看下。有一期讲的 Never Nester ，还是有部分道理的

像我这种野路子常年代码畸形的人，时常要翻出来再看下
找到了，<amp-youtube data-videoid="CFRhGnuXG-4" layout="responsive" width="480" height="270"></amp-youtube>

[InkStone]

你 mentor 的写法比你的强太多了……
虽然在现代的 CPU 分支预测下这个 if 判断的代价不大，但无端地在循环里多跑一条指令和潜在的分支预测失败，完全是无谓地给 CPU 上强度，而且还没提高可读性与可扩展性。

前面看到你说起 OI ，请记住 OI 里大多数的编码习惯在实际工程中都是糟粕，别代入到工程中。

[nuk]

个人觉得你写的好，一来理解很容易，二来更容易扩展，至于判断的性能消耗，可以忽略不计。
类 C 语言这种< len ，或者<= len - 1 ，完全就是折磨，你的 mentor 是 C 陷阱与缺陷的忠实读者吧

[ganbuliao]

这个不是和 mentor 代码习惯不一样
是你的习惯不好 导致 代码可读性和性能的问题吧 （写代码的思路不对）

[yaocai321]

从职业发展来说，听大哥的。
从代码风格上说，平铺当然比嵌套好，所以听大哥的。

最后说下我工作的态度：
1.有不同见解肯定会提出来讨论。
2. 没法达成一致，没有原则性前提下，我不会跟其他人争到底。
3. 至于对与错，表面上我奉行 "你都对", 实际上我会自我过滤，认真的参考别人的想法，然后取其精华去其糟粕。