PHP同事（本组组长）不懂英文，变量名命名有时会张冠李戴？该提醒他么？

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

This topic created in 4735 days ago, the information mentioned may be changed or developed.

数据库命名也不好，方法名命名也不好。我每次看到他的变量名，都不敢通过他的变量名去推测意思，要上溯一下源码。
而且我还觉得有些命名特别别扭。
于是无明火起。曾经用比较委婉的语气指出他数据库表名命名不合理。但指出的时间比较晚，他都把表建好了。他也没改。我也没坚持。
其实他的代码bug还是比较少的，精于SQL。
我是否应该继续坚持“纠正”他。或者有什么其他好方法？

Supplement 1 · May 31, 2013

他的一些例子：
getContractMemo // 返回合同的基本信息
foreach ($this->contract_list as $list) // 其实我他的意思是 foreach ($this->contract_list as $contract)
public function editContractStatus($contract_id, $code) { // 其实code的意思是 status_code
backWardsCustomer // 客源信息反写处理
TradeAllocation // 交易配置
ContractAccept // 合同受理人
ContractChores // 回访记录
`fees_id` int(11) NOT NULL DEFAULT '0' COMMENT '费用类型ID(冗余)',
`financial_fees_type` int(1) NOT NULL DEFAULT '0' COMMENT '收费对象 0=>买方,1=>卖方',

当然，我肯定是专挑他的不好的命名说的。他的命名并不是总这么不靠谱。

写完这些之后，我发现我的心里好受多了。我并不像之前那么憋闷了。我想我找到解决方法了：保持内心的平和，坚持学习英语。

命名

变量名

数据库

38 replies • 1970-01-01 08:00:00 +08:00

isy

May 31, 2013

难，习惯难改，如果是不好相处的，反问你一句 , 你自己的命名很好么！

xunyu

May 31, 2013

建议用拼音代替吧

alexrezit

May 31, 2013

这种人最可怕. 超级可怕.

Zhang

May 31, 2013

拼音更加可怕！！

zhttty

May 31, 2013

既然他是你组长，那么你就要习惯他的命名，作为团队，很多标准是以leader为首的。

qiukun

May 31, 2013

php 木有好用的更名工具吗？

qiukun

May 31, 2013

前几天群里还在说干脆用中文

Livid

MOD

PRO

May 31, 2013

你把他的命名列出来让大家看看吧？

raincious

May 31, 2013

@qiukun 真的，如果英文真的不好，那么干脆用中文算了（笑）。

我写程序的时候关于函数名倒是给自己定了个规矩，发上来给大家看看，顺便求参考和建议：

其实很简单的：

1: 命名规则，按照C语言常规的第二个单词首字母wordWord()分名法。
2: 第一个单词是动词，后面的单词是名词/要操作的对象
所以，常规的类似这样： getContent(); fetchContent();

当然，如果两个单词描述不完就会出现很长的名字：
最糟糕的类似这样： getContentByKeyName(); fetchContentFromDatabaseUsingEPollAndKeepMyCafeWarm();

3: 对于方法名，尽量只是用一个单词命名，因为操作对象已经有了，比如：
$content->fetch();

如果一个单词说明不了，就用常规规则：
$content->fetchByKeyName();

当然，类似还可以用fetch_by_keyname，只要形成一个标准，在程序里一直这样命名就可以了。

hongyz

May 31, 2013

我也有这方面的困扰，特别是看了Robert Martin的《Clean Code》之后。
感觉自己有干净代码强迫症了，看到团队成员的代码，命名不规范，无节操的缩进，提交代码库不写日志等等。相当痛苦。
遇到技术不好的技术经理，就认倒霉吧。
这种编程修养是很难调整过来的，年纪大的话。

PrideChung

May 31, 2013

@raincious iOS程序员表示对 fetchContentFromDatabaseUsingEPollAndKeepMyCafeWarm(); 这种命名十分习惯。
一开始还会给这类方法命名写类似这样的注释:
// fetch content from database using epoll and keep my cafe warm
后来发现注释不过是把驼峰式的方法名改成小写，然后用空格把单词分开了而已，默默删掉……

反而不喜欢 getContent(); 这样的命名，因为完全不知道get的是什么Content，类似的还有 getData() 之类的，说了等于没说。

果然是被洗脑了么，现在连写PHP的代码变量方法名都是死长死长的。

qiukun

May 31, 2013

@raincious
c 多用 under_line 式
cpp 多用 camelCase

做 App 而非 Lib ，团队又都使中文的话。中文命名没问题。具体可以把输入法调成半角的。（I'm serious.）

XDA

May 31, 2013

@PrideChung 你是在简介表达xcode的代码补全很强大么？

laihj

May 31, 2013

拼音吧。不懂英文也不能三天两头能解决的事，你提醒他什么，去学英文？

jiangplus

May 31, 2013

我的话直接踢了……

raincious

May 31, 2013

@qiukun 是的是的，我知道你是serious。

看到你上一个帖子我还在PHP里面将信将疑的试了下，结果真的可以。

瞬间汉语编程半满血复活，我真是笑到不行了。

function 相加($加数, $被加数) {
return $加数 + $被加数;
}

echo (相加(1, 1)); // 2

sojingle

May 31, 2013

@PrideChung 赞同！不是写开源组件的话，大多都不用再写注释了...

Golevka

May 31, 2013

顿时感觉我的Wait4Sema4也很无节操= =

jjx

May 31, 2013

如果是团队 , 表和字段应该是发在wiki上让全体开发人员审评通过, 因为这个可能所有人都要用

一个人开发就没有这个约束

不过很多行业软件的英文不好命名,就是专业的也弄不好,很多时候知其大意就好了

denger

May 31, 2013

@PrideChung
个人觉得这种 fetchContentFromDatabaseUsingEPollAndKeepMyCafeWarm 名命非常不友好。一个函数名应该只是传达这个是 “做什么的”，而无需要告诉别人它是 “怎么做的”（写注释的作用也是如此，大多数情况下）。 fetchContent 即可，简单明了，对于调用者不需要知道你用的是 EPoll实现还是从数据库中查。

>反而不喜欢 getContent(); 这样的命名

关键要看上下文，现在基本上各种语言已经支持 OOP 了。如果是这样呢：

class Topic:

def getContent(self):
// do something..

难道调用者会不知道 topic.getContent() 是干什么用么? 如果非要要写成 getTopicContent，那就有些废话了。当然，除非你用的是 C 语言或类似.

regmach

May 31, 2013

@raincious
getContentByKeyName();
这种很糟糕吗?
因为还有可能...byId,...byUser,...byXxx()
新鸟,勿怪

xuan_lengyue

May 31, 2013

@PrideChung 其实我也觉得你的方法名字太长了。。。
@denger Objective-C 方法命名最好的一点是语意很明确，比如说如果有获取天气的逻辑
C 系的语言可能会写成：
Weather getWeather(float latitude, float longitude, Time time);
如果后面跟的参数太多，很可能次序会写错，甚至有的时候连参数是什么语意都不知道。

Objective-C 的方法则是：
- (Weather)getWeatherForLatitude:(float)latitude longitude:(float)longitude time:(Time)time;
相对而言，每个参数前面都会有指示性的文字进行提示。

酱紫会导致方法名严重变长，但是会有更好的可读性，有时候甚至连文档都不用看，直接通过方法名就能知道什么参数对应什么。

我个人是喜欢后者，当然，萝卜白菜各有所爱啦。

如果fetchContentFromDatabaseUsingEPollAndKeepMyCafeWarm这个方法写成
- (Content)fetchContentFromDatabase:(Database)database using:(Method)method andKeepMyCafe:(Temperature)warm;
就更能体现 Objective-C 的优点了：）

denger

May 31, 2013

@xuan_lengyue
关于你的例子, Weather getWeather(float latitude, float longitude, Time time) 如果设计成:
Weather getWeather(Latitude latitude, Time time) 会不会更好？

关于如何避免参数长的问题，可以参考《重构:改善既有代码的设计》第三章代码的坏味道第四节 Long Parameter List（过长参数列）

PrideChung

May 31, 2013

@denger 所以说 Objective-C 是另外一个世界，因为整个Cocoa框架都是死长死长的命名风格…… 有些还在严格遵守最多80个字符一行的程序员初学 Objective-C 一定会抓狂的，方法名的长度就超过50个字符的方法不在少数。

@xuan_lengyue 不是我写的方法，我只是引用 @raincious 的例子，而且这种长度的方法或者函数名在 Objective-C 里面简直俯拾皆是，随便找一个: CVPixelFormatDescriptionRegisterDescriptionWithPixelFormatType。

的确Objective-C有一点很好的地方是参数的意义很明确，就算不查文档，也不可能写错参数的顺序。

JoyNeop

May 31, 2013

@regmach getElementById() 神躺枪……

zava

May 31, 2013

@zhttty -1
@picasso250 没有 code review 么？坚决讲出来，不讲出来绝对会难受。从某种程度上讲，会纠结这个的是好程序员。

birds7

Jun 1, 2013

你这不算极品额。。。上次给一家票务站做功能扩展的时候发现数据库压根没法读，英文缩写+拼音缩写+数字连注释都没有。。。

metaclass

Jun 1, 2013

也不是那么惨，看起来还是懂一点英语的

backWardsCustomer，这个backwards应全小写；TradeAllocation，配置用Configuration更通一点

不是什么大毛病，还好都可以理解，当然能规范那更好

venglide

Jun 1, 2013 via Android

记得以前有个文章讲接手一个项目，变量全是水果名。。。

xshadown

Jun 1, 2013

己所不欲，勿施于人。

Ricepig

Jun 2, 2013

其实也可能是英文水平确实稍差，加上没有良好的重构工具和时间，所以。。。也没必要无名火起。对于大家都要接触的东西（代码、数据库等），需要有一个约定。英语命名这个约定是个潜规则，但并不是一个强规则，语言本身也有模糊性。

此外，某些时候，有些概念你一时找不到完全精确的英文翻译，或者这个英文翻译转业到大部分人都不懂，这个时候约定一些其他的词汇来替代也不是无法接受的。