Почему люди не делают отступ в C ++ для доступа к спецификаторам / операторам case?

Question

Я часто вижу такие вещи:

class SomeClass {
public:
    void someMethod();
private:
    int someMember;
};

Это кажется мне совершенно неестественным (то же самое относится к case заявлениям при использовании switch). Когда я начал использовать C ++, я ожидал чего-то подобного (с тех пор прошло много времени, но мне все еще интересно):

class SomeClass {
    public:
        void someMethod();
    private:
        int someMember;
};

Есть ли обоснованная причина для нарушения (иным образом) согласованных правил отступов?

Answer 1

Увеличение отступа обычно отражает вход в новую вложенную область, в то время как и спецификаторы доступа, и операторы switch case не изменяют область (то же самое относится и к меткам в целом).Спецификаторы доступа могут быть необязательными в том смысле, что вы можете начать реализацию класса или структуры, и всем членам требуется только подразумеваемый доступ (т. Е. Закрытый и открытый соответственно), но затем код развивается, и вам необходимо добавить спецификатор для неявногоДоступ к участникам: действительно ли стоит внезапно менять отступ для всех участников?Опять же, нет вложенной области видимости, так что я думаю, что это будет вводить в заблуждение.

Если вы работаете с терминалами фиксированной ширины и соответственно оборачиваете свои линии, переиндентирование - это боль.Но полезно, чтобы спецификаторы доступа выделялись среди членов, что означает их откладывание где-нибудь влево - либо в соответствии с ключевым словом class, либо частично там.

Лично я делаю это:

class X
{
  public:
    int member_function()
    {
        switch (expression)
        {
          case X:
            return 6;

          default:
          {
            int n = get_value() / 6;
            return n * n;
          }
        }
    }

  private:
    int member_variable_;
};

Почему я не делаю код отступа для каждого case дальше?Я не могу утверждать, что то, что я делаю, является особенно логичным, но факторы включают в себя:

• Я не хочу преуменьшать значение общего отступа switch / case, как визуально сообщая степеньПереключатель важен для быстрого понимания кода
• Я счастлив просто поместить { и } вокруг существующего кода case - больше похоже на комментарий «эй, мне нужна область» - скореечем заставлять отступать все дальше, что не имеет особого смысла даже для меня, но кажется правильным - мне нравится иметь код для каждой case цепочки
• , некоторые компиляторы предупреждают, если вы вводите новуюпеременные в операторе case без введения области действия, даже если не было случаев, когда переменная впоследствии использовалась потенциально неинициализированной
• Обычно я кодер из 80 столбцов, обычно с 4 пробелами, поэтомувнутри switch - и, следовательно, очевидно, функции - означает, что оставшиеся столбцы являются ценными.

То же самое для class / struct:

• Я хочу отсканировать левый столбец и быстро найти конец класса или легко подсчитать небольшие классы на экране или в распечатке;Спецификаторы доступа с точно таким же уровнем отступа исключают ключевое слово class, но оно помогает их визуально отличать от членов (если класс / структура содержит несколько строк, я также заранее добавляю пустую строку)
• Я не хочу менять существующий класс / отступ члена структуры, когда я ввожу спецификатор private или protected

В заключение: множество мелких факторов влияют на развитиепредпочтения людей в отступах, и если вы хотите быть программистом C ++ в корпоративной среде - особенно подрядчиком - вам просто нужно идти по течению и иногда иметь возможность изменить свой собственный стиль (например, я сейчас застрял в camelCaseLand), с открытыми переменными-членами, начинающимися с заглавной буквы - yikes!).Не парься - это того не стоит.

Answer 2

Спецификаторы доступа на самом деле являются просто метками (как в тех, которые используются goto).Люди обычно не делают отступы над метками и не отступают от них на один уровень по отношению к окружающему коду.Поэтому я бы сказал, что это совсем не противоречит.

РЕДАКТИРОВАТЬ:

Стандарт также использует этот стиль для спецификаторов доступа.Пример из главы 10, параграф 2:

class Base {
public:
  int a, b, c;
};

Answer 3

Представьте себе такое определение класса:

class SomeClass {
    void ImplicitlyPrivateMethod();
public:
    void someMethod();
private:
    int someMember;
};

При предложенном вами стиле отступа нужно изменить его на

class SomeClass {
        void ImplicitlyPrivateMethod();
    public:
        void someMethod();
    private:
        int someMember;
};

(что для многих не очень приятно)люди, особенно если «неявный» раздел достаточно длинный).

---

Я лично предпочитаю половину отступа таких спецификаторов:

class SomeClass {
    void ImplicitlyPrivateMethod();
  public:
    void someMethod();
  private:
    int someMember;
};

Но это вопрос личного вкуса.

Answer 4

Как и во многих других вещах, важно не перепутать правило с целью.Цель отступа - сделать код более понятным и легким для чтения, предоставляя дополнительную визуальную подсказку о том, что и где находится.Теперь, в отдельных случаях, которые вы упоминаете, вместе с namespace s, во многих случаях дополнительные отступы не помогают в удобочитаемости.case s в переключателе можно понимать как if-else s, где вы не добавили бы дополнительный отступ.Это разделители блоков , подобные фигурным скобкам.

switch ( var ) {  
case 1:          // if ( var == 1 ) {
   code;
case 2:          // } else if ( var == 2 ) {
   code;
}

На уровне класса модификаторы доступа можно рассматривать как разделители блоков на том же уровне, что и класс.Добавление дополнительного уровня отступа не делает код более понятным:

class test {
public:
   void foo();
private:
   int member;
};

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

Лично я никогда не делаю отступ для case или модификаторов доступа, в случае namespace s, это зависит ... a namespace, охватывающий весь исходный файл, скорее всего, не будет иметь отступ,в то время как пространства имен, которые принимают только часть исходного файла, будут с отступом - логическое обоснование состоит в том, что в первом случае это не добавляет фактического значения, в то время как во втором это делает.

Answer 5

Две возможные причины:

• так Бьярн Страуструп делает отступ в своих книгах

• большинство текстовых редакторов делают такие отступы автоматически

Answer 6

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

Возьмем, к примеру, следующее:

if( test == 1 ) {
    action1( );
} else if( test == 2 ) {
    action2( );
} else {
    action3( );
}

Обратите внимание на уровни блоков операторов. Теперь переписать его в качестве оператора case с отступом case:

switch( test ) {
    case 1:
        action1( );
        break;
    case 2:
        action2( );
        break;
    default:
        action3( );
        break;
}

Это делает то же самое функционально, но отступы не соответствуют моим действиям. И я думаю, что именно это несоответствие, наконец, заставило меня отказаться от лишних ложных отступов. (Хотя я не возражаю против того, чтобы наполовину отступать предлагали другие, заметьте.)

Answer 7

Поскольку public и private являются метками, которые не вводят новую область видимости, я предпочитаю не давать им никаких специальных отступов, таким образом:

class foo {
    public:
    void something();
    void something_else();

    private:
    int top_secret;
};

Таким образом, правило согласованного отступаэто «отступ равен объему».

Answer 8

Очень мало строк модификаторов доступа на класс, и большинство редакторов модификаторов цвета отличаются от всего остального. Они выделяются сами по себе, так зачем добавлять ненужные вкладки?

Answer 9

Как упоминалось ранее (хотя и аргументировано для модификаторов доступа без отступов), модификаторы доступа образуют логические блоки.Хотя они находятся на том же уровне, что и скобки класса, они являются особыми.

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

Я лично думаю, что это делаеткод яснее.Другие не согласятся.

Это довольно субъективный вопрос.

Answer 10

Большинство редакторов делают отступы автоматически, для себя я оставляю их в виде небольших классов или небольших файлов или операторов короткого переключения, но для длинных или длинных файлов со многими операторами длинного переключения я использую больше отступов для облегчения чтения1002 * Иногда я делаю это, что мне кажется старым стилем

Class CClass
    {
            CClass();
            ~CClass();
        Public:
            int a;
        Private:
            int b;
     };
CClass::CClass
      {
           TODO code;
      }

Это иногда облегчает ситуацию, когда файл может содержать более 20 или 50 функций, чтобы вы могли легко определить начало каждой функции