这是一个创建于 400 天前的主题，其中的信息可能已经有所发展或是发生改变。
校招生一枚，入职半年了，和 mentor 一起负责项目的某个模块，代码自然是两个人互相 review 。
mentor 之前在某大厂，看起来是比较资深的那种，再加上前期对项目不熟，小透明基本上是 mentor 说啥是啥。
review 的时候 mentor 的代码只要功能 ok 那就好，但是 mentor review 我的时候就有点不走心，有些地方没看懂就写 comment ，还有些地方我的设计本来 ok 的，他又要按他自己的习惯来改。
我理解这项目最开始是 mentor 写的，可能看着自己创造的东西被别人改来改去总会不舒服？至少我是无数次幻想着哪天 mentor 不在了我要把现在的代码按我的风格从头到尾重构一下 hhhh
可能 mentor 觉得我菜吧，但我觉得我只是经验不足，好歹哥们也是名校出来的，开发工作难度也就那样，要是功能缺陷那让我改我没话说，但只是代码习惯不一样就被要求改就很烦
mentor 之前在某大厂，看起来是比较资深的那种，再加上前期对项目不熟，小透明基本上是 mentor 说啥是啥。
review 的时候 mentor 的代码只要功能 ok 那就好，但是 mentor review 我的时候就有点不走心，有些地方没看懂就写 comment ，还有些地方我的设计本来 ok 的，他又要按他自己的习惯来改。
我理解这项目最开始是 mentor 写的，可能看着自己创造的东西被别人改来改去总会不舒服？至少我是无数次幻想着哪天 mentor 不在了我要把现在的代码按我的风格从头到尾重构一下 hhhh
可能 mentor 觉得我菜吧，但我觉得我只是经验不足，好歹哥们也是名校出来的，开发工作难度也就那样，要是功能缺陷那让我改我没话说，但只是代码习惯不一样就被要求改就很烦
第 1 条附言 · 2023-11-23 11:53:08 +08:00
关于例子：之前的写法可能误导大家，我重新 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]
```
注意不是只处理最后一个，不是只处理最后一个，不是只处理最后一个
```
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]
```
 |
1
liprais 2023-11-23 11:03:23 +08:00
你才上班半年，当然是听 mentor 的
|
 |
2
idealhs 2023-11-23 11:08:38 +08:00
说这么多没用的，贴点代码上来就知道了
|
 |
3
hahastudio 2023-11-23 11:11:12 +08:00  1
代码风格这东西，只要是一样的基本就是好的
同一组里代码风格不一样才头疼 |
 |
4
Ainokiseki OP @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] ``` |
 |
5
lifei6671 2023-11-23 11:12:42 +08:00 1
和是不是名校毕业的没关系，和公司制定的代码规范有关系，只要有规范，大家都按照规范来。如果没有规范，可以按照社区规范来。
|
|
6
Ainokiseki OP @Ainokiseki 这个我不知道 mentor 是真觉得下面那个好，还是一开始看错了，以为我只想处理最后一个元素，后来在我指出来之后强行挽尊。。
|
 |
7
undeflife 2023-11-23 11:15:38 +08:00 12
原来是 IfErrNotEqualNilLang 那还有啥风格好纠结的，反正怎么写都那么丑。
回到你上面的例子，都明确是最后一个了不在循环里去判断不是效率更高吗 |
 |
8
kxct 2023-11-23 11:20:12 +08:00
多层嵌套循环会让代码层次变得复杂。
你说只需要特殊处理最后一个元素为什么要遍历整个 array 。 |
 |
9
Yuhyeong 2023-11-23 11:20:35 +08:00
理解。
虽然是个例子，但是感觉正常开发中 OP 的写法相对少见一些。特殊处理放循环里每次都需要判别，可能放在正常操作外面会简洁明了很多？这样特殊处理和普通处理就是解耦的两个部分了。 同一个组里面代码风格不统一血压真的高，建议决斗哈哈。厂里面有统一的代码标准吗？ |
 |
10
LeegoYih 2023-11-23 11:23:01 +08:00
这个例子跟代码习惯没关系，是可读性的问题
|
|
11
Ainokiseki OP @kxct 但是其他元素也要处理的，可以类比成 oi 里面输出答案的时候，除了最后一个元素之外其他元素末尾都要加一个空格的场景，之前都是直接在循环里判断的
|
|
12
idealhs 2023-11-23 11:23:50 +08:00
@Ainokiseki #5 我觉得 mentor 的明显好，如果你只想处理最后一个元素，循环中那么多的判断都是无意义的
|
|
13
Ainokiseki OP @Yuhyeong 小厂没有这么细的。。我找找 google 的 style 有没有关于这个的
|
 |
14
k9982874 2023-11-23 11:25:49 +08:00 4
什么时候懂得遵循即有项目中的规范继续开发，而不是上来就掀桌子，你就是一个成熟开发了
|
|
15
k9982874 2023-11-23 11:29:22 +08:00
另外你给的例子，说明你的 mentor 更有经验，把不同的操作放到不同的代码 scope 里，不要写到一个大块里面
代码结构更清晰，后面如果有人接手更方便阅读理解。 |
|
16
kxct 2023-11-23 11:31:30 +08:00
@Ainokiseki 那你 mentor 的修改和你是一个意思吧，代码嵌套层数少一点会比较好看。
|
 |
17
aheadlead 2023-11-23 11:34:59 +08:00
同投你 mentor 一票。。。你们这什么公司？挺有意思的
|
|
18
Ainokiseki OP 好吧，看来大家都赞成 mentor 的方案，看来我还要再学习一个，也许我是太追求简洁忽视可读性了>_<
|
 |
19
ScepterZ 2023-11-23 11:38:31 +08:00 4
@Ainokiseki 他看错的原因我觉得能理解，因为他是在没想到你只处理最后一个居然要循环，自然以为是你循环处理别的东西了。说不好听的就是高估你的水平了
|
 |
20
unclejock 2023-11-23 11:43:44 +08:00
for in 是最简洁的，少点花里胡哨的语法糖
|
 |
21
pkoukk 2023-11-23 11:46:21 +08:00 1
 我主导的项目都是微服务，DDD ，拆模块拆项目，总是就是求求你别把代码写我项目里，我们俩 rpc 交流就行什么代码风格，能用就行，眼不见为净 |
 |
22
sfz97308 2023-11-23 11:49:17 +08:00 1
你举的这个例子如果让我 review ，我应该也会指出同样的问题。不同的代码风格各有利弊，可以商量，团队里商量出一个大家都能接受的共识就好。但你这个例子不属于代码风格或代码习惯的问题，这种代码逻辑的差异，虽然等价，但是存在明显优劣。
|
 |
23
gxy2825 2023-11-23 11:49:26 +08:00 1
op 或许可以把视野放宽到你们公司的整个技术团队，看看大家的规范是如何？如果你和大多数人都不太一样，建议还是按团队规范走
|
|
24
Ainokiseki OP @ScepterZ 我 不 是 只 处 理 最 后 一 个！只是最后一个要特殊处理。。。omg 我还是 append 到主楼吧
|
 |
25
Immortan 2023-11-23 11:51:45 +08:00 3
if 越少，代码越好。
|
 |
26
cp19890714 2023-11-23 11:52:35 +08:00
@Ainokiseki 两个差不多, 但如果一定要分个好坏, 那么 mentor 的更好.
首先, 明确一点: 任何软件都是业务软件. 对于技术软件, 技术本身就是业务. * 对于团队项目, 大部分情况下, 代码的可读性要比效率更重要. * 根据单一职责原则, 每段代码只做一件事情. * 代码应该尽量只表达其业务意义. 这也是函数式编程的好处之一. 对于你给的例子, 最后一个元素要特殊处理, 就应该把这块特殊逻辑"独立且突出", 增强可读性. |
|
27
ScepterZ 2023-11-23 11:54:20 +08:00
@Ainokiseki 那是我理解错了，这样的话看具体的逻辑吧，哪种和产品思路比较顺就怎么写
|
 |
28
dddd1919 2023-11-23 11:59:46 +08:00 1
@Ainokiseki 就这段代码来讲，假设 array size 有 1w ，你的代码除了循环外还需要 1w 次的 if 判断，mentor 的只需要一次，你说哪个好？
我也名校毕业，工作时也会时不时的借鉴一下以前写过的代码，可能当时觉得还不错，现在看时不时的就会感叹 oh shiiiiiiiit |
 |
29
iOCZS 2023-11-23 12:02:40 +08:00 1
通过 code review ，互相 battle 才是出路
|
 |
30
taotaodaddy 2023-11-23 12:48:16 +08:00 12
我说话直
这两个根本不是差不多的 Mentor 的好 OP 的不好 |
 |
31
rqdmap 2023-11-23 12:58:48 +08:00 via Android
同样不喜欢太多的嵌套层次。。像元素间输出空格这种简单场景可能还行，一旦特判的代码逻辑复杂起来容易出现缩进地狱。。
|
 |
32
nbndco 2023-11-23 13:01:17 +08:00 4
为啥你会觉得跑这么多没用的 if 只是代码习惯不同
|
 |
33
darkengine 2023-11-23 13:06:52 +08:00
其他元素做一种处理，最后一个元素做特殊处理
虽然功能一样，但是 mentor 写的代码不用每次都在循环里检查当前是不是最后一个元素 |
 |
34
okeyokey 2023-11-23 13:09:18 +08:00
这不是风格问题，明显 mentor 代码更好，可读性更强，没有嵌套 if ，没有无效循环
|
 |
35
111qqz 2023-11-23 13:13:38 +08:00
感觉你 mentor 的方案更好一点?
另外盲猜 op 是 OI/XCPC 选手? |
 |
36
zcjfesky 2023-11-23 13:16:21 +08:00
你多做了一堆 if 判断还觉得自己做的没问题，还发出来让人评理，笑死
名校病好好改改，也就是你现在的 mentor 人好心善给你脸了，以后职场上别的人不一定那么善良的 |
 |
37
sakamoto123 2023-11-23 13:20:41 +08:00
OP 的更好吧，for 循环里也不用针对 数组为空进行特殊的判断。
|
 |
38
hhjuteman 2023-11-23 13:26:42 +08:00 1
@Ainokiseki
这事实上并不只是简洁性或者可读性得问题了，这只是一方面。 请了解现代 CPU 有关于分支预测的技术。 第一个代码片段中的 if 语句是在 for 循环内部的，这意味着每次迭代都需要进行一次分支预测。如果你的 if 语句的条件是随机的或者不可预测的，那么 CPU 可能会频繁地预测错误，导致性能损失。 相比之下第二段代码特殊处理，则不会有这些性能损失。 请不要忽视这么一点点性能差距，也许在你这段代码中只有纳秒级差距，但有的时候就是这里一点点，那里一点点，最终导致了数量级的差距 |
 |
39
diagnostics 2023-11-23 13:28:37 +08:00
你 Mentor 的习惯有点类似于贯彻 Guard Clause ，对于可读性会更好。
实际执行的时候，如果是 Java 应该会优化这种代码，变成对机器友好的。 现代编译器很强，建议写代码阅读性更好的。 |
 |
40
flmn 2023-11-23 13:28:58 +08:00
必然是 mentor 的代码写得好啊。
另外作为新人，follow 项目已有代码规范是一种职业化，不是说你自己的多好，就要重构成你的，需要考虑成本。 |
|
41
diagnostics 2023-11-23 13:30:40 +08:00
@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] } ``` |
 |
42
iyaozhen 2023-11-23 13:35:38 +08:00
你硬要比较的话，你 mentor 的”习惯“更好，思路更加清晰明确
|
 |
43
Pastsong 2023-11-23 13:36:23 +08:00 1
> 至少我是无数次幻想着哪天 mentor 不在了我要把现在的代码按我的风格从头到尾重构一下
太自大了，劝你最好别有这想法 |
 |
44
neochen13 2023-11-23 13:36:41 +08:00 3
mentor 的好，你明显是看不上你 mentor 的水平……
觉得看起来差不多，然后发贴来寻找认同 其次就是你想重构所有代码，坦白说，这是有巨大风险的 如果你真的这么做了，能承担的了后果吗？太以自我为中心了 |
 |
45
monmon 2023-11-23 13:39:01 +08:00
如果这个 Array 的长度是 1w ，你的代码给人的感官上有 9999 次 if(special) 的判断，虽然有 CPU 分支预测实际运行效率差异不大，但是这是可以人为避免的多余逻辑，另外代码终究是给人看的。
|
 |
46
jjwjiang 2023-11-23 13:47:26 +08:00 3
年轻人还是谦逊一点好；
一个简单的例子是，将来这个 if 需要查库，你的代码直接修改将会产生严重的性能问题以至于需要重构，而你 mentor 的代码完全不会有这问题。 |
 |
47
WytheHuang 2023-11-23 13:52:28 +08:00
我个人可能倾向于你 mentor
|
 |
48
fzdwx 2023-11-23 14:14:24 +08:00
mentor 的好，少了 n 次判断
|
 |
49
otakustay 2023-11-23 14:16:12 +08:00
除了那个 len(array) - 1 会少循环一个元素外，整体我认同你 mentor 这个代码。把正常处理和特殊处理分开，逻辑表达上也更清晰
|
 |
50
pigspy 2023-11-23 14:18:21 +08:00
你 mentor 的明显好
一段代码只干一件事 |
 |
51
suiterchik 2023-11-23 14:27:07 +08:00
各有各的优劣吧
* 你的写法对未来业务逻辑的变更会方便一些，比如现在只是对最后一个元素处理，那未来可能会对命中某些逻辑的元素处理，那么这种情况下你的代码改起来会容易一些 * mentor 的写法少一些 if 判断，能带来一些性能上的优化，不过编译器和 JIT 估计会优化掉，所以可能性能上差异不会特别大 对于这种影响不大，属于代码风格方面的差异，那就遵循公司整体的代码风格吧，同一种风格利于长期的维护和迭代。对于有性能风险（跑得快不快）、维护性风险（后期逻辑好不好变更）、稳定性风险（挂了会不会影响其它逻辑）等，那么就对等沟通，对事不对人呗 |
 |
52
gimp 2023-11-23 14:30:01 +08:00
同认为你 Mentor 的代码好。
你的写法把特殊逻辑放在通用的循环中处理，首先是增加了无效判断，其次代码耦合度更高。 |
 |
53
zjj19950716 2023-11-23 14:31:50 +08:00
你的好， 空 array 不会报错
|
 |
54
visper 2023-11-23 14:32:50 +08:00
无所谓了,能跑就行,都差不多,不在乎这种性能.
|
 |
55
abc1310054026 2023-11-23 14:34:35 +08:00
除开一些有比较高性能要求的项目，都应该按规范行事。规范带来的统一能够极大提高项目的可维护性。自己的偏好可以体现在自己的项目里，遵守规范是专业性的体现。
|
 |
56
nevermoreluo 2023-11-23 14:37:26 +08:00 12
youtube 上有个 CodeAesthetic ，感觉可以看下。有一期讲的 Never Nester ，还是有部分道理的
像我这种野路子常年代码畸形的人，时常要翻出来再看下 找到了， |
 |
57
InkStone 2023-11-23 14:38:02 +08:00
你 mentor 的写法比你的强太多了……
虽然在现代的 CPU 分支预测下这个 if 判断的代价不大，但无端地在循环里多跑一条指令和潜在的分支预测失败，完全是无谓地给 CPU 上强度，而且还没提高可读性与可扩展性。 前面看到你说起 OI ，请记住 OI 里大多数的编码习惯在实际工程中都是糟粕，别代入到工程中。 |
 |
58
nuk 2023-11-23 14:46:31 +08:00
个人觉得你写的好，一来理解很容易，二来更容易扩展，至于判断的性能消耗，可以忽略不计。
类 C 语言这种< len ，或者<= len - 1 ，完全就是折磨，你的 mentor 是 C 陷阱与缺陷的忠实读者吧 |
 |
59
ganbuliao 2023-11-23 14:48:51 +08:00
这个不是和 mentor 代码习惯不一样
是你的习惯不好 导致 代码可读性和性能的问题吧 （写代码的思路不对） |
 |
60
yaocai321 2023-11-23 14:51:05 +08:00 1
从职业发展来说，听大哥的。
从代码风格上说，平铺当然比嵌套好，所以听大哥的。 最后说下我工作的态度： 1.有不同见解肯定会提出来讨论。 2. 没法达成一致，没有原则性前提下，我不会跟其他人争到底。 3. 至于对与错，表面上我奉行 "你都对", 实际上我会自我过滤，认真的参考别人的想法，然后取其精华去其糟粕。 |
|
61
idealhs 2023-11-23 14:59:34 +08:00
看来名校出来的也就那样，跟我们垃圾学校没太大区别。工作了如果能遇到愿意带的，哪怕不是那么大佬，抱紧了跟着学才是真学到。干个几年再回头看自己写的是些啥玩意吧。
|
 |
62
ldyisbest 2023-11-23 15:03:18 +08:00
如果你觉得你的写法好，就据理力争，否则就听老大的
|
 |
63
ZxykM 2023-11-23 15:03:45 +08:00
从给的例子来看，我更喜欢你 mentor 的风格，一眼就知道干了什么
|
 |
64
Vclow 2023-11-23 15:10:21 +08:00
你问他改成这样对比原来的有什么好处呗
|
 |
65
Orenoid 2023-11-23 15:22:30 +08:00
你成功把两个负责不同职责的逻辑揉杂在了一个 for 循环里，读这段 for 循环的人得同时关注两个逻辑
|
 |
66
listenerri 2023-11-23 15:24:38 +08:00
除了每次都比较索引的影响外，那个特殊判断写在 for 循环里，尤其是 for 循环里还做了其他事，会容易让读者忽略掉特殊处理最后一个元素的逻辑（或者直觉 for 里没什么特殊的东西），而单独写在外面时，针对最后一个元素的处理意图就比较明确和清晰
|
 |
67
sockpuppet9527 2023-11-23 15:27:19 +08:00
试想一下 lz 举得例子是最底下的 N ，上面是一个 NP ，那就知道你的 mentor 让你改是多么正确的一件事了。
|
 |
68
Leviathann 2023-11-23 15:29:22 +08:00 1
不是哥们，都写 go 这种东西了还在意什么代码风格？那我问你 15:04:05 是什么风格？
官方带头拉屎的语言，说什么就是什么呗，浪费一秒算我输 |
 |
69
fredweili 2023-11-23 15:40:00 +08:00
鸡毛蒜皮
|
 |
70
MuSeCanYang 2023-11-23 15:43:31 +08:00
眼高手低
|
 |
71
forgottenPerson 2023-11-23 15:56:29 +08:00 via Android
你写的每次还要多做一个判断，你负责人那种一个循环就一个逻辑，之后再处理最后一个元素的逻辑。你静下来好好看看，很明显你负责人那种好点啊。这真没说的。当然了都能运行，但是你负责人那种好点。
说实在的也是你名校出来的，要是去个一般的公司，你看你挨说不，你负责人真挺好的。你的话还是要多看，多指教，就看你这个问题，你负责人确实好一些，多向他学习。 |
 |
72
nagisaushio 2023-11-23 15:58:05 +08:00 via Android
楼主你不妨说说你觉得你写的哪里好了
|
 |
73
RainCats 2023-11-23 15:59:15 +08:00
当别人指出我代码的修改意见时我是很高兴的，平时也会去看同事的代码，有好的我就学过来用
|
 |
74
cyberCat 2023-11-23 16:02:02 +08:00
循环里放 if ？去了解下分支预测提高下水平。
名校出身，本事不高，架子不小。 |
 |
75
pultako 2023-11-23 16:11:02 +08:00
涉及到下标操作和 range 操作对比的，统一使用 range 。
|
|
76
forgottenPerson 2023-11-23 16:14:34 +08:00 via Android
同问，为啥 op 觉得这是可读性问题，我不太理解。
|
 |
77
kdd0063 2023-11-23 16:15:01 +08:00
- 名校很了不起？这行当最不缺名校的
- OI 的很多风格用到工程里就是 shit - 你那么多次无效 if 怎么来的自信？ - 你就是 CMU 科班的，团队有编码规范一样要遵循 |
 |
78
abcdexx 2023-11-23 16:21:51 +08:00
一串英文字母 我踏马看半天 [乐]
|
 |
79
Rorysky 2023-11-23 16:21:56 +08:00
王自如：刚毕业的学生应该有空杯心态
|
 |
80
liyunyang 2023-11-23 16:25:02 +08:00
我站你的导师，导师这样确实负责
|
 |
81
huangliu 2023-11-23 16:30:25 +08:00
看到大家都觉得你 mentor 的写法更好，我就放心了
你要相信能做你 mentor 是有原因的 |
|
82
forgottenPerson 2023-11-23 16:39:00 +08:00 via Android
刚毕业，想独当一面大家都能理解，但是有些编程思路真地值得好好学习，以及一些场景怎么去做，怎么去思考，你现在有这么个负责的负责人，得把握住机会，多向他指教，很多人没你这个机会的，都是直接开干，还要做其他事情，俗称打杂，并不是一直就写代码，能一直从事主职真挺不错的。
比如一个判断，只要一个元素根据条件不满足，就返回，一般的思路是先去循环判断这个不满足的条件，而不是在循环里去逐一比较满足的条件 |
 |
83
windshadow 2023-11-23 16:40:04 +08:00
再怎么名校，进到企业也都是菜鸡，不要太高估自己。
|
 |
84
ansnail 2023-11-23 16:41:29 +08:00
刚工作的小伙伴貌似都觉得把代码写简洁就是最牛 B 的，但工作多年的感觉是除非你是单打独斗，否则代码的可读性永远是第一位的，特别是在团队中，当然了基本的效率还是要有的
|
 |
85
zhdi 2023-11-23 16:50:41 +08:00 2
就你举的这栗子。。。循环里放 if ，每次循环都 if 一下，你还觉得是代码习惯问题？
大概测试了一下，没有缓存的情况下后一段是前一段时间的 400%，有缓存的情况下是 200%，所以这叫代码习惯？这叫你不懂底层还不愿意学习。。 |
 |
86
F1reman 2023-11-23 16:53:21 +08:00
且不说上面说的什么分支预测你能不能理解
你这两段代码运行起来 debug 一下，你就能知道你 debug 每一次都要多按一下了 |
 |
87
ArianX 2023-11-23 16:56:03 +08:00
mentor 的代码确实好一些啊，简洁性可读性性能都会好一些
|
 |
88
runzekk 2023-11-23 16:59:44 +08:00
不要有自己的风格。
一个项目同一个风格才是最屌的。 不要刚开始就形成了自己的风格了，风格这个东西没有好坏，一定要和之前的保持一致。 |
 |
89
sechi 2023-11-23 17:08:26 +08:00
too young, too simple, sometimes naive
 |
 |
90
candidcrat 2023-11-23 17:15:01 +08:00
这和代码风格没有关系吧, 这个例子, 功能要分开, 要我写两个写单独方法, 杂糅在一起是不好的
|
 |
91
williamscorn 2023-11-23 17:17:17 +08:00
看你的代码，对这个数组的所有元素其实都先做了处理，然后对最后一个元素做了特殊处理，那这个特殊处理完全可以拿到循环的外面来做吧，根本不需要放在循环里:
for i:=range array{ // do sth normal to array[i] } // do sth special to array[len(array)-1] |
 |
92
fulvaz 2023-11-23 17:20:39 +08:00
你 mentor 没错，听他的
|
 |
93
oceana 2023-11-23 17:35:13 +08:00
你 mentor 没错，一是没有无效循环，二是分开两块逻辑
|
 |
94
momogzp 2023-11-23 18:02:27 +08:00
站你 mentor, 代码是写给人看的. 可维护也是非常重要的一部分.
你代码的可维护性就没你 mentor 的好, 更不用说其中可能存在的性能损耗了. 学吧, 学无止境. 太深了.jpg |
 |
95
DefoliationM 2023-11-23 18:15:09 +08:00 via Android
第二个好，尽量减少逻辑嵌套，第二个可以直接把 for 嵌套 if 去掉，显然第二个好。
|
 |
96
Huelse 2023-11-23 18:21:21 +08:00
不管如何学习期间请先尊重 mentor ，如果你觉得难受就想如果有错也是 mentor 的锅，等你自己能独立完成项目了再按自己的想法来。
总得来说就是先学习后创改进，不要自作主张，哪怕你真的是天才。 |
 |
97
houshuu 2023-11-23 18:21:38 +08:00
就这个范例来说, 我觉得第二个好.
上下两个逻辑分的越开越清晰. |
 |
98
Baoni 2023-11-23 18:23:21 +08:00
代码真看不出好坏的话，应该是品味有问题。
我才是惨，我觉得我之前的 mentor 是你这样的，能跑就行的心态还看不上别人的修改，甚至有时不能跑，一看里面一堆 bug ，辛辛苦苦帮改了，他还讲其实是小 bug 。不过自信心和吹牛能力是真的强，说话官场味十足。 多希望能和你换个 mentor 。4 赢。 |
 |
99
vacuitym 2023-11-23 18:23:51 +08:00
我觉得第二个明显更好，第一个判断要执行 len-1 次
|
 |
100
43n5Z6GyW39943pj 2023-11-23 18:24:41 +08:00
有大佬带你,好好学
|
Select Language