【问题标题】:Objective-C Class Prefixes [closed]Objective-C 类前缀 [关闭]
【发布时间】:2010-09-14 11:26:45
【问题描述】:

您对命名 ObjC 类的偏好是什么?我有点不确定在这方面最合理的方法是什么,所以很高兴听到一些其他意见。

Apple 建议为可可类添加前缀,因为 ObjC 不支持命名空间。 Google ObjC 样式指南(我的主要目标)取消了它们,除非您正在扩展(类别、类扩展等)NSClass。

我的偏好是不要给类加前缀,因为我也认为这是浪费字母,对事业没有贡献。它应该只在框架代码中用于表明这个类属于它而不是你的应用程序的类,但我不会在应用程序级别使用它。

什么是你的,最重要的是为什么?


我的结论(请随时添加您的 cmets 以做出最明智的决定)


应用级类:

  • 我决定使用 1 个字母前缀(如 CMyClass)。主要原因是出于文件组织目的(例如,在 Finder 中更好的分组),并且它仍然使用更少的类名字母,而不是长度为 2 或更多的前缀。
    • 对可可类使用前缀“C”(例如CAudioController.h
    • 对实用程序集合使用前缀“U”(纯 C,例如 USystemAudio.h

框架级类:

  • 为类加上 2 个或更多自定义字母的前缀,最好是唯一的,因为它可能会与其他应用共享。

类别

  • 类别命名如下:NSClassName+ExtensionPurpose

【问题讨论】:

  • 链接到 Google 的 ObjC 样式指南:google-styleguide.googlecode.com/svn/trunk/… - 他们说:“在设计要跨多个应用程序共享的代码时,可以接受并建议使用前缀(例如 GTMSendMessage)。还建议将前缀用于以下类别依赖外部库的大型应用程序。”

标签: objective-c cocoa coding-style


【解决方案1】:

我的一般方法是为作为框架或可加载包的一部分的类名添加前缀,即可能在多个应用程序和其他框架之间共享的类,但不打扰作为独立应用程序一部分出现的类。

如果史蒂夫乔布斯满足我的一个愿望,那就是在 Objective-C 3.0 中拥有命名空间(明天将可用)。

【讨论】:

  • 我个人鄙视这些前缀。在这种情况下,我的意见与您的完全一样。我从来没有与框架类发生冲突,因为不使用前缀,它们在某种程度上降低了代码的可读性。在框架中,他们可以表示“嘿,我属于这个框架,而不是你的应用程序代码”。如果存在冲突,编译器无论如何都会报告这个问题(在大多数情况下)。
  • 我同意杰里米的做法。由于 Apple 在其库和框架中为所有全局名称添加前缀(即,不仅是类名,还有结构、枚举等的 typedef),并且任何体面的第三方框架都应该效仿,因此应用程序可以通过 根本不使用前缀。
【解决方案2】:

Scott Stevenson 有一个非常好的指导方针,说明 Objective-C 代码的外观。查看以下链接。

http://cocoadevcentral.com/articles/000082.php
http://cocoadevcentral.com/articles/000083.php

这些链接还将回答您应该如何命名类以及为什么命名的问题。

【讨论】:

    【解决方案3】:

    我使用前缀,即使在不会共享的应用程序代码中——主要是为了一致。我通常使用 2 个字母的缩写来表示代码源自的应用程序或框架名称,除非不同的前缀(例如,3 个字母或简短的描述性词)更有意义。

    【讨论】:

    • 两个字母的前缀在大多数情况下应该可以使用,但我想我要指出的是,从技术上讲,Apple 会为自己保留所有这些前缀。所以他们的建议是始终使用 3 个字母的前缀。
    • Apple 在哪里声明他们保留 all 2 字母组合?几乎每个 Mac 项目都使用 2 个字母的前缀。
    • WWDC 2010 videos 应用程序框架中,第 130 节 - 未来证明您的应用程序。
    • 如果 Apple 对这个建议真的很认真,他们应该把它放在一个文档中,而不是一个开发者不太可能看到的视频。
    【解决方案4】:

    你绝对应该给它们加前缀。如果发生冲突,则行为未定义。

    实际发生的情况(上次我遇到这个)是二进制文件已加载,但如果另一个具有该名称的(objc)类已经加载,则不会加载您的类。我会让你弄清楚当你创建这个类的一个实例时你会得到哪个实现;)这样的冲突可能会导致崩溃或大量被吞没的异常(以及一个非功能性应用程序)。许多开发人员使用 2 个大写字母,即(所有事物都相同)26*26 他们将使用相同前缀的机会。再一次 - 这发生在我身上太......最好你这样做以避免以后重写大量代码。

    【讨论】:

    • 重写?还是搜索和替换?
    • 确实如此。其中一种情况的最坏情况实际上并没有那么糟糕。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2016-07-22
    • 1970-01-01
    • 2010-09-15
    • 2023-04-03
    • 1970-01-01
    • 2021-02-07
    • 2011-02-13
    相关资源
    最近更新 更多