您建议如何表示静态类成员？
我有一个命名策略来表示代码实体（变量、方法等）的性质，它解释了范围、实体类型和可变性的最常见排列，但我无法选择一种表示私有静态的方法成员字段（不是属性）。
有哪些推荐的表示方式？
更新：就其价值而言，我确实知道这已经超出了 时尚，尤其是 C#， 微软对此表示反对。 我应该 明确我的目标不是 提供一定程度的“文档”， 但只是为了能够以尽可能少的运动和交叉引用来获取尽可能多的信息。
我个人觉得如果 标识符可以限制为 传达有关目的的信息， 并将代码上下文信息留给 IDE 来传达。 然而，自从 VS2008好像没有提供 突出显示/样式选项是 基于范围或可变性，我 不觉得工具提示是 在这方面特别有效，因为 所需的鼠标运动和 等待，我发现自己的能力有限 选项。
作为参考，我主要使用 C# 进行编程，下面是我当前命名约定的示例：
- 方法参数或局部变量：thisIsMyVariable
- 实例级私有字段：_thisIsMyVariable
- 公共实例或类级属性或方法：ThisIsMyVariable
- 常量：THIS_IS_MY_VARIABLE
对于私有静态字段我一直在考虑这些：
- s_thisIsMyVariable
- _ThisIsMyVariable
I have a naming strategy for denoting the nature of code entity (variable, method, etc.) which accounts for the most common permutations of scope, entity type, and mutability, but I have not been able to choose a way of denoting private static member fields (not properties).
What are some recommended ways of denoting this?
Update: For what it's worth, I do understand that this has fallen out of
fashion, and that for C# particularly,
Microsoft argues against it. I should
specify that my goal in this is not to
provide a level of "documentation",
but simply to be able to get as much information as possible with as little motion and cross referencing as possible.Personally I feel it would be ideal if
identifiers could be restricted to
conveying information about purpose,
and leave code context information to
the IDE to convey. However, since
VS2008 does not appear to provide
highlighting/styling options which are
based on scope or mutability, and I
don't feel that tooltips are
particularly efficient in this because
of the required mouse motion and
waiting, I find myself limited in my
options.
For reference, I primarily program in C#, and below is a sampling of my current naming conventions:
- Method argument or local variable: thisIsMyVariable
- Instance-level private field: _thisIsMyVariable
- Public instance- or class-level property or method: ThisIsMyVariable
- Constant: THIS_IS_MY_VARIABLE
For private static fields I've been considering these:
- s_thisIsMyVariable
- _ThisIsMyVariable
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
像 Kent 一样，我使用驼峰式大小写并带有前导下划线。 为声明添加前缀已经有一段时间不流行了。 我发现将我的声明组织到区域中以及您在 IDE 中获得的工具提示足以跟踪这些内容。
Like Kent, I camel case with a leading underscore. Prefixing declarations has not been in vogue for some time. I find that organizing my declarations into regions and the tools tips that you get in the IDE are sufficient to keep track of this stuff.
我不会使用下划线，因为所有
public都应该看起来不错。就我而言，我使用前缀
the，例如theApplication、theSettings等。I wouldn't use underscores, as everything
publicshould look nice.As for me, I use prefix
the, liketheApplication,theSettings, etc.我使用
s_作为静态成员，使用m_作为实例成员。然而，您所要求的以及我所做的违反了 Microsoft 推荐的 C# 命名约定，如下所示：类型成员的名称。
I use
s_for static members andm_for instance members.However what you're asking for, and what I do, contravene the Microsoft-recommended naming conventions for C# which are listed here: Names of Type Members.
我让我的 IDE 以不同的方式格式化它们。 更容易看出斜体=静态。 然后，当我必须重构代码时，我也不必担心重命名。
I let my IDE format them differently. Way easier to see that italic=static. Then, when I have to refactor code I don't have to worry about renaming as well.
您应该遵守您的语言已有的约定。 您的 IDE 应该明确哪个变量是公共/私有、静态/实例...在我们使用语法着色编辑器之前，需要将变量的可见性或类型放入其名称中。 但现在我们有了它，我发现如果代码没有混乱的前缀的话，它会更干净，更容易阅读。
You should stick to the conventions already in place for your language. Your IDE should make clear which variable is public / private, static / instance ... There was a need to put the visibility or the type of a variable in its name before we had syntax coloring editors. But now that we have it, I find the code much cleaner and easier to read if it isnt cluttered with prefixes.
我使用 g_ ，因为静态变量只不过是一个美化的全局变量
I use g_ , as static variable is nothing but a glorified global variable
我不区分私有静态变量或实例变量。 它们都是驼峰式的，并带有一个前导下划线：
而且我不认为我因此而感到困惑。
I don't differentiate between private static or instance variables. They're both camel-cased with a leading underscore:
And I don't think I've ever been left scratching my head as a result.
我毫不怀疑这会退化为关于谁的方式更好的争论（将这些大括号放在同一行该死的！）但除了常量之外，我不喜欢做或看到类似的事情。 我可以理解你这样做背后的原因，但除非你是一个人做事，否则当其他人正在编辑你的代码并且不遵守它时，它只会引起混乱。
我个人更喜欢不关心它的方法、实例、静态等范围，并在我确实需要知道时让 IDE 帮助我。 此外，没有为您的语言发布命名约定吗？
I have no doubt this will degenerate into an argument about who's way is better (put those braces on the same line dammit!) but I don't like doing or seeing anything like this apart from the constants. I can see your reasoning behind this but unless you're a one-man shop it will just cause confusion when someone else is editing your code and doesn't stick to it.
I personally prefer to not care if its method, instance, static etc. scope and let the IDE help me on that when I do need to know. Besides, aren't there naming conventions published for your language?