【问题标题】:Should you use the private access modifier if it's redundant? [closed]如果私有访问修饰符是多余的,您应该使用它吗? [关闭]
【发布时间】:2010-09-20 06:34:19
【问题描述】:

鉴于这两个例子是等价的,你认为哪个更可取?

没有显式修饰符

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() { ... }

}

我一直使用后者,但最近我开始采用前一种风格。 private 是多余的,因为它是默认的访问器修饰符,所以排除它是否有意义?

【问题讨论】:

    标签: c# coding-style


    【解决方案1】:

    我认为明确声明私有有助于提高可读性。它不允许程序员以不同的方式解释其可见性。

    【讨论】:

    • 在 C# 规范中非常清楚,类的默认修饰符是私有的。这也是面试中常见的问题。
    • 别介意新程序员——显式几乎总是更好。不要让我思考。 :) 对此答案 +1。
    • Java 中的默认访问修饰符是“default”,而不是“protected”。尽管“默认”可能类似于受保护或私有,但我很确定存在细微差别。
    • @Dalin:对于类型的成员(包括嵌套类型)是私有的,对于顶级类型是内部的。
    • @Will Eddins,您可以“意外”关闭可见性这一事实表明成员不需要公开。如果他们这样做了,那么您就已经在需要它们公开的上下文中使用它们了。这就是为什么最好忽略可见性,以便事物在需要出现之前是不可见的。
    【解决方案2】:

    看起来我们是唯一的,但就个人而言,我支持让我们删除私人广告系列。

    我担心的是 public 和 private 非常相似,6-7 个字符长度,蓝色,以“p”开头,因此在 10 个显式私有方法之间指向公共方法比在没有访问属性的 10 个之间指向要困难得多.

    此外,这是一个优势,因为您团队中的懒人倾向于省去编写修饰符并将方法设为私有,这实际上是一件好事。否则,您最终会公开所有内容。

    我通常更喜欢显式而不是隐式,但这在语言极端情况(棘手的作弊)中比在广泛使用的功能中更重要。在这里,我认为长期可维护性更重要。

    另外,我通常喜欢以数学的方式简单明了的代码,而不是明确的代码,以保持未来编码人员的无知。那是 VB 的方式,而不是 C#...

    【讨论】:

    • 我们应该成立一个支持小组!
    • 如果你不喜欢它们都是蓝色的,请让你的编辑器给它们涂上不同的颜色
    • 我在同一个阵营,虽然我不介意是否使用私人。我的主要原因是 C# 代码行通常很长(前导缩进空间、长类型名称等)。删除私有使其更短。私有成员块看起来和传统的 C 程序一样简洁。
    • 越短越优雅。需要像“private”、额外的括号和不必要的运算符这样的明确混乱的人应该学习这种语言。
    • 是的,因为它们是访问修饰符。为什么要在实际上没有修改的情况下添加修饰符?
    【解决方案3】:

    将其标记为私有表明它是故意的,而不是“我实际上没有考虑过,所以我不知道它是否会更好。”;所以我喜欢让它明确。不过,我不会对此深信不疑。

    另外——这可以避免记住规则...成员默认是私有的,(外部)类型默认是内部的;嵌套类型默认是私有的...

    说清楚……说清楚;-p

    【讨论】:

    • 但是规则很容易记住。您可以将它们重述为“一切都尽可能不可见”。或者“一切都是私有的,除非它不能是”(外部类型不能是因为那时没有任何东西可以使用它们)。记住默认值并不难。
    【解决方案4】:

    我总是忽略它有两个原因:减少视觉混乱,以及默认做正确的事情。

    在 C# 中,所有内容都默认为尽可能少的可见性。类成员(字段、方法、属性)默认为私有。一个类默认为内部。嵌套类默认为私有。

    因此,如果您在需要时忽略了可见性,您将自动使用尽可能少的可见性,这无论如何都是正确的做事方式。

    如果您需要让某些东西更多可见,请添加修饰符。这样可以轻松查看偏离默认可见性的项目。

    (不幸的是,此规则仅适用于 C#。在 VB .NET 和 F# 中,默认值完全不同,在大多数情况下绝对不是“可能的最低可见性”。)

    【讨论】:

      【解决方案5】:

      我已经全职从事 C# 开发大约 7 年了,直到我读到这个主题,我才知道默认的访问修饰符是什么。我知道它的存在,但我从来没有使用过它。

      我喜欢在编写代码时明确声明我的意图。既是因为当我回去查看它时,我可以看到声明,而且因为在我编写方法时实际思考和输入“私有”这个词让我更多地思考我的想法做。

      【讨论】:

      • “我从事 C# 的全职开发工作大约 7 年了,直到我读到这个主题之前,我才知道默认的访问修饰符是什么。” --> 这需要一些勇气承认:)
      【解决方案6】:

      就个人而言,我更喜欢 private 修饰符 - 我喜欢明确性。对于字段,它还强调它是一个成员变量,而不是一个函数变量(唯一的区别是位置 - 如果人们可以正确缩进,这没关系,但否则可能会造成混淆)。

      【讨论】:

        【解决方案7】:

        我通常喜欢超级明确。我会一直指定“私人”。然而还有另一个原因:程序员来自默认可见性NO私有但公开的编程语言,例如 PHP。

        【讨论】:

        • 是的,最终,他们(PHP 程序员)将创建一堆私有成员,他们真正想要的是公共修饰符,并且实现的类没有从外部类测试。
        【解决方案8】:

        我总是喜欢明确表达,即使它是多余的。这提供了内置的代码 cmets,并且可以对下一个人有所帮助,尤其是如果他是菜鸟的话。 :-)

        【讨论】:

          【解决方案9】:

          始终使用显式形式。如果由于某种原因底层假设发生变化,具有显式访问含义的代码不会中断,而隐式含义很容易中断。

          此外,当您谈论不同类型的结构时,它们可能具有不同的默认可访问性。如果没有显式修饰符,读者就可以知道哪个结构具有什么默认值。例如。在 C# 中,结构字段默认为public,类字段默认为private,类定义默认为internal

          【讨论】:

            【解决方案10】:

            我一直都很明确。如果没有别的,它更清楚地表明了你的意图。如果我想保密,我会这么说。明确输入修饰符可以确保我考虑它,而不是因为它更快而将事情保密。一长串成员排列得更好:)

            【讨论】:

              【解决方案11】:

              我总是明确指定可见性。我不想让编译器猜测我的意图。

              【讨论】:

                【解决方案12】:

                您是对的,但是由于您希望您的代码对我认为您应该包括的每个人都可以理解,因此您永远不知道何时有人不知道这一点

                【讨论】:

                  【解决方案13】:

                  除非另有说明,否则我的理解一直是成员具有“内部”可访问性。如果这是真的,则需要“private”修饰符来确保这些成员实际上是私有的。

                  无论我对上述内容是否正确,保留修饰符将增加代码的可读性,以防其他开发人员稍后修改此类并对可访问性感到好奇。希望这会有所帮助!

                  【讨论】:

                  • 成员是“私人的”,除非另有说明。 类型(或者至少是外部类型)默认是内部的;并且对于嵌套类再次不同。看 - 已经有 3 个场景需要记住 - 值得明确说明;-p
                  • 您不必记住三个场景。您必须记住的是,默认情况下,所有内容的可见度都最低。外部类型不能是私有的;如果是的话,没有任何东西可以访问它。一个内部类型可以是私有的,因为它可以被它的外部类型访问,这就是为什么私有是它的默认可见性。 C# 中的默认可见性是完全合乎逻辑的 - 因此值得明确说明。
                  • 成员在 VB .NET 中默认具有内部 (Friend) 可见性。 VB .NET 规则基本上要求您明确可见性,因为它们没有明显的逻辑。 C# 规则有一个简单的逻辑规则(参见前面的评论),除非您需要更改它们,否则保留默认值是安全的。
                  【解决方案14】:

                  首先,我将询问是否有关于团队使用的先前代码约定/标准。如果有的话,你应该关注它。

                  如果您必须定义约定,我将推动明确的方式。

                  我的理由?;

                  • 我喜欢保持相同的结构(我的意思是 a.-access 修饰符、b.-return-type/type、c.-name)。
                  • 我不希望(我也不希望其他人)默认记住所有修饰符 (which are here)。
                  • 并非所有语言都有相同的规则。
                  • 不知何故,我认为,不知何故,它迫使开发人员思考并更加意识到变量/方法的范围以及它们的阐述。如果您有一些经验,这可能不适用,但如果您是新手,或者您与经验较少的人一起工作,我认为这很有用。

                  【讨论】:

                    猜你喜欢
                    • 1970-01-01
                    • 2017-12-22
                    • 2021-10-09
                    • 2014-08-27
                    • 1970-01-01
                    • 2017-05-16
                    • 2017-03-27
                    • 2011-04-18
                    • 2011-01-31
                    相关资源
                    最近更新 更多