Руководство Google по стилю в C++. Часть 11

[Reformat]

Не используйте #pragma once. Вместо этого используйте стандартную защиту от повторного включения, описанную в руководстве от Google. Компоненты пути в имени для макроопределения защиты должны быть относительными к корню проекта.

Какие-то вредные советы.

[NN1]

Вполне возможная причина это компиляторы, неподдерживающие эту прагму.

Гугл компания немолодая, мало ли какое старьё у них в закромах :)

[VXP]

Даже компилятор из поставки Visual C++ 6.0 поддерживает

[SShtole]

И, кстати, насколько позволяет вспомнить мой склероз, в исходниках, которые генерировала VC6, комбинировались оба подхода: в хедер в начале записывалась прагма, а остальная часть включалась в #ifdef-«скобки» (извините, что я использую такое просторечное выражение вместо гугловского «макроопределение защиты» 8-P).

[NN1]

Это правильный и переносимый вариант.

ifdef умеют все компиляторы, а если знакомы с pragma once, то используем.

И волки сыты и овцы целы.

[SShtole]

Не используйте венгерскую нотацию (например, именование целочисленной переменной как iNum)

Это НЕ венгерская нотация, а то, что с ней стало, когда она попала в руки профанов. Изначально Чарльз Симоньи предлагал использовать такие префиксы, как rw для записей (rows), например, rwPosition, us (unsafe string) для строк, нуждающихся в санации (на предмет инъекций и т.п.), d (delta) для разницы зачений, например, dY. Большинство префиксов были семантические и никакой IDE никогда не смог бы верно указать эту семантику при наведении курсора. (Как любят аргументировать противники венгерки). Ну, разве что такие префиксы как pX говорят о типе, но тип указателя — сам по себе семантический.

Потом всё это дело опопсело и упростилось, и действительно стало дублировать информацию о типе, после чего венгерка разделилась на т.н. прикладную и системную. Последнюю иначе как профанацией идеи назвать трудно.

Что касается первой, она, насколько можно судить, во многих местах жива и поныне. Просто теперь префикс принято записывать целиком, не экономя ширину экрана: deltaY и т.д.

Составителям правил оформления, тем более из Гугл, знать такие тонкости, по идее, не помешало бы.