blocks|key|830021|text|我喜欢：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|830022|protected+string+_Bar;

public+string+Bar++++++++
{++++++++++++
++++get+{+return+_Bar;+}++++++++
}++++|code-block|syntax|javascript|830023|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

I like:

<pre><code>protected string _Bar;

public string Bar 
{ 
 get { return _Bar; } 
} 
</code></pre>

blocks|key|1129236|text|我认为大多数开发人员在成员变量前加上下划线如下所示：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1129237|protected+string+_bar;|code-block|syntax|javascript|1129238|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

Think most developers prefix member variables with underscore like so:

<pre><code>protected string _bar;
</code></pre>

blocks|key|830069|text|不，微软表示，公开可见的成员必须不仅仅是大小写的不同：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|830070|830071|此规则仅在公开可见的成员上触发。|blockquote|830072|830073|830074|(这包括受保护的成员，因为它们对派生类是可见的。)|830075|所以这很好：|830076|public+class+Foo
{
++++private+string+bar;
++++public+string+Bar+{+get+{+return+bar;+}+}
}|code-block|syntax|javascript|830077|我的个人规则是无论如何都不允许任何其他私有字段，在这一点上这不是问题。|830078|您真的需要受保护的字段吗？如果你想从派生类中改变属性，让它有一个受保护的setter如何？|830079|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|Y|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|10|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|11|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|12|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|13|8|@]|9|@]|A|$O|P]]|$1|Q|3|R|5|6|7|14|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|15|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|V|$]]

No, Microsoft says publicly visible members must differ by more than just case:

<blockquote>
 This rule fires on publicly visible members only.
</blockquote>

(That includes protected members, as they're visible to derived classes.)

So this is fine:

<pre><code>public class Foo
{
 private string bar;
 public string Bar { get { return bar; } }
}
</code></pre>

My personal rule is not to allow anything other private fields anyway, at which point it's not a problem.

Do you really need protected fields? How about making the property have a protected setter if you want to be able to mutate it from derived classes?

blocks|key|84194|text|这可能会让一些开发人员感到厌恶，但我喜欢让我一眼就能区分成员变量和本地变量的命名约定。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|84195|所以，我经常这样做：|84196|public+class+Foo
{
++++protected+string+_bar;

++++public+string+Bar
++++{
++++++++get+{+return+_bar;+}
++++}
}|code-block|syntax|javascript|84197|...or...|84198|public+class+Foo
{
++++protected+string+mBar;++++//+'m'+for+member

++++public+string+Bar
++++{
++++++++get+{+return+mBar;+}
++++}
}|84199|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

This may make some developers out there hurl in disgust, but I like naming conventions that let me distinguish member variables from locals at a glance.

So, I often do something like:

<pre><code>public class Foo
{
 protected string _bar;

 public string Bar
 {
 get { return _bar; }
 }
}
</code></pre>

...or...

<pre><code>public class Foo
{
 protected string mBar; // 'm' for member

 public string Bar
 {
 get { return mBar; }
 }
}
</code></pre>

blocks|key|830107|text|我个人喜欢Balena写的这本书：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|830108|http://www.amazon.com/Practical-Guidelines-Practices-Developers-Pro-Developer/dp/0735621721/ref=sr_1_1?ie=UTF8&s=books&qid=1265845146&sr=8-1|offset|length|830109|entityMap|0|LINK|mutability|MUTABLE|url|https://rads.stackoverflow.com/amzn/click/com/0735621721^0|0|0|3W|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

I personally like this book by Balena:

<a href="https://rads.stackoverflow.com/amzn/click/com/0735621721" rel="nofollow noreferrer" rel="nofollow noreferrer">http://www.amazon.com/Practical-Guidelines-Practices-Developers-Pro-Developer/dp/0735621721/ref=sr_1_1?ie=UTF8&amp;s=books&amp;qid=1265845146&amp;sr=8-1</a>

blocks|key|2539259|text|我个人做以下几件事：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2539260|class+SomeClass
{
++++private+static+string+s_foo;+++//+s_+prefix+for+static+class+fields
++++private+string+m_bar;++++++++++//+m_+prefix+for+instance+class+fields

++++public+static+string+Foo
++++{
++++++++get+{+return+s_foo;+}
++++}

++++public+string+Bar
++++{
++++++++get+{+return+m_bar;+}
++++}
}|code-block|syntax|javascript|2539261|我最初只是使用_或m_作为我所有字段的前缀，直到我开始通过Reflector挖掘大量微软的.NET代码。微软也使用了s_和m_范例，我有点喜欢它。当您读取函数的代码体时，它使您很容易准确地知道字段是什么。我不需要指向任何东西，然后等待工具提示或类似的东西出现。我仅仅通过字段前缀就可以知道某个东西是静态的还是实例的。|2539262|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

I personally do the following:

<pre><code>class SomeClass
{
 private static string s_foo; // s_ prefix for static class fields
 private string m_bar; // m_ prefix for instance class fields

 public static string Foo
 {
 get { return s_foo; }
 }

 public string Bar
 {
 get { return m_bar; }
 }
}
</code></pre>

I originally used to just use _ or m_ as a prefix for all of my fields until I started digging through lots of Microsoft .NET code via Reflector. Microsoft uses the s_ and m_ paradigm as well, and I kind of like it. It makes it easy to know exactly what a field is when you are reading the code body of a function. I don't have to point to anything and wait for a tooltip to appear or anything like that. I know whether something is static or instance simply by its field prefix.

blocks|key|84248|text|这取决于您或您的公司\组织的编码标准。但大多数程序员在字段上使用camelCasing或下划线%2B+camelCasing，在属性上使用PascalCasing，例如：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|84249|public+class+Foo++++
{+++++++++
++++protected+string+_bar;+

++++public+string+Bar+++++++++
++++{+++++++++++++
++++++++get+{+return+_bar;+}+++++++++
++++}+++++
}+|code-block|syntax|javascript|84250|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

It depends on you or your company\organization's coding standard. But most programmers use camelCasing or underscore + camelCasing on Fields and PascalCasing on Properties like:

<pre><code>public class Foo 
{ 
 protected string _bar; 

 public string Bar 
 { 
 get { return _bar; } 
 } 
} 
</code></pre>

<a href="http://msdn.microsoft.com/en-us/library/ms182242.aspx" rel="noreferrer">Microsoft says</a> fields and properties must differ by more than just case. So, if they truly represent the same idea how should they be different?

Here's Microsoft's example of what not to do:

<pre><code>
using System;
namespace NamingLibrary
{ 
 public class Foo // IdentifiersShouldDifferByMoreThanCase 
 { 
 protected string bar;

 public string Bar 
 { 
 get { return bar; } 
 } 
 }
}
</code></pre>

They give no guidance on how this should look. What do most developers do?

How to best name fields and properties

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

字段和属性必须不只是大小写不同。那么，如果它们真的代表了相同的概念，它们应该如何不同呢？下面是微软关于不该做的事情的例子：using System;namespace NamingLibrary{        public class Foo    // IdentifiersShouldDifferByMoreTh...

问如何对字段和属性进行最佳命名
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何对字段和属性进行最佳命名EN