Подтвердить что ты не робот

Почему люди не задают спецификаторы доступа к С++ или случаи?

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

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Ответ 2

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

EDIT:

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

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

Ответ 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;
};

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

Ответ 4

Как и во многих других вещах, важно не допускать правила с целью. Цель отступов делает код более понятным и понятным, предоставляя дополнительный визуальный намек на то, что принадлежит. Теперь, в конкретных случаях, которые вы упоминаете, вместе с namespace s, во многих случаях дополнительный отступ не помогает в удобочитаемости. case в коммутаторе можно понимать как 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, который охватывает весь исходный файл, скорее всего, не будет отступом, а пространства имен, которые только принять участие в исходном файле будет отступом - разумно, что в первом случае он не добавляет никакого фактического значения, а во втором он делает.

Ответ 5

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

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

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

Ответ 6

Все о области охвата и группировки ветвей. Если они не затронуты, то не добавляйте уровень отступов.

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

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

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

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

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

Ответ 7

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

Ответ 8

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

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

    private:
    int top_secret;
};

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

Ответ 9

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

Я иногда делаю то, что я чувствую как старый стиль

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

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

Ответ 10

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

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

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

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