我有一个命名策略来表示代码实体（变量，方法等）的性质，它解释了范围，实体类型和可变性的最常见排列，但我无法选择一种方法表示私有静态成员字段（不是属性）。
有哪些推荐方法可以表示这一点？
更新：对于它的价值，我确实理解这已经失败了 时尚，尤其是C＃ 微软反对它。我应该 指明我的目标不是 提供一定级别的“文档”， 但只是为了能够通过尽可能少的运动和交叉参考获得尽可能多的信息。
就我个人而言，我觉得这是理想的 标识符可以限制为 传达有关目的的信息， 并将代码上下文信息保留给 IDE传达。但是，自从 VS2008似乎没有提供 突出显示/造型选项 基于范围或可变性，我 不要觉得工具提示是 特别有效，因为 所需的鼠标运动和 等等，我发现自己受限于我 选项。
作为参考，我主要使用C＃编程，下面是我当前命名约定的示例：
对于私有静态字段，我一直在考虑这些：
答案 0 :(得分：4)
我将s_用于静态成员，m_用于实例成员。
然而，您所要求的以及我所做的事情违反了Microsoft建议的C＃命名约定：Names of Type Members。
答案 1 :(得分：3)
我让我的IDE格式不同。更容易看出italic = static。然后，当我必须重构代码时，我也不必担心重命名。
答案 2 :(得分：2)
您应该坚持使用适合您语言的惯例。您的IDE应该明确哪个变量是public / private，static / instance ...在我们有语法着色编辑器之前，需要在其名称中放置变量的可见性或类型。但是现在我们拥有它，如果它没有前缀，我发现代码更清晰，更容易阅读。
答案 3 :(得分：1)
我不区分私有静态或实例变量。它们都是骆驼式的，带有一个领先的下划线：
private static readonly ILog _someLog = ...;
我认为我从未因此而挠头。
答案 4 :(得分：1)
我使用g_，因为静态变量只不过是一个美化的全局变量
答案 5 :(得分：0)
我毫不怀疑这会堕落成一个关于谁的方式更好的争论（把那些括号放在同一条线上该死的！）但我不喜欢做或看到这样的事情除了常数之外。我可以看到你的理由，但除非你是一个单独的商店，否则当别人正在编辑你的代码并且不坚持它时，它只会引起混淆。
我个人更喜欢不关心它的方法，实例，静态等范围，并且当我需要知道时让IDE帮助我。此外，是否没有为您的语言发布命名约定？
答案 6 :(得分：0)
像肯特一样，我带着一个领先的下划线来骆驼。前缀声明在一段时间内还没有流行。我发现将声明组织到区域中以及在IDE中获得的工具提示足以跟踪这些内容。
答案 7 :(得分：0)
我不会使用下划线，因为public看起来应该很好。
就我而言，我使用前缀the，例如theApplication，theSettings等。