这是一个创建于 1948 天前的主题，其中的信息可能已经有所发展或是发生改变。
rt，大家平时写程序时，是怎样为自己不了解的东西命名的呢？
如果是编程的技术概念，那自不必说，即使是楼主这样不熟练的 CRUD 工人，也知道 db = database = 数据库之类的，可以比较容易地在命名中使用这种词。
但如果是业务概念，就不一定了。没有接触过财务知识的话，不太容易想到 应收账款 = Account Receivable = AR，面对一个涉及到应收账款的需求，在命名的时候就可能想不到用 AR 这个缩写。 我见过一些程序员把它命名为"data", "temp", "yingshou"等...这些显然都不是很妥当。
遇到这种情况，要怎么办呢？查字典是个办法，但不是永远有效。理由是，
1，专业性，做企业信息化的程序员可能要接触到人力资源、物资管理、财务、生产计划、客户关系管理、运输管理等很多专业领域，程序员的专业只是程序，对这些东西并不是很了解。在这种情况下，即使查词典，也有可能混淆表面相近的词，从而产生错用。
2，作用范围。有的概念是具有中国特色的，在英语中不能具备概念完全相同的词。有的概念甚至是公司内部的，离开了公司，即便是其他中国人，也只能"每一个字都认识，可是连在一起看时完全不明白"。
3，工作效率。如果程序员要对每个业务概念做翻译，势必要多花一些额外的时间，在旁人眼中可能就会成为工作效率低下的人。更不用说有时开发时间被压缩得很紧，如果查字典的次数过多，可能会导致工作不能如期完成，承担责任...
综上，如果是在一家工作语言为中文的公司做企业信息化（ CRUD ）做程序员，要怎样才能方便地做好命名工作呢？
如果是编程的技术概念，那自不必说，即使是楼主这样不熟练的 CRUD 工人，也知道 db = database = 数据库之类的，可以比较容易地在命名中使用这种词。
但如果是业务概念，就不一定了。没有接触过财务知识的话，不太容易想到 应收账款 = Account Receivable = AR，面对一个涉及到应收账款的需求，在命名的时候就可能想不到用 AR 这个缩写。 我见过一些程序员把它命名为"data", "temp", "yingshou"等...这些显然都不是很妥当。
遇到这种情况，要怎么办呢？查字典是个办法，但不是永远有效。理由是，
1，专业性，做企业信息化的程序员可能要接触到人力资源、物资管理、财务、生产计划、客户关系管理、运输管理等很多专业领域，程序员的专业只是程序，对这些东西并不是很了解。在这种情况下，即使查词典，也有可能混淆表面相近的词，从而产生错用。
2，作用范围。有的概念是具有中国特色的，在英语中不能具备概念完全相同的词。有的概念甚至是公司内部的，离开了公司，即便是其他中国人，也只能"每一个字都认识，可是连在一起看时完全不明白"。
3，工作效率。如果程序员要对每个业务概念做翻译，势必要多花一些额外的时间，在旁人眼中可能就会成为工作效率低下的人。更不用说有时开发时间被压缩得很紧，如果查字典的次数过多，可能会导致工作不能如期完成，承担责任...
综上，如果是在一家工作语言为中文的公司做企业信息化（ CRUD ）做程序员，要怎样才能方便地做好命名工作呢？
 |
1
boris1993 2018-12-18 14:04:56 +08:00 via Android
比如说应收账款是一个实体，那么首先创建类的时候，会写好 JavaDoc
``` /** * 应收账款 * <业务含义简短介绍> */ public class AccountReceivable { // 各种属性啥的 } ``` 代码里的话，一般就是 `AccountReceivable ar`这样子了 至于说从来不看 JavaDoc 的，我写了你不看，怪我咯？ |
|
2
boris1993 2018-12-18 14:07:01 +08:00 via Android
至于专业词汇的问题，我首先跟团队里懂业务的，甚至就是业务设计者沟通，这玩意的专业词汇是啥
如果行不通，则去 Google 搜索，然后参考相关文章或者维基百科英文版词条 |
 |
3
CruelMoon OP @boris1993 #1 谢谢回复，偶还以为自己被降了权。不过 Doc 这个东西是命名之后的工作了吧？偶的困扰时在这之前的命名工作，比如像一个需求是"发出商品转主营业务成本"，如果把 发出，商品，转，主营业务，成本 这几个词都查一遍词典，找到对应的英文名，好像很困难和麻烦...而文档中的业务词汇可能还要多不少
|
 |
4
clino 2018-12-18 14:09:35 +08:00
|
 |
5
newtype0092 2018-12-18 14:11:38 +08:00
如果不理解“应收账款”的含义不影响这块的程序逻辑，那么叫 temp 也可以吧，如果和逻辑相关的话，拿肯定是让别人先把业务了解清除了再上手。
总之变量名应该是辅助表达程序逻辑的，如果跟逻辑无关的话，强行用专业翻译反而是没事找事吧。。。 |
|
6
CruelMoon OP @newtype0092 #5 实践上还是有影响的，比如一个程序涉及到总账、应收、应付，程序中分别用 temp1, temp2 和 temp3 来命名，虽然不影响程序运行，但读程序的时候比较容易搞混。阅读者必须时时记得 123 的涵义，再把它和需求联系起来，会带来一定的心智负担。
|
|
7
CruelMoon OP @newtype0092 #5 编程的人可以不懂它们的业务意义，但一定要把它们和需求里的词联系起来，不然就没办法完成工作了。
|
 |
8
SeaRecluse 2018-12-18 14:35:32 +08:00  1
实际上影响就是挺大的，但是很多人的业务和类似的不沾边，或者开发的体量不够大，于是就忽略了这个房间里的可怕怪兽 —— 命名
最好定义一个变量名的长度，在此阈值内，不要缩写，超过之后，前缀缩写，实在无法做到前缀缩写的，最好写个文档转义一下。 |
|
9
CruelMoon OP @SeaRecluse #8 缩写这个东西确实有毒，偶前段时间离开了中国企业，进入一家外企。文档全部是英文的，确实不用关心翻译了，然而被各种缩写搞得也很头痛。一些缩写让老资格的程序员也看不懂，在开会的时候要频繁地查词汇表。有时文档里会有一些新发明的缩写或者生僻的缩写，也会造成一定的理解困难....
|
|
10
boris1993 2018-12-18 14:51:18 +08:00 via Android
@CruelMoon #3 是在命名之后。业务相关的专业词汇，要么是开发人员知道怎么写，要么就是去问业务专家，要么就是自己去查了吧，这是无法避免的事。
至于中文命名，我们团队目前不会这么做，我个人也不会主动这么做。对我来说，我宁可多去查词汇，也不愿意中英文输入法来回切换。 |
|
11
CruelMoon OP @boris1993 #10 好的，我想了下，Doc 可以在一定程度上改善后续维护者阅读程序时看不懂英文专业词汇的问题，它是有用的，不过好像没有解决全部问题。
假设是在一家中国公司工作，那么业务专家的工作语言可能只是中文，这个时候就要自己查了。有没有办法解决我提出的另外一个问题，也就是保证开发人员的翻译是可靠的？ |
 |
12
GeruzoniAnsasu 2018-12-18 15:22:55 +08:00
其实真的，支持 utf8 变量名是最好的
我倒是支持这种复杂命名直接上中文，比较麻烦的是数据库表名，感觉比较好的办法只能是缩写+留个翻译表 |
|
13
boris1993 2018-12-18 15:44:18 +08:00 via Android
@CruelMoon #11 要保证翻译的可靠性.....我只能想到参考维基百科、专业词汇词典，或者找懂得相关行业专业英语的人来协助......
|
 |
14
gz911122 2018-12-18 15:50:22 +08:00
有的真的很难翻译
比如之前在一个做互联网彩票的公司 命名让我脑细胞差点死光。。 比如山东十一运夺金这种 彩种名 还有和值 ，前三，等等这种玩法名 还有胆拖，复式，旋转矩阵这种投注方式。。 简直是噩梦 。。。 |
 |
15
flowfire 2018-12-19 09:48:16 +08:00 via iPhone 1
中文变量名了解一下
|
 |
16
jifengg 2018-12-19 13:19:52 +08:00
专业的怎么命名我没有太好的意见。但是像用 temp，flag，tag 这种无意义的词来表示有意义的字段，最好是不要。
之前有个同事写逻辑的时候喜欢用 flag 来表示“某个状态是否达成”，但是后来他自己都忘记 flag=true 是表示“是”还是“否”了。 |
 |
17
xuanwu 2019-05-07 10:42:58 +08:00
@GeruzoniAnsasu MySQL 表、列也可以（ unicode ）中文命名。
|
Select Language