我染上了 Objective-c 冗长命名的"恶习"

V2EX = way to explore

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

现在注册

已注册用户请登录

iOS 开发实用技术导航

NSHipster 中文版

› http://nshipster.cn/

cocos2d 开源 2D 游戏引擎

› http://www.cocos2d-iphone.org/

CocoaPods

› http://cocoapods.org/

Google Analytics for Mobile 统计解决方案

› http://code.google.com/mobile/analytics/

WWDC

› https://developer.apple.com/wwdc/

Design Guides and Resources

› https://developer.apple.com/design/

Transcripts of WWDC sessions

› http://asciiwwdc.com

Cocoa with Love

› http://cocoawithlove.com/

Cocoa Dev Central

› http://cocoadevcentral.com/

NSHipster

› http://nshipster.com/

Style Guides

› Google Objective-C Style Guide

› NYTimes Objective-C Style Guide

Useful Tools and Services

› Charles Web Debugging Proxy

› Smore

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

obj-c命名是很冗长的，相当冗长。我现在写js的时候，也会习惯用很长的命名方式，能从方法名看得懂的，一般不会用缩略语，除非是约定俗成的。
以前写js会采用非常短的命名方式，因为要考虑网络速度。但现在我认为没这个必要了，混淆时也会做出一些处理。
但对于公开的接口，我还是会尽量采用简短的命名方式。

命名

冗长

37 条回复 • 2014-05-12 14:05:36 +08:00

PrideChung

2014-05-10 10:10:38 +08:00

这是美德，不是恶习。

leavic

2014-05-10 10:48:30 +08:00 via iPad

这是好习惯啊

undozen

2014-05-10 10:52:59 +08:00

@tualatrix

lm902

2014-05-10 11:10:25 +08:00 via iPhone

知足吧，看看.NET的命名。。。

wvv8oo

2014-05-10 11:10:47 +08:00

最长的Objective-C属性名

[56] automaticallyEnablesStillImageStabilizationWhenAvailable
[54] availableMediaCharacteristicsWithMediaSelectionOptions
[49] outputObscuredDueToInsufficientExternalProtection

@PrideChung
@leavic

cameo

2014-05-10 11:25:25 +08:00

@wvv8oo

跟大Java比这都不是个事儿。看看Spring源码里最长的名字：

HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor

superbear

2014-05-10 11:28:08 +08:00

不过一看就知道这方法想干嘛

fangzhzh

2014-05-10 11:59:12 +08:00

本来以为你是矫情
再看你发了两个帖子,原来你是处女座......

mudkip

2014-05-10 12:12:28 +08:00

苹果给 Safari for iOS 7 的 video 元素新增了两个事件，名字叫 webkitplaybacktargetavailabilitychanged 和 webkitcurrentplaybacktargetiswirelesschanged....

Zhang

2014-05-10 12:16:49 +08:00

我觉得这是美德，省得自己或者别人阅读代码的时候连猜带蒙的。

austinchou0126

2014-05-10 12:34:33 +08:00 via iPhone

LZ不觉得Objective-c很难受吗？
oBjeCTive-c

jsonline

2014-05-10 12:41:27 +08:00 via Android

超过15个字符就比较反人类了。
JS 必须压缩，变量名大部分都被压缩了，不用在意

snoopy

2014-05-10 12:42:36 +08:00

你们都不写注释的吗，相比写个这么长的名字我觉得还是在每个函数上面都写个注释比较好。

unicorn70

2014-05-10 12:46:30 +08:00

@snoopy 感觉Xcode的自动补全功能做得比较好，基本没必要缩写，这样也省得到处注释了。

krafttuc

2014-05-10 12:55:02 +08:00 via iPhone

也有这种习惯了。不过很大程度上是因为Xcode的补全太强，换个编辑器就不会这样了。

saharabear

2014-05-10 12:56:29 +08:00

给Spring跪了。

lldong

2014-05-10 13:05:43 +08:00

https://github.com/nst/iOS-Runtime-Headers/blob/7ef0330f961248b9021e59e12aa3182440194817/Frameworks/UIKit.framework/UIViewController.h#L674

-attentionClassDumpUser:yesItsUsAgain:althoughSwizzlingAndOverridingPrivateMethodsIsFun:itWasntMuchFunWhenYourAppStoppedWorking:pleaseRefrainFromDoingSoInTheFutureOkayThanksBye:

snoopy

2014-05-10 13:06:45 +08:00

@unicorn70 我说一下我的看法，没有其它意思，仅供参考：
1、自动补全未写代码提供了便利，但它绝对不应该成为长命名的理由。
2、注释的好处可不仅仅是减少命名的长度，它可以为日后看代码的人（有可能就是你自己）提供全方位的呵护。在注释中起码要给出函数的说明（解决什么问题），参数的个数和类型，以及返回值的类型。
3、我们都知道命名是编程的一大难题，但认真思考命名有助于理清代码的结构，这个函数到底在我的代码中起什么样的作用。
4、长命名真的很难看。
以上只是我个人的见解，我不会说长命名很糟糕，毕竟苹果的那些工程师都在用，他们比我厉害多了。

fangzhzh

2014-05-10 13:23:33 +08:00 via Android

@snoopy 参数甚至函数内部逻辑都会变这时候函数名会变注释未必会跟着改啊

chenha0

2014-05-10 13:40:54 +08:00

假如跟我一样是个80字或120字就折行的爱好者，大概总看到这种长方法会崩溃。。。

hewigovens

2014-05-10 13:50:23 +08:00

@lldong 明显是故意的, 233

Alex_L

2014-05-10 16:15:26 +08:00

@snoopy 你永远不需要注释

cbsw

2014-05-10 16:18:57 +08:00

这么冗长的命名，还是参差不齐的驼子，这让人咋看啊！还是最古老的 LISP 的标点符号命名方式最漂亮优雅

unicorn70

2014-05-10 16:33:23 +08:00

@snoopy 什么事情都有个度，不管是长命名，短命名。难看的长命名，一般是超出了那个度，而且基本也算是个例。

另外说注释，没有说不要注释，但是如果能不要的就不要了。避免冗余。如果在函数名上多两三个单词，或者写出全称而不是只用首字母简写，就能起到可以省去对他的注释的效果，我会偏向于用长命名省去注释。如果无论如何都要注释的，那就怎么好看怎么写好了。注释的问题是维护的成本。自己能按照某种标准一直维护注释，不代表将来的自己或者别人也能这么好地维护注释。就像为什么很多人通过用doxygen让多写几句注释省去写独立文档地麻烦，长命名也有类似功能，多写几个名字省去注释地麻烦，如果能达到这样的效果，我就认可长命名。

如果长命名有一些用它的理由，自动补全又能提高生产力，用它就很顺理成章啦。

Some one's meal is another's poison. 适用不适用，最后还看各人的情况。

manoon

2014-05-10 16:46:53 +08:00

js 会有自动补全么？

Smartype

2014-05-10 16:49:00 +08:00

ObjC 方法名字长是很正常的。因为它的方法名字里面包含了参数信息。ObjC 算是比较不错的实现，面向对象，而且是动态的。实现也是非常简单的。

WildCat

2014-05-10 17:06:09 +08:00 via iPhone

@lldong 23333...🙈

alsotang

2014-05-10 17:50:03 +08:00

@jsonline 局部变量压缩，函数名压不了

dorentus

2014-05-10 19:54:47 +08:00

其实自动补全根本就不是个事，只是我们被 Xcode 的自动补全惯坏了吧

最近我在用 RubyMotion 写 iOS 应用，没有 IDE 自动补全，然后几天下来常见的方法名，即使很长，我也可以直接不查文档打出来了……

holy_sin

2014-05-10 22:46:00 +08:00

中毒太深

Ricepig

2014-05-10 23:14:13 +08:00

长名称往往是在这种语言的IDE拥有强力补全的情况下会大量出现

一方面，有了这种IDE，长名称并不会显著增加键入时的工作量；
另一方面，长名称又能一定程度的提高程序的可读性；

以极小代价换回显著的提高，何乐不为呢？

xuan_lengyue

2014-05-10 23:48:38 +08:00

反正我现在连 C# 的函数命名都已经逐渐 Objective-C 化了。。。

Rabbit52

2014-05-11 00:16:19 +08:00

@fangzhzh 干的漂亮！

banxi1988

2014-05-11 08:48:31 +08:00

大家就没有考虑过,母语不是英文的,看那么长的命名不觉得累吗?
如果短一点的你试试对比感觉下.
因为我们在看名字时,还需要将对应的英文转换成我们自己思维中的汉语
再来理解,所以我不管是用任何语言,不论是JavaScript,Python,Java,Objective-C
都是追求简短有力,讲究约定俗成,
当然也需要追求不同编程语言的习惯...

davidlau

2014-05-11 14:52:33 +08:00

@banxi1988 短命名读起来确实简洁，但是当API太多无法『约定俗成』时，还是长命名比较好。

比如说
str.strip("2",4);
[aString stripCharater:"2" repeatTimes:4 fromLeftToRight:YES]

前者虽然简洁但是如果很久没用，忘了第2个参数的意义时，需要查文档。
但比如ObjC的Framework一大堆记不住的函数，个人觉得还是后者好，省去查文档的时间。

onepiece

2014-05-12 09:34:24 +08:00

@davidlau 同意, 我只在自己一个人的项目中用短的命名. 如果是多人的项目就尽量用长的命名.

amon

2014-05-12 14:05:36 +08:00

哈哈，写长一些还是好的，易读性高。