大家好,我是煎鱼。,在日常开发 Go 工程中,我们经常会用 fmt.Printf 或 fmt.Sprintf 去写类似的拼装字符串的业务。,如下代码:,这业务迭代迭代着,日积月累的,有一部分常变的拼装逻辑会来越长。小小的电脑显示屏已经不足以让代码在一行内显示了。,有许多特性会把字符串转为变量,但后面那串又臭又长的变量依然无法简单甩掉,因此有大部分同学会选择把代码格式化了。,如下代码:,你可能以为这是个例?实际并不,很多人都遇到了。,这在 Go issues 中社区讨论了三四年了,@Ian Lance Taylor 发起了新提案《proposal: spec: add simple string interpolation similar to Swift[1]》。希望能够得到更多的讨论,增加新特性解决这个问题。,这个新特性,类似于 Swift 中的字符串插值的简单版本。我们直接看例子:,对应的输出结果:,提案计划新增的 “字符串插值”,规范如下:,上面的例子中,以下几个都是字符串插值:,会有同学疑惑像 person 看起来就是结构体的是怎么取值的?,Go 有一个神奇的约定方法,像结构体这类类型,如果有 String() string 方法,将会调用该方法以获取字符串值。,如果没有 String 方法,需要是字符串、整数、浮点数、复数、常量或布尔值等类型,可以取值后格式化。否则将会报错。,当前的主要争论点之一,像是 fmt.Sprintf 等方法也可以完成字符串插值一模一样的效果,为什么还要新增这个功能特性(或是语法糖)?,主流观点是现有的格式化字符串的方法,在参数数量多了后,很容易出错(例如:顺序搞错),也比较松散,一大坨代码。,在新增字符串插值的特性/语法糖后,可以更好阅读、更好修改,不需要过于依赖编写变量的顺序、更紧凑。,具体的例子如下,现有版本代码:,应用新特性后会变成:,其实我们在工作中都经常遇到这个问题,甚至在 issues 中有同学反馈,他经常要写 50 个以上参数的格式化参数,在 Go 这维护起来比较痛苦。,如果你是长期维护某几个项目的开发者,不断持续新增、变更的现有格式化字符串的方法,和新增的字符串插值。,在接下来的几年中,你会选择哪一个?或是有没有新的想法?
文章版权声明
1 原创文章作者:cmcc,如若转载,请注明出处: https://www.52hwl.com/20557.html
2 温馨提示:软件侵权请联系469472785#qq.com(三天内删除相关链接)资源失效请留言反馈
3 下载提示:如遇蓝奏云无法访问,请修改lanzous(把s修改成x)
4 免责声明:本站为个人博客,所有软件信息均来自网络 修改版软件,加群广告提示为修改者自留,非本站信息,注意鉴别