Objective-C类前缀

您对命名ObjC类的偏好是什么？我有点不确定在这个问题上什么是最合理的方法，所以很高兴听到一些其他的意见

苹果建议在cocoa类前面加前缀，因为ObjC不支持名称空间。GoogleOBJC样式指南（我的主要目标是）将其删除，除非您正在扩展（类别、类扩展等）NSClass

我不喜欢在类前面加前缀，因为我也认为这是浪费字母，也没有什么原因。它应该只在框架代码中使用，以表示该类属于它，而不属于应用程序的类，但我不会在应用程序级别使用它

什么是你的，最重要的是为什么

我的结论（请随时添加您的评论以做出最明智的决定）

---

应用程序级别类：

• 我决定使用1个字母的前缀（比如CMyClass）。主要原因是出于文件组织的目的（例如，在Finder中进行更好的分组），它使用的类名字母仍然少于长度为2或2以上的前缀。
  • 可可类使用前缀“C”（例如

    CAudioController.h

    ）
  • 对实用程序集合使用前缀“U”（普通C，例如

    USystemAudio.h

    ）

框架级类：

• 前缀类包含2个或更多自定义字母，最好是唯一的，因为它可能会与其他应用程序共享

类别

• 类别的命名如下：

  NSClassName+ExtensionPurpose

---

您绝对应该在它们前面加前缀。如果发生碰撞，则行为未定义

---

实际发生的情况（上次我遇到这个）是加载了二进制文件，但是如果已经加载了另一个具有该名称的（objc）类，则不会加载您的类。我将让您了解在创建此类的实例时将得到哪个实现；）这样的冲突可能会导致崩溃或大量异常（以及非功能性应用程序）。许多开发人员使用2个大写字母，这是（所有条件都相同）26*26他们使用相同前缀的可能性。又一次——这件事发生在我身上了。。。。最好这样做，以避免以后重写大量代码。
关于objective-C代码的外观，有一个非常好的指南。签出以下链接



---

这些链接还将回答您应该如何命名类以及为什么命名的问题。
我的一般方法是在作为框架或可加载捆绑包一部分的类名前加前缀，即可能在多个应用程序之间以及与其他框架共享的类，但不必担心作为独立应用程序一部分出现的类

---

如果Steve Jobs答应了我一个愿望，那就是在Objective-C 3.0中使用名称空间（将于明天提供）。
我使用前缀，即使是在不会共享的应用程序代码中也会使用前缀——主要用于一致性。我通常使用两个字母的缩写来表示代码起源的应用程序或框架名称，除非不同的前缀（例如，3个字母或一个简短的描述性单词）更有意义。
我个人不喜欢这些前缀。在这种情况下，我的意见和你的完全一样。我从未因为不使用前缀而与框架类发生过冲突，它们在某种程度上降低了代码的可读性。在框架中，他们可以发出“嘿，我属于这个框架，而不是你的应用程序代码”的信号。如果有冲突，编译器无论如何都会报告这个问题（在大多数情况下）。我同意Jeremy的方法。由于Apple在其库和框架中为所有全局名称加前缀（即，不仅仅是类名，而是结构、枚举等的typedef），而且任何体面的第三方框架都应该效仿，因此应用程序最好不使用前缀来避免冲突。两个字母的前缀应该在大多数情况下都能工作，但我想我应该指出，从技术上讲，苹果公司为自己保留了所有这些前缀。因此，他们的建议是始终使用3个字母的前缀。苹果在哪里声明保留所有2个字母的组合？几乎每个Mac项目都使用两个字母的前缀。在应用程序框架中，会话130——未来验证你的应用程序。如果苹果真的认真对待这个建议，他们应该把它放在文档中，而不是放在开发人员不太可能看到的视频中。重写？还是搜索并替换？确实如此。其中一种情况的最坏情况实际上并没有那么糟糕。链接到Google的ObjC风格指南：-他们说：“当设计要在多个应用程序之间共享的代码时，前缀是可以接受的，并且是推荐的（例如GTMSendMessage）。对于依赖外部库的大型应用程序类，也建议使用前缀。”