名称规范都需要见名知意，但是名称很长的时候一般怎么命名？ 先说我，根据英译取单词开头 1-3 组合完成
This topic created in 1904 days ago, the information mentioned may be changed or developed.
 |
1
没什么特殊情况的话长就长着，不乱缩，
|
1 |
2
可千万别瞎截取缩写单词，我真特么看不懂猜不到啊，更别学 k8s i11n 这种规则命名，谁特么看得懂啊
|
 |
RwingAug 20, 2021
3
长就长，不乱缩
|
 |
yyzclAug 20, 2021 via iPhone
4
很讨厌乱缩写的
|
 |
yolee599Aug 20, 2021 via Android
5
一般参考开源库来缩写，比如长度：len，接收：recv，缓冲区：buf，错误：err
|
 |
masterclockAug 20, 2021
6
const bsx = 0; 别缩写
const bySimpleXerox = 1; |
 |
7
Func HowtoNameLongVariable() {}
請勿縮寫。否則別人不會清楚。 我個人的話，在已知作用域的範圍內（ 5 行 - 8 行）會使用 i / x / e 等單個字母作為一些臨時變量。 |
 |
LeonardAug 20, 2021
8
长也没关系吧，规范比较重要，反正有代码补全。除非是已经约定俗成的，一般不缩写。
|
 |
gesseAug 20, 2021
9
每次看 java 变量名都是一种折磨
|
 |
lizytalkAug 20, 2021
10
this_is_a_long_variable_name
不乱缩，能看懂最重要。反正有 IDE，这个变量名本来也只有第一次会全打出来🐶 |
 |
wuxinlingAug 20, 2021
11
变量名长就长了，别缩。
时间长了，期间你另一个项目用到了意义不一但是缩写后差不多的情况，脑子半天反应不过来缩写了个啥。 https://github.com/hotvulcan/finance_i18n 财务类的不好翻译可以用这个 |
 |
ZFieldAug 20, 2021
12
长就长吧，缩写这东西真搞得人头大
|
 |
shakarakaAug 20, 2021
14
编译的时候都会去掉的，留着不行么，就怕用的时候不知道这是个什么鬼东西
|
 |
Inf1nityAug 20, 2021
15
我觉得命名能体现函数的意义并符合约定俗成的规范即可，一个意义模糊不清的短命名反而更让人难以接受。
|
 |
94Aug 20, 2021
16
有明确的缩写的可以用，比如说：Globalization(G11N)、Internalization(I18N)、Translation(T9N)、Localization(L10N)
或者 Development(Dev)、To(2)、For(4)的这种的。 没有共识的话，缩写容易翻车，自己隔一段时间回来看都会想不起来 |
 |
wangchonglieAug 20, 2021
17
@dfkjgklfdjg #16 看不懂....
|
 |
wangkun025Aug 20, 2021
18
不缩写。
|
|
94Aug 20, 2021
19
@wangchonglie #17，呃...那比如说 Input/Output （ IO ）....
或者说 DTO 、BO 、AO 、VO 、POJO |
 |
mxT52CRuqR6o5Aug 20, 2021
20
就让名字长着，反正 ide 你打前几个字母都能提示出来，根本就不会带来多少麻烦
|
 |
lap510200Aug 20, 2021
21
你说的是 java 吗，那又臭又长的变量名、类、函数名不用 ide 我是没法工作的
|
 |
tabris17Aug 20, 2021
22
长度不是问题，现代编译器都不会把变量名长度限制得很短。而且用 IDE 根本不会影响输入效率
|
 |
L5tEU4WX072p5P42Aug 21, 2021 via iPhone
23
长就长，不缩写，千万不要别错字。
|
 |
ethusdtAug 21, 2021
24
可以体验下汉语(狗头):
const 动态材质球的高光强度节点系数 = 0.8; const 动态材质球的贴图节点数 = 8; const 动态材质宿主的模型 = new M(); |
 |
HappyTrailAug 21, 2021
25
想起来我司某段代码
analyze 直接缩写 anal (手动狗头 |
Select Language