前辈写的代码，要不你来解释一下？

[x77]

String get string {
  return switch (this) {
    Gender.male => "Male",
    Gender.female => "Female",
  };
}

[angrylid]

你周日发这个贴钓不到老前辈的。

[dode]

const obj = {
log: ['a', 'b', 'c'],
get latest() {
return this.log[this.log.length - 1];
}
};

console.log(obj.latest);
// Expected output: "c"

[way2explore2]

`if (a===1 && user.role==='admin') return true;`

我同事写的，我 review 时候建议，改成

`return a===1 && user.role==='admin'`
他说这样太复杂，另一个同事附议，太复杂，保留原样。


我无语😑

[HaroldFinchNYC]

@way2explore2 你可以跑路了

[xuanbg]

代码本身没什么毛病，逻辑清晰。获取枚举的名称嘛，这样写也不是不行啦。。。

[sadfQED2]

又不是不能用，那你说怎么写

[JasonLaw]

@xuanbg 更加好的设计不应该是 Gender 的一个属性吗？比如叫 desc ，male 的 desc 是 Male ，而 female 的是 Female 。

代码没问题，但是很难维护。

[hhjswf]

@JasonLaw 性别还有什么拓展空间吗

[Finnn]

@hhjswf 你不重视 LGBTQ... （逃

[JasonLaw]

@hhjsw desc 跟 gender 是非常紧密的东西，弄得这么远真的好吗？

[fregie]

@way2explore2 说明你同事比你想的更全面。
从自己写的爽的角度思考，代码越少越精简越好
从软件工程角度思考，代码越一目了然越好，语法越少越好，代码多少是其次

[JasonLaw]

@way2explore2 #3 这段代码更大的问题是命名，对我来说，我根本不知道 a 是什么。

BTW ，这个函数的名称是什么？

[terrytw]

这类问题不是很理解为何来回的讨论
正常公司不是应该有代码规范么
常见的逻辑如何处理，应该是标准化的呀？

[x77]

水贴。不过好像没人完全看懂啊

[Yunsheng]

你觉得精简的好，那你就写精简的。我觉得可读性好的我就写我认为可读性好的。有时候精简后的读起来其实需要在脑子里面转一下，可能我个人愚笨，如果只是写法的不同，我偏向可读性更高的。因为理解起来更顺畅。

[x77]

结帖，我应该说明这是 dart 代码。

- 这是一个 get 属性，属性名称 string ，返回类型 String 。
- switch 表达式根据 case 的内容判断 this 是 enum 实例。
- 返回“Male”和“Female”，而不用 enum 成员本身的名称（ Gender.male.name ），说明别的地方需要用 enum 得到特定 字符串。

所以，这是个 enum 扩展，类似于 enum Gender {male = "Male", female = "Female"}，为什么需要这个扩展，因为 Dart 不支持指定 enum 成员的值。

[Alalajiyh]

@way2explore2 还是有区别的。在不满足条件的时候第一种写法会返回 undefined ，第二种返回 false

[star7th]

我觉得，在不影响性能的前提下，永远是 可读性 比 代码量少 重要。

[star7th]

@way2explore2

我同意你同事的看法。

我觉得，在不影响性能的前提下，永远是 可读性 比 代码量少 重要。

[afx]

@way2explore2 哈哈哈，让我想起这个话题的原始话题下一堆人赞同前辈，只因为他们看不懂这种表达方式。写代码就像写文章，能否写出简洁优雅的代码考验的是程序员的表达能力。

[janus77]

1. 为了多语言
2. 为了预留产品可能改文案，比如改成帅哥美女这种
3. 为了预留更多的类型，比如 LGPT 等等
4. 屎山没改干净。
总之，你可以改，但是发个帖来问真的没必要

[way2explore2]

@star7th

我无语的点在于，这里边他没提升可读性。
只是不熟悉 JS 。

[way2explore2]

@Alalajiyh

他有 return false

他代码三行, 伪代码如下

If condition
Return true

Return false

我建议
Return condition

[way2explore2]

@fregie
请指教，可读性提升在哪里？

从我的角度看，他只是不会写 JS ，（他也确实是 JS 新手）

[way2explore2]

@star7th 请问，可读性提升在哪里？

[ma836323493]

@way2explore2 可读性在于对于弱类型语言，一眼能看出返回结果类型 和 判断条件

[lucasji]

@star7th #19 请问同事的代码的可读性体现在哪里？层主的代码直接返回 condition ，那么我在阅读这个 condition 并且思考过该 condition 何时为 true ，何时为 false 时，这个函数就已经结束了。但是同事的代码我不仅需要思考该 condition 为 true 或 false 的情况，更要去思考 if 块里面的逻辑。因为你使用了 if 模块，那么就相当于告诉其他人，我的代码依托于 condition 有额外的逻辑，但是同事的 if 块居然直接返回 true 或 false （这是 condition 已经表达过的意思），给人从思考上带来了无用的额外负担。

[ma836323493]

@way2explore2 另只不过是习惯而已，if 的那种根本一点都不需要动脑子， 而且后续 if 里如果还有其他操作，就必须这样写了

[ty29022]

你们真的是，绣花的事情争来争去，门槛低嘛，谁都能掰扯两句
喜欢雕琢细节大可以讨论一些更有意义的话题，比如命名呀，缓存友好呀，代码缩进和扁平化啊
只能说**严于律己 宽于待人**

[roycestevie6761]

这种代码以后都是 copilot 的工作了。一个 tab 键拿下

[hxysnail]

@ma836323493 @way2explore2 我想到一个比较粗鄙的类别，不要生气哈

这种写法，让我想起一句俗话：脱裤子放屁。放屁需要脱裤子吗？——似乎不需要，但脱了也不会死，而且万一放完屁后刚好还想拉屎呢？

虽然我也觉得放屁没必要脱裤子，但不同的人有不同的考量点。有的人愿意为未来的小概率事件未雨绸缪；有的人连火烧眉毛的事都为所谓；我老板也经常说，要干好一件事不容易，其中人是最不可控的因素。

所以最关键的是，找到志同道合的人合作。这也是物以类聚，人以群分的这句古话的含义。如果实在没有办法，那就捏着鼻子走呗，管它的

[FakerLeung]

@way2explore2
看后面还会不会来个 If condition2 Return true

[jifengg]

Dart SDK 版本 2.17 以上可用“增强枚举”。

https://dart.cn/guides/language/language-tour#enumerated-types

[3000codes]

@way2explore2 要看这个条件语句是否包含了所有条件,如果只有这一种情况发生,我赞同你的代码,大部分情况还是赞同你同事的

[way2explore2]

@3000codes 只有一种。

如果是多个条件，我当然不会建议缩写到一行啊。可能我举例的时候，说的不够详细。

```js
const isComplicated = (user:User):bool => {
if (user.role === 'admin' || user.role === 'manager' ) {
// 只有这一个 if condition
return true
}
return false

}
```
他写的代码，那两行代码，`return true, return false`, 看得我想吐 🤮
所以我 PR Review 里建议
=>

```javascript
return (user.role === 'admin' || user.role === 'manager')
```



然后他说，他自己写的更易读。另一个 Graduate 复议说，看不懂第二种写法。

[star7th]

@way2explore2 @lucasji

我没太认真看。
我的意思是建议使用这种明确 return true 或者 false 的方式。这样一看就知道返回布尔值。
直接返回一个表达式的可读性并不高，我要多看一眼去确认才知道他返回的仅仅是一个布尔值还是表达式后再运行什么再返回。

即 我认为

if( 1 === 1 && 2 === 2 ){
return true ;
}else{
return false;
}

比

return 1 === 1 && 2 === 2

的可读性好 。

[zaqzhin]

@way2explore2 666

[Alalajiyh]

@way2explore2 那完全没问题，不改变功能的前提下。我无理由支持你的写法