Добрый день.

Давным-давно в нескольких разных конторах разные товарищи нестандартной программистской ориентации склоняли меня к принятию "корпоративных стандартов кодирования".
Конторы были полное г... и "корпоративный стандарт кодирования" сводился к форматированию кода так, как привык ближайший микроначальник.
В одной из этих контор ближайший микроначальник был натуральным майором Красной Армии со всеми вытекающими понятиями о...
Тогда я отбился от них, предъявив утилиту 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 — пусть все голову ломают что бы это значило

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

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

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

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

A>и как Вы хотите делать такие проверки с помощью макросов в С++ ?

http://www.rsdn.ru/forum/src/1824757.flat

Автор: CrystaX
Дата: 06.04.06

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

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

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

бывают, но это обычно уже не С++. Исходный посыл был — в с++ от венгерской нотации толку мало. А такие касты в плюсах обычно оборачивают и в клиентском коде они редки

Здравствуйте, pepsicoca

Стиль кодирования в компании должен быть обязательно! И каждый программист должен кодировать в соответствии с этим стилем. Всех несогласных на первый раз можно анально карать. На второй — выгонять нафиг.

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

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

Ну в данном случае читабельность от сокращения ничуть не пострадала — все предельно ясно.
Есть разумное соглашение: длина имени переменной определяется ее областью видимости. Чем больше область видимости, тем длиннее и подробнее имя.

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

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

У меня тоже монитор широкий, но в vim у меня одновременно открыто шесть окон тайлами, вот ширина одного окна и получается 80

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

P>1. Как у нас теперь обстоит дело с рекомендуемым/не рекомендуемым стилем кодирования?

По разному бывало. Если исходный код читает менее пять человек, то можно договориться. В некоторых проектах каждый коммит был через review. Несоблюдение стандартов кодирования это повод отклонить твой коммит. Ну а все проблемы, что фича не сделана, это твои.

P>3. Поддерживает ли Микрософт по-прежнему венгерскую нотацию?

А вопрос о венгерской нотации или о стандартах кодирования?

Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Ну в данном случае читабельность от сокращения ничуть не пострадала — все предельно ясно.
SVZ>Есть разумное соглашение: длина имени переменной определяется ее областью видимости. Чем больше область видимости, тем длиннее и подробнее имя.
меня продолжает убивать такой подход к именованию. любая команда, где разработка ведется хотя бы несколько лет быстро начинает заполонять проект акронимами. для любого новичка это все сплошной дремучий лес, это примерно как церковнославянский — вроде бы что-то похожее где-то видел и догадаться можно, но читать невозможно и часто неправильно все понимаешь.

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

__>Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>>Ну в данном случае читабельность от сокращения ничуть не пострадала — все предельно ясно.
SVZ>>Есть разумное соглашение: длина имени переменной определяется ее областью видимости. Чем больше область видимости, тем длиннее и подробнее имя.
__>меня продолжает убивать такой подход к именованию. любая команда, где разработка ведется хотя бы несколько лет быстро начинает заполонять проект акронимами. для любого новичка это все сплошной дремучий лес, это примерно как церковнославянский — вроде бы что-то похожее где-то видел и догадаться можно, но читать невозможно и часто неправильно все понимаешь.

Да это полбеды, привыкаешь быстро. Тем более, когда именование более менее стандартизовано и имена выбираются так, как написал Роман чуть выше.
А вот понять без комментариев, что делает код в целом — вот за это точно убивать надо. На месте. Из рогатки.

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

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

A>>и как Вы хотите делать такие проверки с помощью макросов в С++ ?

K>http://www.rsdn.ru/forum/src/1824757.flat

Автор: CrystaX
Дата: 06.04.06

и где там макросы? Вы видимо имели ввиду "шаблоны" %)

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

__>Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>>Ну в данном случае читабельность от сокращения ничуть не пострадала — все предельно ясно.
SVZ>>Есть разумное соглашение: длина имени переменной определяется ее областью видимости. Чем больше область видимости, тем длиннее и подробнее имя.
__>меня продолжает убивать такой подход к именованию. любая команда, где разработка ведется хотя бы несколько лет быстро начинает заполонять проект акронимами. для любого новичка это все сплошной дремучий лес, это примерно как церковнославянский — вроде бы что-то похожее где-то видел и догадаться можно, но читать невозможно и часто неправильно все понимаешь.

общеизвестные сокращения — это нормально (idx, fn, str).
но вот ix я сначала прочитал как "integer x"

Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Да это полбеды, привыкаешь быстро. Тем более, когда именование более менее стандартизовано и имена выбираются так, как написал Роман чуть выше.
по мне это признак того, что "вы слишком долго тут работаете".
сокращения делают код менее поддерживаемым. новичкам сложно в нем разбираться. вот так вот просто на ровном месте создается проблема.

SVZ>А вот понять без комментариев, что делает код в целом — вот за это точно убивать надо. На месте. Из рогатки.
комментарий это признак невыразительности кода. это признак провала программиста выразить свои мысли кодом.
если мне не верите, то советую осилить "чистый код" — открыл ее для себя пару месяцев назад. это наиболее близкая книжка к моему собственному мнению, выработанному опытом

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

__>Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>>Да это полбеды, привыкаешь быстро. Тем более, когда именование более менее стандартизовано и имена выбираются так, как написал Роман чуть выше.
__>по мне это признак того, что "вы слишком долго тут работаете".
__>сокращения делают код менее поддерживаемым. новичкам сложно в нем разбираться. вот так вот просто на ровном месте создается проблема.


Я тоже бывал новичком (и не один раз ), видел самые разные соглашения. Может поэтому меня это не пугает

SVZ>>А вот понять без комментариев, что делает код в целом — вот за это точно убивать надо. На месте. Из рогатки.
__>комментарий это признак невыразительности кода. это признак провала программиста выразить свои мысли кодом.
__>если мне не верите, то советую осилить "чистый код" — открыл ее для себя пару месяцев назад. это наиболее близкая книжка к моему собственному мнению, выработанному опытом

Спасибо, посмотрю. В качестве алаверды рекомендую А.Голуба "Веревка достаточной длины..."
Мы, видимо, говорим о разном коде и о разном подходе к комментированию.

Вот такие комментарии, согласен, бесполезны:

GetWindowRect(bla-bla-bla); // Получить прямоугольник окна

Если же пишется более-менее сложный алгоритм, то "самодокументируемый код" — миф. Не все можно вынести в отдельные функции и не всегда можно дать функции короткое осмысленное имя.
При этом комментарии должны отвечать на вопрос "Зачем". Зачем выполняется данная операция, почему именно так, а не иначе.

Да, комментарии пишутся раньше кода.

17.09.2013 11:47, Stanislav V. Zudin пишет:

> Если же пишется более-менее сложный алгоритм, то "самодокументируемый
> код" — миф. Не все можно вынести в отдельные функции и не всегда можно
> дать функции короткое осмысленное имя.
Чаще это по причине неопытности клиента. Именно сложные алгоритмы легче
писать в самодокументированном варианте и разбивать на части.

Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Если же пишется более-менее сложный алгоритм, то "самодокументируемый код" — миф. Не все можно вынести в отдельные функции и не всегда можно дать функции короткое осмысленное имя.
я разбирался в сложных алгоритмах откомментированных. могу сказать что обычно проще выкинуть и написать заново.
даже сложный алгоритм должен быть разбит на короткие ф-ии с читаемыми именами, это единственный вариант когда его можно понять и протестировать. комменты очень мало помогают

SVZ>При этом комментарии должны отвечать на вопрос "Зачем". Зачем выполняется данная операция, почему именно так, а не иначе.
SVZ>Да, комментарии пишутся раньше кода.
существуют варианты, когда комменты уместны. но это не те случаи, когда ты смотришь на код и думаешь "зачем?".
вот недавно помню смотрю — очень бредовый кусок кода — часть логики вынесена в UI и там какая-то страшная проверка и написано — bug 552344 fix. нет, понятно, что мозно заглянуть в баг, разобраться зачем вообще это гавно понаписано. но код от этого понятнее не становится

17.09.2013 18:15, __kot2 пишет:

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

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

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

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

M>У меня тоже монитор широкий, но в vim у меня одновременно открыто шесть окон тайлами, вот ширина одного окна и получается 80

да, поэтому я, получив просьбу убрать длинные строки, убрал и не возмущался

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


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

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