Добрый день.

Давным-давно в нескольких разных конторах разные товарищи нестандартной программистской ориентации склоняли меня к принятию "корпоративных стандартов кодирования".
Конторы были полное г... и "корпоративный стандарт кодирования" сводился к форматированию кода так, как привык ближайший микроначальник.
В одной из этих контор ближайший микроначальник был натуральным майором Красной Армии со всеми вытекающими понятиями о...
Тогда я отбился от них, предъявив утилиту indent и сказав им: "при помощи этой утилиты вы можете отформатировать код как вам удобно".
Однако осадок остался.

В связи с этим вопросы:

1. Как у нас теперь обстоит дело с рекомендуемым/не рекомендуемым стилем кодирования?
2. Что об этом говорят классики от Страуса до Микрософта?
3. Поддерживает ли Микрософт по-прежнему венгерскую нотацию?
4. Если нет, то что он поддерживает?

Спасибо.

P>Давным-давно в нескольких разных конторах разные товарищи нестандартной программистской ориентации склоняли меня к принятию "корпоративных стандартов кодирования".
P>Конторы были полное г... и "корпоративный стандарт кодирования" сводился к форматированию кода так, как привык ближайший микроначальник.
P>В одной из этих контор ближайший микроначальник был натуральным майором Красной Армии со всеми вытекающими понятиями о...
P>Тогда я отбился от них, предъявив утилиту indent и сказав им: "при помощи этой утилиты вы можете отформатировать код как вам удобно".
P>Однако осадок остался.

не знаю на счет венгерских нотаций, однако для меня никогда не было проблемой использовать разные стили форматирования кода. и как-то я это не воспринимаю как насилие или диктаторство.
и переключаться между ними легко (для себя, допустим, пишешь так и делаешь так, на работе — как положено). дисциплина — это здорово, иначе большие проекты выродятся в срач и помойку.

тут вот меня недавно попросили ограничить строки 80-тью символами. я нахожу это требование дебильным, у меня здоровенный монитор и бывают довольно-таки длинные строки
(например, выражение + строка с внятным сообщением в ассерте). но в этой части нашего фреймворка весь код оформляется таким образом — ну так ладно, мне не жалко. пусть будет 80.

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

Здравствуйте, pepsicoca, Вы писали:

P>1. Как у нас теперь обстоит дело с рекомендуемым/не рекомендуемым стилем кодирования?
P>2. Что об этом говорят классики от Страуса до Микрософта?
P>3. Поддерживает ли Микрософт по-прежнему венгерскую нотацию?
P>4. Если нет, то что он поддерживает?

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

рекомендуемый всеми стандарт кодирования — это "использовать однообразное оформление кода, хотя бы в пределах одного файла"
в остальном все оформляют код как хотят. вещи типа "int* x" vs "int *x" никак не влияют на защищенность кода от ошибок.

Здравствуйте, pepsicoca, Вы писали:

P>1. Как у нас теперь обстоит дело с рекомендуемым/не рекомендуемым стилем кодирования?
P>2. Что об этом говорят классики от Страуса до Микрософта?
P>3. Поддерживает ли Микрософт по-прежнему венгерскую нотацию?
P>4. Если нет, то что он поддерживает?

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

В тех проектах, где это от меня зависит, я стараюсь придерживаться следующих принципов:
1. Правишь уже написанный кем-то файл — соблюдай принятый в нем стандарт кодирования
2. Пишешь свой новый файл, можешь следовать привычному тебе стандарту кодирования. Но он должен быть легко читаемым и не слишком уж вычурным.
3. Табуляции запрещены, если только не навязаны огромным объемом чужого кода, доставшегося по наследству
4. Политика именования глобальных символов является единой в пределах проекта (если обратное не навязано унаследованным кодом).

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

Думаю, это повсеместно (по крайней мере я с таким встречался тоже).
Каждый (микро-начальник) считает свой огород самым правильным. Твоя задача на испытательном сроке угадать чего хочет начальник.

A>в остальном все оформляют код как хотят. вещи типа "int* x" vs "int *x" никак не влияют на защищенность кода от ошибок.
Это Вы зря, есть фирмы (микро-нчальники), которые за лишний пробел фейсом о тейбл

HN>Каждый (микро-начальник) считает свой огород самым правильным.

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

>Твоя задача на испытательном сроке угадать чего хочет начальник.

стандарты кодирования есть и ничего угадывать не надо — их никто и не скрывает.

L_L>стандарты кодирования есть и ничего угадывать не надо — их никто и не скрывает.

Стандартам надо следовать.
ps: про угадывание — это я о своем...

Здравствуйте, HolyNick, Вы писали:

L_L>>стандарты кодирования есть и ничего угадывать не надо — их никто и не скрывает.

HN>Стандартам надо следовать.
HN>ps: про угадывание — это я о своем...

А, ок, я не так понял, стало быть.

Здравствуйте, HolyNick, Вы писали:

A>>в остальном все оформляют код как хотят. вещи типа "int* x" vs "int *x" никак не влияют на защищенность кода от ошибок.
HN>Это Вы зря, есть фирмы (микро-нчальники), которые за лишний пробел фейсом о тейбл
Из личных наблюдений — код оформленный аккуратно (отсутствие лишних пробелов и пустых строк в том числе) менее подвержен логическим ошибкам. Такой код более понятен, более чувствуется идея автора. Такой код проще поддерживать. Всегда, абсолютно всегда, программист неаккуратно оформляющий код имеет такой же бардак в голове — как следствие поток сознания в коде.

Здравствуйте, real_sba, Вы писали:

_>Здравствуйте, HolyNick, Вы писали:

A>>>в остальном все оформляют код как хотят. вещи типа "int* x" vs "int *x" никак не влияют на защищенность кода от ошибок.
HN>>Это Вы зря, есть фирмы (микро-нчальники), которые за лишний пробел фейсом о тейбл
_>Из личных наблюдений — код оформленный аккуратно (отсутствие лишних пробелов и пустых строк в том числе) менее подвержен логическим ошибкам. Такой код более понятен, более чувствуется идея автора. Такой код проще поддерживать. Всегда, абсолютно всегда, программист неаккуратно оформляющий код имеет такой же бардак в голове — как следствие поток сознания в коде.

Это все понятно. Просто у всех свои понятия об аккуратности и правильности кода\архитектуры итп.

Здравствуйте, Abyx, Вы писали:

A>венгерская нотация, т.е. добавление информации о типе переменной в ее имя, появилась не просто так, и она действительно нужна если у компилятора слабая типизация или он не может статически проверить тип переменной.
A>т.е. она нужна для кода на Си, и почти не нужна для качественного кода на С++.

Не-не-не. pxHeight, yearEstablished, hashLookup, countLines — это всё может быть один и тот же целочисленный тип, но с точки зрения предметной области типы этих данных несовместимы — например, сложить одно с другим было бы бессмысленно. Так что венгерская нотация, т. е. добавление информации о типе (о том, какую информацию содержит, а не о деталях реализации) переменной в ее имя, помогает избежать ошибок во многих случаях.

А глупая венгерская нотация в стиле lpsz бесполезна как в C, так и где бы то ни было.

Здравствуйте, pepsicoca, Вы писали:

P>2. Что об этом говорят классики от Страуса до Микрософта?

это такой тонкий троллинг?

Здравствуйте, Roman Odaisky, Вы писали:
RO>Не-не-не. pxHeight, yearEstablished, hashLookup, countLines — это всё может быть один и тот же целочисленный тип, но с точки зрения предметной области типы этих данных несовместимы — например, сложить одно с другим было бы бессмысленно. Так что венгерская нотация, т. е. добавление информации о типе (о том, какую информацию содержит, а не о деталях реализации) переменной в ее имя, помогает избежать ошибок во многих случаях.
ошибки подобного рода возникают когда у нас огромная область видимости переменных и замудренная логика их жонглирования. короче говоря, говнокод.

Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, Abyx, Вы писали:

A>>венгерская нотация, т.е. добавление информации о типе переменной в ее имя, появилась не просто так, и она действительно нужна если у компилятора слабая типизация или он не может статически проверить тип переменной.
A>>т.е. она нужна для кода на Си, и почти не нужна для качественного кода на С++.

RO>Не-не-не. pxHeight, yearEstablished, hashLookup, countLines — это всё может быть один и тот же целочисленный тип, но с точки зрения предметной области типы этих данных несовместимы — например, сложить одно с другим было бы бессмысленно. Так что венгерская нотация, т. е. добавление информации о типе (о том, какую информацию содержит, а не о деталях реализации) переменной в ее имя, помогает избежать ошибок во многих случаях.

вобщем-то я об этом и писал.

RO>А глупая венгерская нотация в стиле lpsz бесполезна как в C, так и где бы то ни было.
psz полезно тем что отличается pwsz. "l" в "lp" тоже была когда-то полезна, а сейчас уже это просто традиция.

Здравствуйте, Abyx, Вы писали:

A>psz полезно тем что отличается pwsz.
А в чем польза? Типы разные, если ошибешься — компилятор даст тебе по рукам

Здравствуйте, enji, Вы писали:

E>Здравствуйте, Abyx, Вы писали:

A>>psz полезно тем что отличается pwsz.
E>А в чем польза? Типы разные, если ошибешься — компилятор даст тебе по рукам

например если кастовать к INT_PTR, то не даст.
бывают такие функции — FooW(..., INT_PTR param)

Здравствуйте, Roman Odaisky, Вы писали:

RO>Не-не-не. pxHeight, yearEstablished, hashLookup, countLines — это всё может быть один и тот же целочисленный тип, но с точки зрения предметной области типы этих данных несовместимы — например, сложить одно с другим было бы бессмысленно.

Это должен отслеживать компилятор. Самое печальное в том, что языки с метапрограммированием (тот же C++, а также Nemerle) могут это. Увы, народ до сих пор боится макросов.

Здравствуйте, __kot2, Вы писали:

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

Не обязательно. Например, бинарный поиск (std::equal_range) по массиву каких-то объектов. Нашел первый объект по индексу ixFirst и с неким идентификатором (например, ключ в БД) idFirst, аналогично ixLast и idLast. Вот вычесть ixFirst из ixLast нормально, а id из id не очень.

Здравствуйте, Roman Odaisky, Вы писали:
RO>Не обязательно. Например, бинарный поиск (std::equal_range) по массиву каких-то объектов. Нашел первый объект по индексу ixFirst и с неким идентификатором (например, ключ в БД) idFirst, аналогично ixLast и idLast. Вот вычесть ixFirst из ixLast нормально, а id из id не очень.
ну тогда уж надо писать ixfst и ixlst — пусть все голову ломают что бы это значило