Здравствуйте, 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 символов