Стиль кода, краткость и конкурентные преимущества

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

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

Для запятых в начале строк (или других операторов в многострочных выражениях) есть ещё одно обоснование — более компактные диффы при добавлении ещё одной переменной/подвыражения.

Многие вещи кажутся действительно неразумными и необоснованными. Другие сам давно использую, например { на той же строке.
А в класс New я бы все-таки добавил variadic templates из С++11.

        template <typename ... Args>
        New (Args ... args) {
            d = new Class(args...);
        }

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

Зачем вообще запятые ставить в начало?

Посмотрите, как отличается diff между старой и новой версиями при добавлении строки в конец. В варианте с запятыми в конце в diff'е будет две измененных строки. Если запятые в начале — только одна.

Как бы мелочь, но при мержах разных веток кода бывает приятно.

Какое-то уж оооочень притянутое за уши обоснование нового внезапно любимого стиля соображениеми энергоэффективности и увеличением продуктивности.

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

Отсутствие пробельной строки между методами, — это ухудшение читаемости кода.

Кто-нибудь еще кроме автора переучивался писать открывающую скобу на той же строке?
Как результат?

Если уж так прямо волнует отсутствие единообразия синтаксиса, могу предложить сравнить с языком Python, который, кстати, имеет отличную библиотеку обвязки С++ boost::python
Python:

if a < b: # без вариантов
    a = c
    func( b * b )
else: # без вариантов
    b = c
    func( a * a )

C++:

if( a < b ) { // или всё же на следующей строке?
    a = c;
    func( b * b );
} // или всё же на той же строке, что и else! а может вообще на предыдущей!
else { // или всё же на следующей строке?
    b = c;
    func( a * a );
} // или всё же на следующей строке?

На самом деле просто нужно иногда менять привычные вещи. Задействовать левое полушарие по полной. Пересесть на мак с писи, перепрошить коммуникатор, поменять стиль кода — это всё одного поля ягоды. Уверен, что через 3 года вы так же ръяно будете отстаивать египетские скобки.

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

В целом правила интересные, но хотелось бы добавить несколько мыслей.

Includes
Если некоторый файл довольно насыщен функционалом, то у него может быть до 15 инклюдов. В таком случае имеет смысл визуально разбить инклюды на группы — свои заголовочные файлы, сторонние и системные.

Однозначно, такой файл, как всемирно известный stdafx.h, тоже желательно «разбавить» переводами строк, поскольку инклюды — это и есть его основное содержание.

forward declarations в моей практике очень редко требовались для компиляции всего файла, гораздо чаще они требовались исключительно для одного конкретного блока кода:

class some_class;
class some_other_class {
public:
  typedef some_class some_identifier;
}

В таком случае я предпочитаю писать подобные связанные объявления рядом, а не «утаскивать» в начало файла.

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

Имена. Те, кто считает, что some_name и someName отличаются на одно нажатие ужасной комбинации «Shift+_», ошибаются: заглавные буквы тоже требуют нажатия шифта, так что отличаются эти два стиля только одним нажатием дефиса. Да, на некоторых клавиатурах дефис задвинут в какое-то ужасное место, но я почему-то считаю, что это проблема исключительно владельцев плохих клавиатур.

Между тем, в C++ существуют сущности, одинаковые с точки зрения языка, но зачастую совершенно разные семантически: классы и умные структуры. Классы — это понятие ООП, для них характерны наследование и полиморфизм, хотя они и могут быть созданы на стеке или включены в другой класс как поле, это считается плохим стилем, и потому объекты, как правило, передаются только по указателю. Существует даже такая разновидность классов, как абстрактные, и их-то по значению вообще никогда не передают.

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

Мое предложение — использование различных стилей наименования для отделения классов от структур:
классы — IDataQuery, DataStore, PersonCollection;
объекты — dataQuery, dataStore, personCollection;
структуры (как типы, так и переменные) — shared_ptr, scope_lock, native_holder.

Комментарии начала файла не нужно делать короче — их нужно просто выкинуть.

Попробуйте взглянуть на стилистические конвенции не с точки зрения экономии вертикального места (почти все ЖК-мониторы прекрасно поворачиваются на 90% и организовать ide/консоль в несколько колонок тоже не сложно), а с точки зрения уменьшение вероятности возникновения ошибки при его изменении или написании.

По скобкам (и прочим конвенциям для C-подобного синтаксиса) стоит почитать МакКоннела, честно говоря мне сложно представить кто и что может сказать по этому вопросу после него.

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