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

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

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

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

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

№ 56 - Использовать вектор по умолчанию. Вместо этого я часто использую дек. Интересно, что Herb Sutter кажется, что он не согласен с этим сам.

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

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

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

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

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

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

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

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

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

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

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

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