Question

我最近删除了从类定义中指定的private，因为它位于class关键字后面的顶部：

class MyClass
{
private:
    int someVariable;
// ...

我认为这是多余的。

一位同事不同意这种说法，称它有效地“隐藏”了数据的private性质。

我们的大多数遗留代码都明确说明了访问说明符，并且通常在整个定义中不一致地混合它们。我们的课程也往往很大。

我正在尝试让我的新课程足够小，以便我的课程定义类似于：

class MyClass
{
    // 3-4 lines of private variables
protected:
    //  3-4 lines of protected functions
public:
    //  public interface
}

允许遗漏冗余访问说明符，同时（希望）让private成员足够接近struct / class关键字以供参考。

为简洁起见，我是否牺牲了可读性，或struct / class个关键字是否足够？

Answer 1

如果您非常熟悉所有默认访问级别，那么如果您在不必要时省略它们，您可能不会发现可读性方面存在任何差异。

但是，您会发现许多与您合作的人不能100％确定默认的访问级别规则。对于经常使用不同语言的人来说尤其如此，因为不同语言的规则可能不同。结果他们可能会混淆规则。

始终指定访问权限是最安全的选择，如果只是为了帮助与您合作的人减少一件事情。

Answer 2

从技术上讲，类开头的“私有”或结构开头的“公共”是多余的，但我个人不喜欢混合风格，而是喜欢通过访问和声明类型进行排序。可读性对我来说更为重要。所以我会有一个“公共方法”，“私有属性”等部分，我将它们格式化为：

class A
{
public: // methods
private: // methods
private: // attributes
};

这当然也会生成冗余访问声明。另外，我喜欢先把“公共”的东西放在首位，因为这对班级用户来说是最重要的。所以，无论如何我都需要一个访问说明符。而且我也把“公共”放在“结构”的开头。

Answer 3

虽然不正确 - 严格来说 - 你的同事有一个观点;一位经验丰富的C ++程序员不需要使用默认的访问勺，但是经验不足的程序员可能会这样做。

更重要的是：我见过和使用的大多数代码都将公共内容放在第一位，这使得这个问题没有实际意义。

Answer 4

我个人认为非常明确通常是件好事。额外的代码行是为它增加的清晰度付出的小代价。

此外，它允许您轻松地重新排序您的成员（私人必须是第一个，如果它被省略，这实际上是“向后”你期望的）。如果你重新排序，并且有一个private:修饰符，其他开发人员不太可能破坏某些东西。

Answer 5

就我个人而言，我认为包含private关键字会更清楚，我会保留它。只是为了确保它是私密的，其他人也都知道它。

但我认为这是个人品味，每个人都不同。

Answer 6

我几乎总是从你的后面安排我的课程：首先是公共接口，第二是受保护的接口，最后是私有数据。这样我的类的用户可以简单地查看顶部的公共和受保护的接口，而根本不需要查看私有数据。使用该订单，就没有可能的冗余，问题就变得没有实际意义了。

如果您希望以您概述的方式组织自己的方式，我相信明确的远远超过了代码行的增益。通过这种方式，对读者的意图进行编码是完全明显的（例如，如果您将结构更改为类，或者在任何时候将结构更改为反向）。

Answer 7

我经常首先看到类/结构定义的公共部分，因此受保护/私有的东西会在以后出现。

这是有意义的，因为头文件旨在显示您的类的公共接口实际上是什么。

同时，为什么不使用struct？公开默认...

尽管如此，在代码中更清楚地知道发生了什么事情仍然是非常痛苦的。这就是为什么我避免使用三元运算符并仍然为if语句添加大括号的原因，后面只有一行代码。

最紧迫的问题是，您的公司代码标准是什么？不管你喜欢与否，这都是你应该为你的公司做的标准风格，如果他们这样做，你就这样做。