Objective-C 常量键命名

发布于 2024-10-20 19:48:59 字数 117 浏览 1 评论 0原文

我对常量命名有点困惑。

kName
NameKey
NAME_KEY

确实使用过这些时尚吗?

I'm little bit confused about constants naming.

kName
NameKey
NAME_KEY

Definitely usage of these fashions?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

分开我的手 2024-10-27 19:48:59

根据 Cocoa 编码指南,使用 const 创建的常量应该如下所示:

const 常量的格式由以下声明举例说明:

<块引用>

const float NSLightGray;

要查看指南 点击此处

According to Coding Guidelines for Cocoa, constances created with const shoul look like this:

The format for const constants is exemplified by the following declaration:

const float NSLightGray;

To see guidelines click here

笑红尘 2024-10-27 19:48:59

我建议选择您自己的项目或公司前缀(如上面的 NS 或 AV)并坚持使用。因此,如果您的前缀是 AB:

  • ABMegaTopKey for const 变量
  • AB_MEGA_TOP_FLAG for #defines

Apple 使用不同的样式,具体取决于谁编写了项目以及何时编写的。

I suggest to pick your own project or company prefix (like NS or AV above) and stick with it. So, if your prefix is AB:

  • ABMegaTopKey for const variables
  • AB_MEGA_TOP_FLAG for #defines

Apple uses different style depending, I guess, on who wrote the project and when was it written.

少女的英雄梦 2024-10-27 19:48:59

kName 用于字符串或变量常量。
NAME_KEY 用于#define 常量。

kName is used for string or variable constants.
NAME_KEY is used for #define constants.

窝囊感情。 2024-10-27 19:48:59

kName 是 Apple 风格,而 NAME_KEY 在其他语言中更为普遍。进行更多研究: k 是匈牙利符号

kName is Apple style, while NAME_KEY is alot more widespread among other languages. Doing a lil more research: k is hungarian notation

ヅ她的身影、若隐若现 2024-10-27 19:48:59

我总是使用来自主要 C 背景的第三种样式,尽管我通常会在框架上添加前缀,例如

NSString* const JP_NAME_KEY = @"name";

I always use the third style coming from a mainly C background, although I will usually put a prefix on them for frameworks e.g.

NSString* const JP_NAME_KEY = @"name";
染年凉城似染瑾 2024-10-27 19:48:59

各个库中的常量命名存在一些明显的“文化”。

我通常非常字面地声明常量,使用大驼峰式和下划线来分隔较长的名称:

  • 以组织代码为前缀
  • ,然后以库为前缀(如果适用)
  • 然后按类型或类别为其添加前缀

    ORGConstantName

    ORGLibrary_ConstantName

    ORGLibraryType_ConstantName

    ORGLibraryCategory_ConstantName

它很冗长,但它避免了冲突,并且当常量仅适用于特定范围、类型、库或其他上下文时,它非常清楚。

无论你决定做什么,只要确保它是一致的。

there are a few visible 'cultures' in naming constants across the libraries.

I typically declare constants quite literally, using upper Camel with underscores to separate the longer names:

  • Prefix with organization code
  • then prefix with library (if applicable)
  • then prefix it by type or category

    ORGConstantName

    ORGLibrary_ConstantName

    ORGLibraryType_ConstantName

    ORGLibraryCategory_ConstantName

it's verbose, but it avoids clashes, and it's really clear when the constant applies only to a certain scope, type, library, or other context.

whatever you settle on, just make sure it's consistent.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文