Группирование одинаковых типов переменных-членов вместе
При написании класса вы группируете вместе переменные-члены одного типа? Есть ли в этом польза? Например:
class Foo
{
private:
bool a_;
bool b_;
int c_;
int d_;
std::string e_;
std::string f_;
...
};
В отличие от:
class Bar
{
private:
std::string e_;
bool a_;
int d_;
bool b_;
std::string f_;
int c_;
.
.. };
Или вы просто располагаете их в том порядке, в котором они были добавлены?
Ответы 8
Вы должны располагать их в том порядке, в котором вы хотите, чтобы они инициализировались, потому что именно в том порядке, в котором они будут инициализированы, независимо от вашего списка инициализаторов в конструкторе. Не все компиляторы также предупреждают вас о несоответствиях.
Я группирую их по семантике, т.е.
class Foo
{
private:
std::string peach;
bool banana;
int apple;
int red;
std::string green;
std::string blue;
...
};
Чем читабельнее, тем лучше.
Просто хочу добавить небольшой указатель на ответ Алистера ниже! Члены будут инициализированы в том порядке, в котором они появляются в определении класса, а не в том порядке, в котором они появляются в списке инициализаторов ctor! Так что вы должны иметь это в виду и не можете заказать их полностью по своему вкусу!
Если вам важен размер ваших объектов, и если компилятор не переупорядочивает члены внутри класса (если между членами нет спецификаторов доступа, он не должен переупорядочивать), тогда объекты могут получиться меньше, если вы упорядочиваете своих участников от самых больших до самых маленьких. Причина в том, что меньше вероятность того, что потребуется заполнение для удовлетворения требований выравнивания. Такой порядок приведет к тому, что члены одного типа будут ближе друг к другу.
По сравнению с ясностью кода это обычно проигрывает. По сравнению с порядком инициализации, конечно, он всегда проигрывает (хотя вы можете добавить спецификаторы доступа и надеяться на лучшее). Но вы спросили, есть ли выгода от Любые.
- Группируйте семантически.
- Если вам нужно сгруппировать семантически, это запах кода. Извлеките класс. К счастью для вас, связанные участники уже находятся в группе, поэтому выбрать подходящих для переезда несложно.
В большинстве случаев у вас не должно быть слишком много членов в структуре.
Если да, может, стоит подумать о подструктурах ...
Я знаю, что есть исключения, но, как правило, старайтесь, чтобы ваши структуры были небольшими.
В порядке эффективного приоритета:
0) Члены ЕСЛИ имеют зависимости между собой при построении ИЛИ, если члены должны быть построены в определенном порядке: объявите их в порядке построения, который вы хотите выполнить. При построении единственный порядок построения членов - это порядок объявления членов в классе.
0.5) ЕСЛИ размер объекта экземпляра класса имеет значение (вам нужен минимальный размер для этого типа, но не выполняйте раннюю оптимизацию!), С некоторыми компиляторами лучше упорядочить ваши члены в порядке размера, чем больше первый, для выравнивания байтов или другое подобное поведение при компиляции.
1) В первую очередь установите ЯСНОСТЬ: сначала напишите для читателя (будьте ясны, упорядочивайте тематические / целевые группы и т. д.), Затем для компилятора (возможно, следуя предыдущим советам).
Почти во всех случаях важен только 1). Предпочитайте тематические, целевые и «составные части одной системы» для группировки членов, а не группировки по типу.
Примечание: если вы группируете своих участников по системе и видите, что у вас много групп, возможно, вам стоит инкапсулировать эти системы в классы.
Я согласен с другими в отношении некоторых причин для упорядочивания переменных, но помимо этого мне нравится видеть переменные, которые наиболее важны для работы класса, ближе к началу, а переменные, которые менее важны, ближе к концу. Если у вас есть другие причины игнорировать это, хорошо, но когда другие вещи терпят неудачу, я делаю это.
Конечно, это обычно заканчивается объявлением переменных в том порядке, в котором они возникают у меня. Наиболее важные переменные - это те, о которых я думаю в первую очередь, и другие, с которыми я сталкиваюсь, когда фактически пишу реализацию класса.
Из Кодекса Стива МакКоннелла, стр. 762: -
Order declarations sensibly: ... Grouping by types is usually sensible since variables of the same type tend to be used in related operations ... If your list of variables is so long that alphabetical ordering helps, your routine is probably too big.
Кроме того, на предыдущей странице он применяет стиль из моего предыдущего ответа, показывающий, что несколько объявлений "скопились" в одной строке ...
bool a_, b_, c_;
... со значком "Coding Horror". Так что я пересматриваю этот подход. Спасибо комментаторам за то, что заставили меня переоценить это.
+1, но лучше разрабатывать классы таким образом, чтобы порядок инициализации не имел значения - именно потому, что слишком легко ошибиться без даже предупреждения.