如果使用私人访问修改器，是否应该使用冗余？
鉴于这两个例子是相同的，你认为哪一个更可取？
没有明确的修饰语
public class MyClass { string name = "james"; public string Name { get { return name; } set { name = value; } } void SomeMethod() { ... } } 用明确的修饰符
public class MyClass { private string name = "james"; public string Name { get { return name; } set { name = value; } } private void SomeMethod() { ... } }
我一直使用后者，但最近我开始采用前者的风格。 私有是多余的，因为这是默认的访问修饰符，所以排除它是没有意义的？
我认为明确说明私人有助于可读性。 它不会允许程序员以不同的方式解释其可见性。
看起来，我们是唯一的，但个人而言， 我支持让我们删除私人活动。
我担心的是，公共和私人是如此相似，长度为6-7个字符，蓝色，以“p”开始，因此在10个明确的私人公开方法之间指定一个公共方法比在没有访问属性的10个公共方法更难。
而且，这是一个优势，因为你的团队中的懒惰的人倾向于保存编写修改器，并使这个方法变为私有，这实际上是一件好事。 否则，你最终公开的一切。
我通常更喜欢显性而不是隐式，但在一个广泛的特性中，语言angular落案例（棘手的作弊）更重要。 在这里，我认为长期可维护性更重要。
另外，我通常喜欢当代码是简单明了的时候，为了保留未来的编码器的无知，在代码明确的时候用math方法清楚。 这是VB的方式，而不是C＃…
把它标明为私人，说明它是故意的，而不是“我没有真正考虑过，所以我不知道它会不会更好。” 所以我喜欢把它明确。 尽pipe如此，我对此不会有任何的信任。
另外 – 这可以防止必须记住规则…成员默认是私有的，（外部）types默认是内部的; 嵌套types默认是私有的
说清楚…明确表示; -p
我总是忽略它，以减less视觉混乱。 在C＃中，所有的东西都默认为尽可能less的可见性 。 类成员（字段，方法，属性）默认为私有。 一个类默认为内部。 嵌套类默认为私有。
如果你需要更清楚的东西，那么添加修饰符。 这可以很容易地看到偏离默认可见性的项目。
唯一的情况，我可以看到它造成的问题是，如果你来自VB.NET的背景。 但是，嘿，我来自VB.NET的背景，我仍然知道在C＃中默认的可见性是什么。
另一方面，在VB .NET中，我几乎总是把它包括进来，因为默认是相当愚蠢的。 Sub或Function的默认值是Friend而不是Private 。
我已经使用C＃开发了大约7年的全职工作了，直到我读了这个主题之后，我才知道默认访问修饰符是什么。 我知道有一个存在，但我从来没有使用它。
我喜欢明确地声明我的意图，因为我的代码。 这既是因为这些声明让我回想起来，而且还因为当我写一个方法时，实际上思考和input“private”这个词使得我更加思考我所想的是什么做。
就个人而言，我更喜欢私人修饰 – 我喜欢清晰。 对于字段，它也强调，它是一个成员variables，而不是一个函数variables（唯一的区别，否则是位置 – 这是可以的，如果人们可以正确缩进，但可以混淆，否则）。
我喜欢通常是超显式的。 我会永远指定“私人”。 然而，还有另一个原因：程序员来自编程语言，其默认可见性不是私有的，而是公开的，例如PHP。
我总是喜欢明确的，即使是多余的。 这提供了内置的代码注释，可以帮助下一个人，特别是如果他是一个noob。 🙂
总是使用显式的forms。 如果出于某种原因潜在的假设发生了变化，具有明确的访问权限的代码将不会被破坏，而隐含的内涵则容易被破坏。
而且，当您谈论不同types的结构时，它们可能具有不同的默认可访问性。 如果没有明确的修饰语，那么读者就会知道哪个结构有什么默认的。 例如，在C＃中，struct字段默认为public ，class字段默认为private ，而类定义默认为internal 。
我总是明确指定可见性。 我不想让编译器猜测我的意图。
我一直都很清楚 如果没有其他更清楚地表明你的意图。 如果我想要一些私密的东西，我会这么说。 明确地input修饰符可以确保我考虑它，而不是仅仅因为它更快而使事物保密。 这一长串成员排队更好:)
你是正确的，但既然你想要你的代码对于我认为你应该包括的每个人都是可以理解的，你永远不知道什么时候有人不知道这个
除非另有说明，我的理解一直是成员具有“内部”可访问性。 如果这是真的，则需要“私人”修改者来确保这些成员实际上是私人的。
无论我对上述内容是否正确，在其他开发人员稍后修改此类并对可访问性感到好奇的情况下，将修改器留在原处将会增加代码的可读性。 希望这可以帮助！
首先我会问是否有关于团队正在使用的代码惯例/标准。 如果有的话，你应该遵循它。
如果你必须定义这个约定，我会采取明确的方式。
我的理由是什么？
- 我喜欢保持相同的结构（我的意思是访问修饰符，b.-return-type / type，c.-name）。
- 我不想（我不指望别人）默认记住所有的修饰符（ 在这里 ）。
- 并非所有的语言都有相同的规则。
- 不知何故，我认为这样做会迫使开发者思考variables/方法的范围和对这些variables的解释。 如果你有一些经验，这可能不适用，但如果你是一个新手，或者你与经验较less的人一起工作，我认为这是有用的。
