Ваше наименее любимое руководство по программированию на C ++

Question

В качестве аналога C ++ Guideline 102 , какие из 101 рекомендаций Sutter & Alexandrescu вы нарушаете или игнорируете чаще всего и почему?

Answer 1

Я сломал 19 (всегда инициализирую переменные) на этом сайте только вчера. Мой фрагмент кода был:

uint64_t i = getIEEEbitpatternByMeansRelevantToTheQuestion();
double d;
memcpy(&d, &i, 8);

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

Инициализация не POD-типов и POD-типов, являющихся членами классов, в высшей степени целесообразна. Инициализация чего-либо только для memcpy / memset, а не так много.

Фактически, одна из причин инициализации не POD заключается в том, чтобы избежать конструкции по умолчанию, которую вы просто назначаете поверх более поздней. Инициализация POD, над которым вы планируете писать, - это в основном то же самое.

У меня нет книги, поэтому, возможно, именно это они и имеют в виду, и «всегда» в названии вводит в заблуждение.

Answer 2

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

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

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

Answer 3

Время от времени мне нравится хороший актерский состав в стиле C, боюсь признаться. (Я понимаю проблемы с этим - просто не могу с собой поделать)

Answer 4

Нет. 56 - использовать вектор по умолчанию. Я часто использую deque вместо этого. Интересно, что Херб Саттер , похоже, сам противоречит этому .

Answer 5

Честно говоря, со временем у меня выработались привычки, которые почти идеально соответствуют этим принципам. Следование этим стандартам кодирования приводит к чистому, простому в обслуживании коду.

Answer 6

72. Предпочитайте использовать исключения для сообщения об ошибках.

Вместо этого я использую 72-ALT. Не бросайте исключения. :)

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

Answer 7

После просмотра всех правил это будет: 89. Правильно напишите функциональные объекты . Я никогда не найду время, чтобы написать их правильно. Иногда я использую переменные функции, но это не совсем мой выбор.

Answer 8

Я игнорирую большинство из них, потому что их можно обобщить так: используйте C ++, как если бы это был объектно-ориентированный язык высокого уровня. Но если вам нужен объектно-ориентированный язык высокого уровня, есть гораздо лучшие кандидаты (C #, Java, Lisp, Python и т. Д.). C ++ по сути является матерью всех сборщиков структурированных макросов, и я использую его как таковой, и только в тех работах, где это требуется.