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

[Ainokiseki]

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

关于例子：之前的写法可能误导大家，我重新 append 一下
注意不是只处理最后一个，不是只处理最后一个，不是只处理最后一个

```
for i:=range array{
// do sth normal to array[i]
if i==len(array)-1{
// do sth special to array[len(array)-1]
}
}
```
mentor 要我改成：
```
for i:=0;i<len(array-1);i++{
// do sth normal
}
// do sth special for array[len(array)-1]

```

[liprais]

你才上班半年，当然是听 mentor 的

[idealhs]

说这么多没用的，贴点代码上来就知道了

[hahastudio]

代码风格这东西，只要是一样的基本就是好的
同一组里代码风格不一样才头疼

[Ainokiseki]

@idealhs 我举个例子：某段代码要对数组中最后一个元素做特殊处理，我写的是：
```
for i:=range array{
if i==len(array)-1{
// do sth special
}
}
```
mentor 要我改成：
```
for i:=0;i<len(array-1);i++{
// do sth normal
}
// do sth special for array[len(array)-1]

```

[lifei6671]

和是不是名校毕业的没关系，和公司制定的代码规范有关系，只要有规范，大家都按照规范来。如果没有规范，可以按照社区规范来。

[Ainokiseki]

@Ainokiseki 这个我不知道 mentor 是真觉得下面那个好，还是一开始看错了，以为我只想处理最后一个元素，后来在我指出来之后强行挽尊。。

[undeflife]

原来是 IfErrNotEqualNilLang 那还有啥风格好纠结的，反正怎么写都那么丑。

回到你上面的例子，都明确是最后一个了不在循环里去判断不是效率更高吗

[kxct]

多层嵌套循环会让代码层次变得复杂。
你说只需要特殊处理最后一个元素为什么要遍历整个 array 。

[Yuhyeong]

理解。
虽然是个例子，但是感觉正常开发中 OP 的写法相对少见一些。特殊处理放循环里每次都需要判别，可能放在正常操作外面会简洁明了很多？这样特殊处理和普通处理就是解耦的两个部分了。

同一个组里面代码风格不统一血压真的高，建议决斗哈哈。厂里面有统一的代码标准吗？

[LeegoYih]

这个例子跟代码习惯没关系，是可读性的问题

[Ainokiseki]

@kxct 但是其他元素也要处理的，可以类比成 oi 里面输出答案的时候，除了最后一个元素之外其他元素末尾都要加一个空格的场景，之前都是直接在循环里判断的

[idealhs]

@Ainokiseki #5 我觉得 mentor 的明显好，如果你只想处理最后一个元素，循环中那么多的判断都是无意义的

[Ainokiseki]

@Yuhyeong 小厂没有这么细的。。我找找 google 的 style 有没有关于这个的

[k9982874]

什么时候懂得遵循即有项目中的规范继续开发，而不是上来就掀桌子，你就是一个成熟开发了

[k9982874]

另外你给的例子，说明你的 mentor 更有经验，把不同的操作放到不同的代码 scope 里，不要写到一个大块里面
代码结构更清晰，后面如果有人接手更方便阅读理解。

[kxct]

@Ainokiseki 那你 mentor 的修改和你是一个意思吧，代码嵌套层数少一点会比较好看。

[aheadlead]

同投你 mentor 一票。。。你们这什么公司？挺有意思的

[Ainokiseki]

好吧，看来大家都赞成 mentor 的方案，看来我还要再学习一个，也许我是太追求简洁忽视可读性了>_<

[ScepterZ]

@Ainokiseki 他看错的原因我觉得能理解，因为他是在没想到你只处理最后一个居然要循环，自然以为是你循环处理别的东西了。说不好听的就是高估你的水平了

[unclejock]

for in 是最简洁的，少点花里胡哨的语法糖

[pkoukk]

我主导的项目都是微服务，DDD ，拆模块拆项目，总是就是求求你别把代码写我项目里，我们俩 rpc 交流就行
什么代码风格，能用就行，眼不见为净

[sfz97308]

你举的这个例子如果让我 review ，我应该也会指出同样的问题。不同的代码风格各有利弊，可以商量，团队里商量出一个大家都能接受的共识就好。但你这个例子不属于代码风格或代码习惯的问题，这种代码逻辑的差异，虽然等价，但是存在明显优劣。

[gxy2825]

op 或许可以把视野放宽到你们公司的整个技术团队，看看大家的规范是如何？如果你和大多数人都不太一样，建议还是按团队规范走

[Ainokiseki]

@ScepterZ 我 不 是 只 处 理 最 后 一 个！只是最后一个要特殊处理。。。omg 我还是 append 到主楼吧

[Immortan]

if 越少，代码越好。

[cp19890714]

@Ainokiseki 两个差不多, 但如果一定要分个好坏, 那么 mentor 的更好.
首先, 明确一点: 任何软件都是业务软件. 对于技术软件, 技术本身就是业务.

* 对于团队项目, 大部分情况下, 代码的可读性要比效率更重要.
* 根据单一职责原则, 每段代码只做一件事情.
* 代码应该尽量只表达其业务意义. 这也是函数式编程的好处之一.

对于你给的例子, 最后一个元素要特殊处理, 就应该把这块特殊逻辑"独立且突出", 增强可读性.

[ScepterZ]

@Ainokiseki 那是我理解错了，这样的话看具体的逻辑吧，哪种和产品思路比较顺就怎么写

[dddd1919]

@Ainokiseki 就这段代码来讲，假设 array size 有 1w ，你的代码除了循环外还需要 1w 次的 if 判断，mentor 的只需要一次，你说哪个好？

我也名校毕业，工作时也会时不时的借鉴一下以前写过的代码，可能当时觉得还不错，现在看时不时的就会感叹 oh shiiiiiiiit

[iOCZS]

通过 code review ，互相 battle 才是出路

[taotaodaddy]

我说话直
这两个根本不是差不多的
Mentor 的好
OP 的不好

[rqdmap]

同样不喜欢太多的嵌套层次。。像元素间输出空格这种简单场景可能还行，一旦特判的代码逻辑复杂起来容易出现缩进地狱。。

[nbndco]

为啥你会觉得跑这么多没用的 if 只是代码习惯不同

[darkengine]

其他元素做一种处理，最后一个元素做特殊处理

虽然功能一样，但是 mentor 写的代码不用每次都在循环里检查当前是不是最后一个元素

[okeyokey]

这不是风格问题，明显 mentor 代码更好，可读性更强，没有嵌套 if ，没有无效循环

[111qqz]

感觉你 mentor 的方案更好一点?
另外盲猜 op 是 OI/XCPC 选手?

[zcjfesky]

你多做了一堆 if 判断还觉得自己做的没问题，还发出来让人评理，笑死
名校病好好改改，也就是你现在的 mentor 人好心善给你脸了，以后职场上别的人不一定那么善良的

[sakamoto123]

OP 的更好吧，for 循环里也不用针对 数组为空进行特殊的判断。

[hhjuteman]

@Ainokiseki

这事实上并不只是简洁性或者可读性得问题了，这只是一方面。

请了解现代 CPU 有关于分支预测的技术。
第一个代码片段中的 if 语句是在 for 循环内部的，这意味着每次迭代都需要进行一次分支预测。如果你的 if 语句的条件是随机的或者不可预测的，那么 CPU 可能会频繁地预测错误，导致性能损失。
相比之下第二段代码特殊处理，则不会有这些性能损失。

请不要忽视这么一点点性能差距，也许在你这段代码中只有纳秒级差距，但有的时候就是这里一点点，那里一点点，最终导致了数量级的差距

[diagnostics]

你 Mentor 的习惯有点类似于贯彻 Guard Clause ，对于可读性会更好。

实际执行的时候，如果是 Java 应该会优化这种代码，变成对机器友好的。

现代编译器很强，建议写代码阅读性更好的。

[flmn]

必然是 mentor 的代码写得好啊。

另外作为新人，follow 项目已有代码规范是一种职业化，不是说你自己的多好，就要重构成你的，需要考虑成本。

[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 ，还是有部分道理的

像我这种野路子常年代码畸形的人，时常要翻出来再看下
找到了，

[InkStone]

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

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

[nuk]

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

[ganbuliao]

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

[yaocai321]

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

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

[idealhs]

看来名校出来的也就那样，跟我们垃圾学校没太大区别。工作了如果能遇到愿意带的，哪怕不是那么大佬，抱紧了跟着学才是真学到。干个几年再回头看自己写的是些啥玩意吧。

[ldyisbest]

如果你觉得你的写法好，就据理力争，否则就听老大的

[ZxykM]

从给的例子来看，我更喜欢你 mentor 的风格，一眼就知道干了什么

[Vclow]

你问他改成这样对比原来的有什么好处呗

[Orenoid]

你成功把两个负责不同职责的逻辑揉杂在了一个 for 循环里，读这段 for 循环的人得同时关注两个逻辑

[listenerri]

除了每次都比较索引的影响外，那个特殊判断写在 for 循环里，尤其是 for 循环里还做了其他事，会容易让读者忽略掉特殊处理最后一个元素的逻辑（或者直觉 for 里没什么特殊的东西），而单独写在外面时，针对最后一个元素的处理意图就比较明确和清晰

[sockpuppet9527]

试想一下 lz 举得例子是最底下的 N ，上面是一个 NP ，那就知道你的 mentor 让你改是多么正确的一件事了。

[Leviathann]

不是哥们，都写 go 这种东西了还在意什么代码风格？那我问你 15:04:05 是什么风格？
官方带头拉屎的语言，说什么就是什么呗，浪费一秒算我输

[fredweili]

鸡毛蒜皮

[MuSeCanYang]

眼高手低

[forgottenPerson]

你写的每次还要多做一个判断，你负责人那种一个循环就一个逻辑，之后再处理最后一个元素的逻辑。你静下来好好看看，很明显你负责人那种好点啊。这真没说的。当然了都能运行，但是你负责人那种好点。

说实在的也是你名校出来的，要是去个一般的公司，你看你挨说不，你负责人真挺好的。你的话还是要多看，多指教，就看你这个问题，你负责人确实好一些，多向他学习。

[nagisaushio]

楼主你不妨说说你觉得你写的哪里好了

[RainCats]

当别人指出我代码的修改意见时我是很高兴的，平时也会去看同事的代码，有好的我就学过来用

[cyberCat]

循环里放 if ？去了解下分支预测提高下水平。
名校出身，本事不高，架子不小。

[pultako]

涉及到下标操作和 range 操作对比的，统一使用 range 。

[forgottenPerson]

同问，为啥 op 觉得这是可读性问题，我不太理解。

[kdd0063]

- 名校很了不起？这行当最不缺名校的
- OI 的很多风格用到工程里就是 shit
- 你那么多次无效 if 怎么来的自信？
- 你就是 CMU 科班的，团队有编码规范一样要遵循

[abcdexx]

一串英文字母 我踏马看半天 [乐]

[Rorysky]

王自如：刚毕业的学生应该有空杯心态

[liyunyang]

我站你的导师，导师这样确实负责

[huangliu]

看到大家都觉得你 mentor 的写法更好，我就放心了
你要相信能做你 mentor 是有原因的

[forgottenPerson]

刚毕业，想独当一面大家都能理解，但是有些编程思路真地值得好好学习，以及一些场景怎么去做，怎么去思考，你现在有这么个负责的负责人，得把握住机会，多向他指教，很多人没你这个机会的，都是直接开干，还要做其他事情，俗称打杂，并不是一直就写代码，能一直从事主职真挺不错的。

比如一个判断，只要一个元素根据条件不满足，就返回，一般的思路是先去循环判断这个不满足的条件，而不是在循环里去逐一比较满足的条件

[windshadow]

再怎么名校，进到企业也都是菜鸡，不要太高估自己。

[ansnail]

刚工作的小伙伴貌似都觉得把代码写简洁就是最牛 B 的，但工作多年的感觉是除非你是单打独斗，否则代码的可读性永远是第一位的，特别是在团队中，当然了基本的效率还是要有的

[zhdi]

就你举的这栗子。。。循环里放 if ，每次循环都 if 一下，你还觉得是代码习惯问题？
大概测试了一下，没有缓存的情况下后一段是前一段时间的 400%，有缓存的情况下是 200%，所以这叫代码习惯？这叫你不懂底层还不愿意学习。。

[F1reman]

且不说上面说的什么分支预测你能不能理解
你这两段代码运行起来 debug 一下，你就能知道你 debug 每一次都要多按一下了

[ArianX]

mentor 的代码确实好一些啊，简洁性可读性性能都会好一些

[runzekk]

不要有自己的风格。

一个项目同一个风格才是最屌的。

不要刚开始就形成了自己的风格了，风格这个东西没有好坏，一定要和之前的保持一致。

[sechi]

too young, too simple, sometimes naive

[candidcrat]

这和代码风格没有关系吧, 这个例子, 功能要分开, 要我写两个写单独方法, 杂糅在一起是不好的

[williamscorn]

看你的代码，对这个数组的所有元素其实都先做了处理，然后对最后一个元素做了特殊处理，那这个特殊处理完全可以拿到循环的外面来做吧，根本不需要放在循环里:
for i:=range array{
// do sth normal to array[i]
}
// do sth special to array[len(array)-1]

[fulvaz]

你 mentor 没错，听他的

[oceana]

你 mentor 没错，一是没有无效循环，二是分开两块逻辑

[momogzp]

站你 mentor, 代码是写给人看的. 可维护也是非常重要的一部分.
你代码的可维护性就没你 mentor 的好, 更不用说其中可能存在的性能损耗了.

学吧, 学无止境. 太深了.jpg

[DefoliationM]

第二个好，尽量减少逻辑嵌套，第二个可以直接把 for 嵌套 if 去掉，显然第二个好。

[Huelse]

不管如何学习期间请先尊重 mentor ，如果你觉得难受就想如果有错也是 mentor 的锅，等你自己能独立完成项目了再按自己的想法来。
总得来说就是先学习后创改进，不要自作主张，哪怕你真的是天才。

[houshuu]

就这个范例来说, 我觉得第二个好.
上下两个逻辑分的越开越清晰.

[Baoni]

代码真看不出好坏的话，应该是品味有问题。
我才是惨，我觉得我之前的 mentor 是你这样的，能跑就行的心态还看不上别人的修改，甚至有时不能跑，一看里面一堆 bug ，辛辛苦苦帮改了，他还讲其实是小 bug 。不过自信心和吹牛能力是真的强，说话官场味十足。
多希望能和你换个 mentor 。4 赢。

[vacuitym]

我觉得第二个明显更好，第一个判断要执行 len-1 次

[43n5Z6GyW39943pj]

有大佬带你,好好学