这是一个创建于 367 天前的主题，其中的信息可能已经有所发展或是发生改变。
代码密度太低了，经常要这么写：
1: var val string
2: if ok {
3: val = "okay"
4: } else {
5: val = "fail"
6: }
即使优化一下，还有：
1: val := okay
2: if !ok {
3: val = "fail"
4: }
要是 kotlin,swift, java, c++, c ，来得多快啊，尤其很多个这种条件初始赋值的时候，看版面，就像在搞笑似的。
 |
1
zhwguest OP java,c,c++也不错
|
 |
2
wojiugaiming 2025 年 1 月 19 日 via Android  2
喜欢 golang 喜欢的不得了
|
 |
3
poltao 2025 年 1 月 19 日
学会与自己和解，不要在意这些细节
|
 |
4
aloxaf 2025 年 1 月 19 日 1
google 的语言设计水平和 MS 比就是一坨翔（用 golang 和 dart 有感
|
 |
5
SethShi 2025 年 1 月 19 日 1
|
|
6
SethShi 2025 年 1 月 19 日 3
 |
 |
7
youyouzi 2025 年 1 月 19 日
前端表示很平和，和 js 逻辑一样
|
 |
8
kandaakihito 2025 年 1 月 19 日 1
go 的设计思想确实神奇，缺少很多特性。一查为什么没有，固定回答基本都是 “你自己可以手搓，那样更加 clear”
|
 |
9
w568w 2025 年 1 月 19 日
@seth19960929 #6 这个很多时候不能平替条件运算符。比如如果 v1 、v2 是有副作用的，或者要执行很耗时的计算，那就没法用 When 了。
---- 另外 Go 就是 Google 做出来解决自己需求的，如果你觉得写起来难受，说明你的使用场景和 Google 那帮人不一样，就别硬用了。 |
 |
10
hefish 2025 年 1 月 19 日
这样不是挺好嘛，能把工作量提高啊。。。
|
 |
11
dobelee 2025 年 1 月 19 日
这个确实很迷，还是保留 c++的三目运算符好一些。
|
 |
12
DefoliationM 2025 年 1 月 19 日
推荐使用 java,没必要和自己过不去，用自己喜欢的就行了。
|
 |
13
v1 2025 年 1 月 19 日
10 年前用 php 的时候也是有一群人喷不是强类型 = =| 其实不影响赚钱就行了，如果是自己的项目建议换自己喜欢的语言。
|
 |
14
guanzhangzhang 2025 年 1 月 19 日
那要是来个说受不了其他语言作用域的呢
 |
 |
15
doraemonki 2025 年 1 月 19 日 via Android
如无必要勿增实体
|
 |
16
xuxu555 2025 年 1 月 19 日
hhhh, golang 确实是这样。不过不得不说，除了这个 err 判断繁琐点，其他真的挺简洁了。
|
 |
17
csys 2025 年 1 月 19 日 1
最简洁直观的:
var val = if ok "okay" else "fail" 或者 var val = ok match { true => "okay", false => "fail" } |
 |
18
liuliuliuliu PRO 推荐试一下 C# 😊
|
 |
19
akira 2025 年 1 月 19 日
这种小事情。。真不重要了。。
|
 |
21
Leviathann 2025 年 1 月 19 日
@doraemonki var val string 和下面的两处 val =，都属于无必要又增实体
|
|
22
doraemonki 2025 年 1 月 19 日 via Android
@Leviathann 从 Go 语言的设计哲学出发考虑，引入三元表达式增加的复杂度远超带来的收益，增加了理解难度还带来了代码风格的问题(深度嵌套的写法一定会出现)，普通的 if else 是最常用的写法，足够简洁，即使是初学者也能一眼看懂
|
 |
23
fregie 2025 年 1 月 19 日 4
代码密度高不一定是好事，越是简化的高级语法越难读，项目规模上来后简直是灾难
满屏的高度浓缩三元表达不头疼吗 |
 |
24
SakuraNite 2025 年 1 月 19 日
学会与自己和解，不要在意这些细节，能解决问题就可以了
|
 |
25
extrem 2025 年 1 月 19 日
总结一下就是，引入一般的三目运算符会导致在很多场景下与当前“go 哲学”相悖的用法出现，弊大于利，而在当前的计算机语言演进道路上又没有找到更好的办法了，所以索性维持现状
|
|
26
extrem 2025 年 1 月 19 日
我之前也经常要吐槽但后来发现确实是没办法，这些软件构建的基础设施的设计要考虑的比让我们不爽的点多得多，所以少即使多，没有完美的语言只有完美的选择
|
 |
27
proxytoworld 2025 年 1 月 19 日
没有三目运算符确实难受
|
 |
28
LaTero 2025 年 1 月 19 日 via Android
@extrem 有更好的方法呀，把 if 从 statement 改成 expression 就行，很多现代语言都支持类似这样的：
var v = if (pred) a else b |
 |
29
ixixi 2025 年 1 月 19 日
不喜欢就不要用，干嘛委屈自己
|
 |
30
zgcwkj 2025 年 1 月 19 日
你是想说没有**三目运算符**？
|
 |
31
lekai63 2025 年 1 月 19 日 via iPhone
比较适合“按代码行数算绩效”的公司使用 🐶
|
 |
32
victorc 2025 年 1 月 19 日
你去用两天 rust
回来看 go 哪哪都好 |
 |
33
sealinfree 2025 年 1 月 19 日
改写为 go 的形式
// When 三元表达式 func When[T any](Check bool, TrueVal, FalseVal T) T { if Check { return TrueVal } else { return FalseVal } } |
|
34
sealinfree 2025 年 1 月 19 日
使用效果 aaa := When(1 == 1, 1, 2)
aaa 值为 1 |
 |
35
sagaxu 2025 年 1 月 19 日 1
|
 |
36
redbule 2025 年 1 月 20 日
如果你觉得不优雅，那么只有 pattern match 能满足你了。
|
 |
37
bzj 2025 年 1 月 20 日
没看懂有什么问题
|
|
38
bzj 2025 年 1 月 20 日
你应该就属于那种认为 PHP 是全世界最好语言的群体
|
 |
40
sch1111878 2025 年 1 月 20 日
@youyouzi 你平时不用 value ? 1 : 2 吗
|
 |
41
AV1 2025 年 1 月 20 日
@sagaxu
要惰性求值只能用 callback 了，不过 go 似乎没有箭头函数或者 lambda 表达，用起来依然很麻烦。🤣 func when[T any](value bool, trueCallback func() T, falseCallback func() T) T { if value { return trueCallback() } else { return falseCallback() } } |
 |
42
wangritian 2025 年 1 月 20 日
这种小事无所谓吧，需要的自己手搓，语言最重要的还是生态
|
|
43
zhwguest OP |
 |
44
KimiArthur 2025 年 1 月 20 日 via Android
@aloxaf dart 语法不是很简单明了吗？
|
 |
46
spritecn 2025 年 1 月 20 日
java 已经习惯 了这么写
``` if a return a; ``` |
 |
47
ikaros 2025 年 1 月 20 日
你可以用 rust 啊
|
 |
48
A5SqQoWI1DOXm7Y7 2025 年 1 月 20 日
这都不算啥，关键是不同小版本之间还语言不一致，这就恶心了
|
 |
49
ryan961 2025 年 1 月 20 日
如果这么写呢？
 |
 |
51
Felldeadbird 2025 年 1 月 20 日
哈哈，这就不得不提 go 没有三目运算符的事情了。
|
 |
52
Rehtt 2025 年 1 月 20 日 via Android
golang 的优点是不管水平高低写的代码都能一眼看懂 提高协作效率
|
 |
53
uds9u32br 2025 年 1 月 20 日
虽然我挺喜欢 go 的，但是我寻思三目加上去也不太影响可读性啊。
|
|
55
youyouzi 2025 年 1 月 20 日
我想着是上面代码也没毛病啊，就算不用三目，直接 if else 问题也不大啊
|
 |
56
crayygy 2025 年 1 月 20 日 1
@uds9u32br 三目本身没有影响，但不能阻止有人往三目里面再多加几次三目，我看过几次我们的 C++ 代码里面这么写的，给人恶心坏了，宁可啰嗦一点。所以我喜欢 Java 和 Go ，虽然啰嗦，但是适合工程化，大家写出来的代码都差不多
|
 |
57
fffq 2025 年 1 月 20 日
自己搓个三目 func ，多大点事
|
 |
58
vfs 2025 年 1 月 20 日 1
跟你相反， 我就是喜欢它要求的这种。 感觉代码读起来很清整，赏心悦目的。
|
 |
60
fuhanfeng 2025 年 1 月 20 日
我在想 go 的设计者自己会不会也不爽某些写法，但又担心一直加特性破坏 go 设立之初的目标，然后内心十分纠结
|
 |
62
fioncat 2025 年 1 月 20 日
你需要 rust
let val = if ok { "okay" } else { "fail" }; |
|
63
nxcdJaNnmyF9O90X 2025 年 1 月 20 日
脑子有坑吧 这也来黑 用不惯回去用抹脚布
|
 |
65
funnyecho 2025 年 1 月 20 日
看评论才直到，op 想要个三目？
我觉得优化后的那个版本已经很好了（初始化和条件分支要挨在一起）。后面加分支，那都是随手的事。 |
 |
66
me1onsoda 2025 年 1 月 20 日
写的恶心看的舒服
|
 |
69
x1aoYao 2025 年 1 月 20 日 1
尤其是在子作用域，返回多值的函数，只有其中一个想赋值修改外层的变量，其余的初始化
就只能提前定义其余变量，否则直接:=外层的变量就不是被修改而是遮盖了。Go 没有元组，这个就很别扭。 |
 |
71
yazinnnn0 2025 年 1 月 20 日
换家不用写 go 的单位吧
|
 |
72
faimin 2025 年 1 月 20 日 1
特性少也有好处，这样可以少一些炫技的骚操作，大家写出来的代码就都一样了，维护起来也方便😄
|
 |
73
zxjxzj9 2025 年 1 月 20 日 1
恰恰相反最喜欢 go 这种干掉三目运算符的做法。。。 确实不容易看花眼，多写几行没事的，特别是现在很多都是 ai 写的了
|
 |
74
zhaoahui 2025 年 1 月 20 日
Go 就图一个简单
|
 |
75
iyaozhen 2025 年 1 月 20 日
没懂，其它语言 if else 不这样写？楼主举个例子呢？
还是想要三目运算符？ 但这就是 go 的设计特性，语言的简洁。三目最大的问题是可以无限嵌套，看起来很麻烦 |
 |
76
xiaocaiji111 2025 年 1 月 20 日
@kandaakihito 我们业务用了，后面业务复杂起来，简直要痛苦死了。特性太少，刚开始非常轻量，后面要啥啥没有
|
|
77
xiaocaiji111 2025 年 1 月 20 日
@uds9u32br 对，总是说影响复杂度，复杂度，会编码得都能看懂三目吧，我怀疑是增加 go 团队得复杂度，而不是用户得，所以不加。
|
 |
78
CodingIran 2025 年 1 月 20 日
@ufan0 作为同时写 Flutter 和 iOS 原生的吐槽几点 Dart：
1.枚举不能忽略名称，静态变量（方法）不能忽略类名 ```dart currentConnectivityType: ConnectivityResult.wifi 👎 currentConnectivityType: .wifi 👍 ``` ```dart return Container(color: Colors.white, ... 👎 return Container(color: .white, ... 👍 ``` 2.函数方法默认值鸡肋 有默认值的参数必须使用 `{}` 包起来，而且必须放在方法的最后，甚至默认值只能是常量 😵💫 ```dart void foo(int arg1, { int arg2 = 0, int arg3 = 0 }) 👎 void foo(int arg1 = 0, int arg2, int arg3 = 0) 👍 ``` 3.必须显性的书写 const `EdgeInsets.only(top: 8)` 显然是一个常量，为何需要显性的写上 `const`，而不是编译器或 IDE 自动处理 ```dart padding: const EdgeInsets.only(top: 8) 👎 padding: .only(top: 8 ) 👍 ``` 4.残缺的 Optional ? ```dart class Foo { final int? count; void test() { if (count != null) { count += 1; ❌ count! += 1; ❌ } } } 上面的代码无法编译通过，因为 count 定义为 `int?`，即使已经判断了非空，获取它之前仍然需要 `unwrap`，只能写： count = count! + 1; 😅 ``` 5.异常处理理念落后 下面是个经典的 Dart 异常处理流程，存在 2 个问题： - 可能抛出异常的方法没有明显的标志，只能依靠文档和阅读源码来确定这个方法是否会抛出异常，因此调用时很难确定一个方法是否需要` try catch` - try 的 {} 内通常包含多个方法的组合调用，除非查看各个方法的实现，否则很难判断出哪些方法是会抛出异常的 ```dart // 定义一个可能抛出异常的方法 void functionCanThrowException() { .... throw Exception('xxxxxxx'); } // 调用 try { functionA(); functionB(); functionCanThrowException(); functionC(); } catch(e) { // handle error } ``` 6.反人类的 json 序列化 竟然需要借助 json_serializable 之类的插件才能完成其他语言自动实现的功能，生成一大堆 .g.dart 文件更是丑陋 |
 |
79
aladdinding 2025 年 1 月 20 日
只有一种写法不好吗
|
 |
80
jeesk 2025 年 1 月 20 日 via Android
|
|
81
jeesk 2025 年 1 月 20 日 via Android
语法糖 越加越多就成💩，
|
|
82
jeesk 2025 年 1 月 20 日
没吐槽到重点：
毕竟 if else 完全可以优化 func result(bool2 bool, first any, two any) any { if bool2 { return first } else { return two } } |
 |
83
ufan0 2025 年 1 月 20 日 1
@CodingIran 很久没有见到如此认真对待的回复了，让我找回了很多年前的论坛感受，回复中的其中几项，在我刚接触 Dart 的时候蛮苦恼的。
2. 个人还是蛮喜欢这个设计的，看起来清晰，review 代码的时候能够一目十行。关于默认值只能是常量，我接触的几个静态语言似乎均是如此设计； 3. 关于 const ，我并非编译领域大牛，不知道为何如此设计，前期看到很头疼，用习惯了后多数能通过 IDE （ Alt + Enter ）自动重构，倒也是习惯了； 4. 被困扰中，我也发现了该问题，并且此前在 Github 看过相关 issue ，目前仍为 open 状态； 5. 被困扰中，且 IDE 提示蛮鸡肋； 6. 此为做 UI 相关开发时候的取舍了，提升性能吧。换言之，如果不是开发 UI 相关，那么这个问题就不是问题了，我也在用 Dart 写后端。 |
|
84
AV1 2025 年 1 月 20 日
@CodingIran
有点不对吧，dart 的默认参数、可选参数是放在方括号[]里，而不是大括号{}里，比如 String say(String from, String msg, [String device = 'carrier pigeon']) {/**/} 而大括号{}里的参数，相当于 python 的关键字参数（**kwargs ）。 这倒也体现了 dart 函数参数声明的复杂，易混，难记。🐶 |
|
85
nxcdJaNnmyF9O90X 2025 年 1 月 20 日
@x1aoYao 月经贴 脑子有泡 就别用 go 啊 逼你用了吗 拉黑了 sbb
|
 |
87
youngzy 2025 年 1 月 20 日
三元在单层的情况下还好，但挡不住有人喜欢套娃
如果我看到 ` a ? b ? e : f : c ? d : e ? g : h ` 我肯定心态直接爆炸 我宁可放弃使用单层的三元也不想去看别人写的套娃 |
 |
88
Rickkkkkkk 2025 年 1 月 20 日
一种逻辑多种写法绝大多数情况下都是缺点，特别是写业务逻辑。
啰嗦不是问题 |
 |
91
kingcanfish 2025 年 1 月 21 日
@ryalu 你就说能不能跑吧！
|
Select Language