Смущает ли опускание ключевого слова "private" в определении класса?

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

Технически, "private" в начале класса или "public" в начале структуры является избыточным, однако лично мне не нравится смешанный стиль, а скорее порядок по доступу и типу объявления. Читаемость для меня важнее как краткость. Поэтому у меня будет раздел «публичные методы», «приватные атрибуты» и т. Д., И я отформатирую их так:

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

Это, конечно, также генерирует объявления избыточного доступа. Кроме того, мне нравится ставить «публичные» вещи на первое место, потому что это наиболее важно для пользователей класса. Итак, мне все равно нужен спецификатор доступа в начале. И я помещаю "public" в начале "struct".

Answer 3

Лично я считаю, что быть очень откровенным, как правило, хорошо. Дополнительная строка кода - это небольшая цена за ясность, которую он добавляет.

Кроме того, он позволяет вам легко переупорядочивать своих участников (private должен быть первым, если он опущен, что на самом деле «назад», чем вы ожидаете). Если вы измените порядок и на месте есть модификатор private:, другие разработчики с меньшей вероятностью что-то сломают.

Answer 4

Хотя неверно - строго говоря - у вашего коллеги есть точка зрения;опытному программисту на C ++ не нужна поданная им ложка доступа по умолчанию, но менее опытный программист может.

Более конкретно: большая часть кода, с которым я сталкивался и с которым работал, ставит общедоступные вещи на первое место, чтоделает вопрос спорным.

Answer 5

Сначала я часто вижу открытую часть определения класса / структуры, поэтому защищенный / приватный материал появляется позже.

Это имеет смысл, так как заголовочный файл предназначен для того, чтобы показать, каким на самом деле является открытый интерфейс для вашего класса.

В то же время, почему бы не использовать struct? общедоступный по умолчанию ...

Тем не менее, в вашем коде никогда не помешает быть более ясным в отношении того, что происходит. Это та же самая причина, почему я избегаю троичного оператора и все еще вставляю фигурные скобки для оператора if, который имеет только одну строку кода после него.

Самая насущная проблема, каковы стандарты стандартов вашей компании? Нравится вам это или нет, это стандартный стиль, который вы должны сделать для своей компании, если они говорят, что делают это таким образом, вы делаете это таким образом.

Answer 6

Я почти всегда размещаю свои классы в обратном направлении от ваших: сначала общедоступный интерфейс, затем любой защищенный интерфейс, а затем личные данные.Это сделано для того, чтобы пользователи моих классов могли просто смотреть на общедоступные и защищенные интерфейсы сверху и вообще не должны просматривать личные данные.Если использовать этот порядок, то нет никакой возможной избыточности, и вопрос станет спорным.

Если вы предпочитаете упорядочить свой метод так, как вы обрисовали, я считаю, что явный отклик намного превосходит преимущество кода.Таким образом, для читателей кода совершенно очевидно, каково намерение (например, если вы измените структуру на класс или наоборот в любой точке).

Answer 7

Лично я думаю, что с ключевым словом private все намного яснее, и я бы его сохранил. Просто чтобы убедиться, что это личное и все остальные тоже это знают.

Но я предполагаю, что это личного вкуса и отличается для всех.