写程序最痛苦的部分。。。

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

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

这是一个创建于 4163 天前的主题，其中的信息可能已经有所发展或是发生改变。

渐渐地觉得，写程序最虐心的部分是命名的部分，写程序有很大一部分的时间卡在这个环节上了。

特别是写前端的程序，写html的时候，命名是一个有奠基性质的过程：想好各个部分的命名之后，后面整个过程就一路畅通了；当对命名稀里糊涂的时候，往往也就意识着你不是很确切地知道整个程序该怎么写。

可是命名这个过程真的好让人纠结！

命名

程序

部分

44 条回复 • 1970-01-01 08:00:00 +08:00

dreampuf

2013-07-20 15:49:21 +08:00

项目保持一致，无二意就行。

一个交换函数命名为“灵魂守卫”，前端后端分为天灾和近卫，我觉得也妥当。

yuelang85

2013-07-20 15:49:25 +08:00

写得多了，就有一些自己的模式了。。。。

xhslyf

2013-07-20 16:02:50 +08:00

前端的话，按照自己的书写习惯和结构模式，制定一份命名规范，然后实践……
实践过程中，发现规范上不合适的地方，改进。
等到这份你自己的命名规范已经能满足自己绝大多数代码情况时，就OK了。

团队协作的话，那就要大家一起商量了。

fangzhzh

2013-07-20 16:18:56 +08:00

我觉得最虐心的是: 程序排UI,排完运行看, 一看差一点, 然后再重拍

luikore

2013-07-20 16:20:55 +08:00

1. 多练习比喻 (metaphor) 的修辞手法
2. 学习代数, 如果没有 x, y, xs, a, b 这些用法人类根本就不可能进步

jjgod

2013-07-20 16:39:54 +08:00

"There are only two hard problems in Computer Science:
cache invalidation and naming things."

-- Phil Karlton

juicy

2013-07-20 16:43:43 +08:00

@dreampuf 起个马马虎虎的名字，就会不自主地觉得特别别扭的。。然后就一直再想有没有更合适的名字，有没有，有没有，有没有。。。。然后，程序就写不下去了

juicy

2013-07-20 16:47:33 +08:00

@xhslyf 团队协作倒还好，按照大家的习惯（虽然可能自己并不喜欢）或制定的规范命名，也不是很在意合适程度如何，往往做自己个人的东西时还真没有给自己做过规范，或许确实改定一个个人的代码命名规范了。。

juicy

2013-07-20 16:49:44 +08:00

@jjgod 不知道Phil Karlton是哪位大神，不过大神就是大神，讲出了最容易被忽视的精髓啊

violetmoon

2013-07-20 17:38:22 +08:00

同感啊感觉最纠结的就是给变量起名字了。。。

dongbeta

2013-07-20 19:55:59 +08:00

起名和分类

vivianalive

2013-07-20 20:34:26 +08:00

个人的话,可以按功能和模块来命名..然后横线,下划线,骆驼式的用法要固定一下.
比如:
几个单词放一下表示名字的用横线: maple-syrup-cookies (枫糖饼干)
表示属于某一分类中的一个对象用下划线: dessert_cookies (点心_饼干)
下划线和横线一起用: btn_hello-world.png

最重要一点就是,避免使用abc,xyz,123之类,因为人家可不知道funtion1和function2的作用分别是什么.

mywjch

2013-07-20 21:01:56 +08:00

强烈推荐看一下 The.Art.of.Readable.Code(2011.11 Dustin.Boswell) 和google的 [google-styleguide](https://code.google.com/p/google-styleguide/)

comcuter

2013-07-20 21:53:16 +08:00

我觉得最虐心的是: 程序排UI,排完运行看, 一看差一点, 然后再重拍

+1 而且实在浪费时间.

darasion

2013-07-20 22:09:31 +08:00

我觉得写代码这种事情，有着天然的手工作坊性质，即便有各种所谓“现代化”的软件工程理论，还是不足以像传统工业那样，每个细节都能在设计时敲定，然后按部就班的完成。

实际中，很多时候都是写代码到最后，才发现某个事情无法实现，总有一部分代码白写了，总是到最后重构。总是修修补补改来改去。

比如检查一个机械零件是否合格，只要用尺子量一下就好了，每一个微米都有标准可以依据。
但是，要检查一坨代码是否真的没bug，或者现在可以用能不能能保证将来成为架构扩展的绊脚石，几乎没有一个统一的标准。总是连代码风格这种鸡毛蒜皮的事情都在争论不休。

someFork

2013-07-20 23:47:33 +08:00

完全同感。

funcman

2013-07-20 23:55:49 +08:00

放弃完美主义吧。

regmach

2013-07-21 00:01:38 +08:00

@dreampuf
function Tb($a, $b){
//
}

jiyinyiyong

2013-07-21 00:31:18 +08:00

这太高端了吧.. 每天忙改 Bug 的表示膜拜
取名字这事情能比调试异步界面纠结的逻辑更改难吗?

treo

2013-07-21 00:50:02 +08:00

a1 a2 a3 多简洁

txx

2013-07-21 00:56:26 +08:00 via iPhone

曾经打开一段团队里的人写的算法性质很强的类，变量名全都是x，xx，xxx，_x，_xx。。。。我杀了他的心都有

so898

2013-07-21 01:36:33 +08:00

我的前任自从看到我的一大排TestLabel之后，就拒绝读任何我写的代码了……
尼玛那些确实是用来测试高度的啊！！！！！

bitsmix

2013-07-21 01:44:44 +08:00

来写 js 吧。。。

clino

2013-07-21 02:03:44 +08:00

http://agentzh.org/misc/slides/naming/naming.html
http://agentzh.org/misc/slides/naming/naming_recap.html

xhbeca9

2013-07-21 09:12:27 +08:00

学习

juntao

2013-07-21 09:18:48 +08:00

@so898 你的前任。。。。就是这么离开你的把。

最纠结的也是命名部分。

juicy

2013-07-21 09:53:07 +08:00

@clino 想成为一个好的程序员，必须先成为一个好的诗人。。。。。。

walkingway

2013-07-21 09:56:07 +08:00

建议楼主读读《代码大全》的第11章变量名的力量

http://book.douban.com/subject/1477390/

juicy

2013-07-21 09:58:16 +08:00

@walkingway 好的，谢谢～

alexrezit

2013-07-21 10:01:09 +08:00

我觉得大部分语言都有命名规范吧? 如果命名有困难多半是英语不好, 而程序员英语不好就像厨师切菜切不匀一样可笑至极.

@txx
你可以跟他对着干: txx, txxx, _txx.

falconeye

2013-07-21 10:55:23 +08:00

深有感触，命名是个大学问。
最好有一个命名规范，或命名字典，供大家查阅，以便保持统一。

damngood

2013-07-21 11:17:43 +08:00

大家可以举些例子出来作为类似于 naming pattern 的东西 (嗯, design 可以有pattern, naming 应该也可以有吧. :) )

比如我最近一个场景:

一个对象创建的时候只赋予了一些简单的属性, 比如 id, name 等少量几个

然后在一个方法中会给其余的属性赋值, 然后我就纠结了怎么给这个方法取名字好了..

最后只能想到 dressUP() 或者 inflate() 之类的..

还可以有更好的吗

dalang

2013-07-21 14:42:49 +08:00

坦白地说，命名对我来说也是大问题。表现在每次重看自己的代码，总觉得好多地方需要重命名。
有时候基于一些开源的项目做，命名还可以参考已有的代码，纯自己命名的时候不能让自己满意。

除了命名规范需要遵守外，英语差可能也是一方面原因吧

wupher

2013-07-21 15:39:04 +08:00

我觉得最痛苦的部分是接着别人的写，而他写得像陀屎。更痛苦的是，你还无权更改这陀屎。
有次接了一个iOS项目，他们后台服务全是WebService，而iOS根本不支持SOAP，需要手动封装。所有的各种不同功能的业务服务，从登录到乱七八糟的各种业务，全都走一个WebService调用。这个WebService函数里面再走一个坑爹无比的XML。这个XML由各种乱七八糟的业务后台汇聚而来，这些业务后台涉及多家公司承建的系统。所以这个XML大家基本都当文本文件来玩了，根本无法校验，每个系统对他都有自己的理解。最后，当初是哪个混蛋设计的接口，里面一堆错别字，"field"都拼写不清楚，这种接口居然还开了设计评审会，那些人都是瞎子吗？
由于前述种种原因，我虽然极尽挖苦嘲弄侮辱他们的人格和智商，但是他们就是说接口无法修改（其它厂商配合原因、时间紧急、没有程序员、前任辞职，bluh, bluh bluh）。我居然也给它们对付过去了。
这是我做过的最痛苦的项目，没有之一。

bcxx

2013-07-21 17:17:57 +08:00

@alexrezit 忘记了是哪门语言，貌似是 F# 还是啥，源码是按照字母表来排序的

yuelang85

2013-07-21 17:29:05 +08:00

@wupher 我觉得最痛苦的部分是接着别人的写，而他写得像陀屎。更痛苦的是，你还无权更改这陀屎。

+1

还接过那种项目，接手代码还算是不错的代码，但是严重不符合自己需求。然后改啊改啊改，然后当领导问策划为啥项目做了这么长时间的时候，策划竟然说是因为程序在不愿意复用别人代码，不停的改啊改。。。。