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

[Ainokiseki]

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

[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 项目已有代码规范是一种职业化，不是说你自己的多好，就要重构成你的，需要考虑成本。