Какие есть причины размещать функции-члены перед переменными-членами или наоборот?

Question

Учитывая класс, какие существуют причины для любого из двух следующих стилей кода?

Style A:
class Foo {
    private:
        doWork();

        int bar;
}

Style B:
class Foo {
    private:
        int bar;

        doWork();
}

Для меня они галстук. Мне нравится Стиль A, потому что переменные-члены кажутся более детализированными и, таким образом, будут появляться после более общих функций-членов. Однако мне также нравится Стиль B, потому что переменные-члены, похоже, определяют в стиле ООП, что представляет класс.

Есть ли другие вещи, которые стоит учитывать при выборе между этими двумя стилями?

Answer 1

В C ++ для тех, кто использует класс, характерно смотреть на определение в коде в заголовочном файле.

В Java распространенным (но не универсальным) для тех, кто использует класс, является просмотр документации, сгенерированной из комментариев JavaDoc. IDE поддерживают стиль B.

Таким образом:

• В C ++ я использую стиль A, размещая открытый интерфейс в верхней части заголовочного файла.
• В Java я использую стиль B, размещая данные над методами.

Answer 2

По крайней мере, вы правы, это всего лишь стиль. И единственная причина стиля (руководства) - сделать код более читабельным (для огромной аудитории).

Поскольку стиль B более распространен, больше читателей сочтут его более приятным для чтения (и могут читать его быстрее, чем стиль A). И это причина, почему вы должны использовать стиль B (по крайней мере, для Java, C #, PHP ...)

Answer 3

Программирование на C ++. Мой предпочтительный стиль - A, где акцент делается на API, которым обладает класс. Примерно так:

class SomeClass
{
public:
    void foo();
    void bar(int i);

private:
    int m_i;
};

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

С другой стороны, например, (низкоуровневая) структура сообщения. Я мог бы поспорить за противоположное, когда участники первыми предоставят читателю эту информацию, так как это может быть самой важной. Как то так:

struct SomeMessage
{
    uint64_t m_id;
    int32_t  m_number;
    char     m_name[16];

    explicit SomeMessage(uint64_t id);
};

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

Answer 4

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

class A {
    int bar;
public:
    doWork();
};

Answer 5

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

Answer 6

Если вы посмотрите на UML Class Diagram , вы увидите, что блок состоит из трех частей: верхняя часть содержит имя класса, средняя содержит атрибуты, а нижняя содержит методы.

Итак, я тоже так люблю писать свой код, так как он больше похож на мой дизайн.

Answer 7

Как бы то ни было, меня учили стилю B, и я вижу этот стиль гораздо чаще, чем стиль A. Кроме того, некоторые языки (в частности, Unreal Script, если вы хотите назвать его языком), применяют стиль B через компилятор проверка.

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