1
dreampuf 2013 年 7 月 20 日
项目保持一致,无二意就行。
一个交换函数命名为“灵魂守卫”,前端后端分为天灾和近卫,我觉得也妥当。 |
2
yuelang85 2013 年 7 月 20 日
写得多了,就有一些自己的模式了。。。。
|
3
YFZZ PRO 前端的话,按照自己的书写习惯和结构模式,制定一份命名规范,然后实践……
实践过程中,发现规范上不合适的地方,改进。 等到这份你自己的命名规范已经能满足自己绝大多数代码情况时,就OK了。 团队协作的话,那就要大家一起商量了。 |
4
fangzhzh 2013 年 7 月 20 日
我觉得最虐心的是: 程序排UI,排完运行看, 一看差一点, 然后再重拍
|
5
luikore 2013 年 7 月 20 日
1. 多练习比喻 (metaphor) 的修辞手法
2. 学习代数, 如果没有 x, y, xs, a, b 这些用法人类根本就不可能进步 |
6
jjgod 2013 年 7 月 20 日 "There are only two hard problems in Computer Science:
cache invalidation and naming things." -- Phil Karlton |
7
juicy OP @dreampuf 起个马马虎虎的名字,就会不自主地觉得特别别扭的。。然后就一直再想有没有更合适的名字,有没有,有没有,有没有。。。。然后,程序就写不下去了
|
8
juicy OP @xhslyf 团队协作倒还好,按照大家的习惯(虽然可能自己并不喜欢)或制定的规范命名,也不是很在意合适程度如何, 往往做自己个人的东西时还真没有给自己做过规范, 或许确实改定一个个人的代码命名规范了。。
|
10
violetmoon 2013 年 7 月 20 日
同感啊 感觉最纠结的就是给变量起名字了。。。
|
11
dongbeta 2013 年 7 月 20 日
起名和分类
|
12
vivianalive 2013 年 7 月 20 日
个人的话,可以按功能和模块来命名..然后横线,下划线,骆驼式的用法要固定一下.
比如: 几个单词放一下表示名字的用横线: maple-syrup-cookies (枫糖饼干) 表示属于某一分类中的一个对象用下划线: dessert_cookies (点心_饼干) 下划线和横线一起用: btn_hello-world.png 最重要一点就是,避免使用abc,xyz,123之类,因为人家可不知道funtion1和function2的作用分别是什么. |
13
mywjch 2013 年 7 月 20 日 强烈推荐看一下 The.Art.of.Readable.Code(2011.11 Dustin.Boswell) 和google的 [google-styleguide](https://code.google.com/p/google-styleguide/)
|
14
comcuter 2013 年 7 月 20 日
我觉得最虐心的是: 程序排UI,排完运行看, 一看差一点, 然后再重拍
+1 而且实在浪费时间. |
15
darasion 2013 年 7 月 20 日 我觉得写代码这种事情,有着天然的手工作坊性质,即便有各种所谓“现代化”的软件工程理论,还是不足以像传统工业那样,每个细节都能在设计时敲定,然后按部就班的完成。
实际中,很多时候都是写代码到最后,才发现某个事情无法实现,总有一部分代码白写了,总是到最后重构。总是修修补补改来改去。 比如检查一个机械零件是否合格,只要用尺子量一下就好了,每一个微米都有标准可以依据。 但是,要检查一坨代码是否真的没bug,或者现在可以用能不能能保证将来成为架构扩展的绊脚石,几乎没有一个统一的标准。总是连代码风格这种鸡毛蒜皮的事情都在争论不休。 |
16
someFork 2013 年 7 月 20 日
完全同感。
|
17
funcman 2013 年 7 月 20 日
放弃完美主义吧。
|
19
jiyinyiyong 2013 年 7 月 21 日
这太高端了吧.. 每天忙改 Bug 的表示膜拜
取名字这事情能比调试异步界面纠结的逻辑更改难吗? |
20
treo 2013 年 7 月 21 日
a1 a2 a3 多简洁
|
21
txx 2013 年 7 月 21 日 via iPhone
曾经打开一段 团队里的人写的 算法性质很强的类,变量名全都是x,xx,xxx,_x,_xx。。。。我杀了他的心都有
|
22
so898 2013 年 7 月 21 日
我的前任自从看到我的一大排TestLabel之后,就拒绝读任何我写的代码了……
尼玛那些确实是用来测试高度的啊!!!!! |
23
bitsmix 2013 年 7 月 21 日
来写 js 吧。。。
|
24
clino 2013 年 7 月 21 日
|
25
xhbeca9 2013 年 7 月 21 日
学习
|
28
walkingway 2013 年 7 月 21 日
|
29
juicy OP @walkingway 好的,谢谢~
|
30
alexrezit 2013 年 7 月 21 日
|
31
falconeye 2013 年 7 月 21 日
深有感触,命名是个大学问。
最好有一个命名规范,或命名字典,供大家查阅,以便保持统一。 |
32
damngood 2013 年 7 月 21 日
大家可以举些例子出来作为类似于 naming pattern 的东西 (嗯, design 可以有pattern, naming 应该也可以有吧. :) )
比如我最近一个场景: 一个对象创建的时候只赋予了一些简单的属性, 比如 id, name 等少量几个 然后在一个方法中会给其余的属性赋值, 然后我就纠结了怎么给这个方法取名字好了.. 最后只能想到 dressUP() 或者 inflate() 之类的.. 还可以有更好的吗 |
33
dalang 2013 年 7 月 21 日
坦白地说,命名对我来说也是大问题。表现在每次重看自己的代码,总觉得好多地方需要重命名。
有时候基于一些开源的项目做,命名还可以参考已有的代码,纯自己命名的时候不能让自己满意。 除了命名规范需要遵守外,英语差可能也是一方面原因吧 |
34
wupher 2013 年 7 月 21 日
我觉得最痛苦的部分是接着别人的写,而他写得像陀屎。更痛苦的是,你还无权更改这陀屎。
有次接了一个iOS项目,他们后台服务全是WebService,而iOS根本不支持SOAP,需要手动封装。所有的各种不同功能的业务服务,从登录到乱七八糟的各种业务,全都走一个WebService调用。这个WebService函数里面再走一个坑爹无比的XML。这个XML由各种乱七八糟的业务后台汇聚而来,这些业务后台涉及多家公司承建的系统。所以这个XML大家基本都当文本文件来玩了,根本无法校验,每个系统对他都有自己的理解。最后,当初是哪个混蛋设计的接口,里面一堆错别字,"field"都拼写不清楚,这种接口居然还开了设计评审会,那些人都是瞎子吗? 由于前述种种原因,我虽然极尽挖苦嘲弄侮辱他们的人格和智商,但是他们就是说接口无法修改(其它厂商配合原因、时间紧急、没有程序员、前任辞职,bluh, bluh bluh)。我居然也给它们对付过去了。 这是我做过的最痛苦的项目,没有之一。 |
36
yuelang85 2013 年 7 月 21 日
@wupher 我觉得最痛苦的部分是接着别人的写,而他写得像陀屎。更痛苦的是,你还无权更改这陀屎。
+1 还接过那种项目,接手代码还算是不错的代码,但是严重不符合自己需求。然后改啊改啊改,然后当领导问策划为啥项目做了这么长时间的时候,策划竟然说是因为程序在不愿意复用别人代码,不停的改啊改。。。。 |
37
Loveyuki 2013 年 7 月 21 日 唉。重构别人的代码这种事情,说出来都是泪啊。
一个月重构的我都快吐了。 |
42
cst4you 2013 年 7 月 22 日 via Android
我实在很讨厌团队里写html用什么div_1, div_1_3 这样命名的而且还是上下嵌套关系的。
哥们你要我哪找你们的关系去? |
43
fanghui 2013 年 7 月 22 日
深有同感,分层和功能结合命名
|
44
diligence24 2013 年 7 月 23 日
我觉得最痛苦的是差不多的功能重复写几遍,而且想破脑袋也感觉不能把这些方法复用。
|