Здравствуйте, Снорк, Вы писали:


С> Главное, что они — законодатели мод.

Это уже вопрос не по форуму: Орлом летать или Ужом ползать?

С>Впрочем, они сами отказываются ныне от венгерской нотации. Как тут уже заметили, в GDI+, например.
Здравая идея! Самих небось заколебало код корявый писать....

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

S>З.Ы. Для справки: теорема Стеклова из квантовой механики формулируется так: "Коммутатор операторов спиртных напитков с различной крепостью отличен от нуля". Из этого, в частности, следует принципиальная неизмеримость одновременно каждого из воздействий, например, пива и водки.



Это в юмор надо.

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

M>>>Дак и не зачем такие большие функции плодить.
M>>>Функция должна занимать 5-10 строчек. Так ещё можно контролировать код. А при 30 строчках, ты не в переменных, так в алгоритме ошибёшся. Преффиксы, в данном случае, просто загоняют проблему в даль.....

W>>Сомнительно...
W>>Если заниматься постоянно функциональной декомпозицией методов, то когда же проект сдавать?
W>>Или понятие сроков в природе остсутствует?

M>А как вы считаете, какое соотношение времени на проектирование и на кодирование нормалное? 1:100 ?
M>Вы из тех кто рвётся в бой — покодируем-покодируем, потом ошибочки поищем? потом бросим и перекодируем?

Ну зачем так сразу и так резко?
Все мы читали Брукса, Гамму, Страуструпа и т.д.
Все мы имеем некий (пусть и очень небольшой -- в моем случае --) опыт.

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

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

M>Это уже вопрос не по форуму: Орлом летать или Ужом ползать?

А вот по форуму: писать понятный для абстрактного большинства программмистов код — это по вашему орлом летать или ужом ползать?

С>>Впрочем, они сами отказываются ныне от венгерской нотации. Как тут уже заметили, в GDI+, например.
M>Здравая идея! Самих небось заколебало код корявый писать....

Наверное, так и решили за кружкой чая: заколебало! Коряво как-то получается...

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

Ну нельзя, нельзя окинуть одним взглядом всю вселенную!
Ну не возможно отличать спутники Юпитера от Луны по префиксам!

W>Ну зачем так сразу и так резко?
W>Все мы читали Брукса, Гамму, Страуструпа и т.д.
W>Все мы имеем некий (пусть и очень небольшой -- в моем случае --) опыт.

Я уверен, ты и Буча читал! А у него есть цитатка на какого-то психолога: мол больше пяти-семи объектов одновременно человек не может брать во внимание: память его небезгранична.
И отсюда вытекает мораль: структура программного кода должна быть такой, что бы в поле зрения программиста на данном уровне рассмотрения было не более скольки-то важных элементов.

W>Просто я считаю (пока что!) неоправданным проектировать систему от нуля сразу до мельчайших мелочей (вроде типа переменной-счетчика в цикле второй степени вложенности во внутренней функции модулявизуализации отчета).

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

Слов нет, проектирование цикла (n+5)-той вложенности, наверное, (я сам не знаю) маразм.

Здравствуйте, Снорк, Вы писали:

С>А вот по форуму: писать понятный для абстрактного большинства программмистов код — это по вашему орлом летать или ужом ползать?

Смотря из каких соображений это делать: из-за того что "так делает Вася", или из-за того что "так делает Вася и я считаю что это правильно".

С>Наверное, так и решили за кружкой чая: заколебало! Коряво как-то получается...

Американцы чай редко пьют...
Видать не они это решили!

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

M>Я уверен, ты и Буча читал! А у него есть цитатка на какого-то психолога: мол больше пяти-семи объектов одновременно человек не может брать во внимание: память его небезгранична.
M>И отсюда вытекает мораль: структура программного кода должна быть такой, что бы в поле зрения программиста на данном уровне рассмотрения было не более скольки-то важных элементов.

Ага, о семи элементах я и хотел сказать.

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

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

M>Смотря из каких соображений это делать: из-за того что "так делает Вася", или из-за того что "так делает Вася и я считаю что это правильно".

Вася != Microsoft.

Здравствуйте, Снорк, Вы писали:

С>Вася != Microsoft.
Microsoft!=Идеал.

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

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

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

IT>Потратишь ровно одну секунду. Клац по файлу в фаре, и вот он у тебя уже в тудию загружен. Чего проще?

S>>... Студия у тебя не всегда под руками, а Блокнот, он на любой винде стоит.

IT>А зачем тебе код без студии?

Зачем, а хотя бы так, в 6-ой студии я реализовал свой хитрый тулбар, причём в проэкте 2-х летней давности, а тулбар был только в промежуточной версии проэкта, в какой не помню, самих архивов версий проэкта не меньше 30, даже приблизительно зная в какой версии этот тулбар находится, я значительно больше времени бы потратил времени на загрузку проэкта в студию, его конвертацию в формат 7-ой, а так фаром зашол в архив F4 и посмотрел файлик, один второй, вот и нашол.

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

S>SomeClass(int count)
S>{
S> m_count = count;
S>}

S> Как сделать без префиксов? Не называть же параметр countOfSomeClass

WF>А вот так (Java):
WF>

WF>SomeClass( int count )
WF>{
WF>    this.count = count;
WF>}
WF>

А еще лучше так:

SomeClass(int count)
{
this.count = param.count;
}

И запретить обращаться к нелокальным переменным без явного
указания области видимости.
Отсутствие конфликтов будет гарантировано языком.

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

P>Раз тут развернулось обсуждение префиксов, хотелось бы узнать, как сейчас прогрессивная общественность относится к сабжу и к префиксам вообще. Мне почему-то кажется, что в приходом всевозможных VAssist-ов реальная необходимость в этом постепенно отмирает. И держится это всё на программистах "старой школы". Но я совсем не уверен.

Ну, в общем, имхо, всё зависит от того, что ты пишешь.
У меня в библиотеке куча защищённых переменных типа theWindowsMap, theWindow и пр., венгерка используется только для декларирования публичных свойств...

На счёт VA — главное — понимание того, с чем ты работает — я тут пару дней посидел под соляркой с nc и ничего, не сказал бы, что знание типа переменно через префиксы сильно помагает... Главное, имхо — понимание того, что делает конкретная ф-ия/поле...

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

P>>Раз тут развернулось обсуждение префиксов, хотелось бы узнать, как сейчас прогрессивная общественность относится к сабжу и к префиксам
dmz>Венгерскую нотацию — давить. Почему — читать Голуба. Который Аллен.

А кто он такой? Что выдающегося сделал?

P>>Мне почему-то кажется, что в приходом всевозможных VAssist-ов
P>>реальная необходимость в этом постепенно отмирает. И держится это
dmz>Этой необходимости и не было никогда, при нормальном подходе к кодированию.

А 1-3 (не больше) символьные префиксы значительно увеличивают читабельность кода, это факт!

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

_D>У меня не раз VA ставил раком MSVC и винды.

MSVC и без всякого VA может сама раком встать и Windows так-же поставить

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

P>Раз тут развернулось обсуждение префиксов, хотелось бы узнать, как сейчас прогрессивная общественность относится к сабжу и к префиксам вообще. Мне почему-то кажется, что в приходом всевозможных VAssist-ов реальная необходимость в этом постепенно отмирает. И держится это всё на программистах "старой школы". Но я совсем не уверен.

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

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

m_ данные класса
s_ статические данные класса
g_ глобальные переменные

i_ input-параметр функции
o_ output-параметр функции
io_ in-out параметр функции.
без префикса — локальные переменные.

Еще нужен префикс p для указателей: например, m_pAggregationByPointer. Этот префикс не так важен, как предыдущие, но если к нему привык, то почему-то сильно напрягает его отсутствие. Просто бесит, я бы сказал. Поэтому мы его ставим всегда.

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

Некоторые используют префикс b для bool. Наличие или отсутствие этого префикса как показывает практика не принципиально, но мне, например, нравится когда он есть. Так красиво.

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

Аргументация против обычно такая:
класс должен быть компактен и понятен, чтобы программер знал наизусть какая переменная член класса, а какая нет. Функция должна быть короткая, чтобы было очевидно, что является входным параметром, а что нет. Глобальных переменных не должно быть

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

Например, я исправляю дефект, найденный клиентом. В отладчике я проваливаюсь (или возвращаюсь вверх по стеку) в очередную функцию. Я хочу видеть сразу, здесь и сейчас, не глядя в header, и не глядя на сигнатуру функции, какая переменная локальная, какая параметр, а какая член класса. При глубине стека 5-7 функций в малознакомом коде большого объема я уже этого не запоминаю (есть проблемы поважнее), и у меня просто нет времени постоянно лазить по header-ам за всякой ерундой.

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

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

G>i_ input-параметр функции
G>o_ output-параметр функции
G>io_ in-out параметр функции.

Ага, познакомился недавно с таким стилем именования. Впечатление — это чистое замусоревание имен переменных ни несущее почти никакой смысловой нагрузки.

P.S. Против других префиксов ничего сильно против не имею.

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

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

G>>i_ input-параметр функции
G>>o_ output-параметр функции
G>>io_ in-out параметр функции.

L>Ага, познакомился недавно с таким стилем именования. Впечатление — это чистое замусоревание имен переменных ни несущее почти никакой смысловой нагрузки.

Вот простейший пример — одна из ситуаций, когда это помогает. Допустим мы ловим багу в малознакомом (чужом, и/или хорошо забытом) коде.

void SomeClass::SetTimeRange( TimeRange i_exclusiveTimeRange )
{
// legacy code...

   TimeRange inclusiveTimeRange = i_exclusiveTimeRange;
   inclusiveTimeRange.SetEndTime( i_exclusiveTimeRange.GetEndTime() - oneMinute );

// legacy code...

   doSomething( inclusiveTimeRange );

// legacy code...

   doSomethingElse( i_exclusiveTimeRange );
}

Мы остановились в брекпойнте в функции doSomethingElse. Понимаем, что ошибка вызвана неправильным значением входного параметра. Выходим в отладчике из функции doSomethingElse обратно в функцию SetTimeRange. Первая строчка, на которой останавливается взгляд, это doSomethingElse( i_exclusiveTimeRange ). Глядя на префикс параметра понимаем, что нам не надо смотреть по коду, как вычисляется i_exclusiveTimeRange, т. к. это входной параметр. Спокойно идем выше по стеку.

В той же ситуации для функции doSomething мы сразу видим, что мы должны сделать поиск вверх по коду с целью разобраться, как формируется inclusiveTimeRange.

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

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

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

G>Мы остановились в брекпойнте в функции doSomethingElse. Понимаем, что ошибка вызвана неправильным значением входного параметра. Выходим в отладчике из функции doSomethingElse обратно в функцию SetTimeRange. Первая строчка, на которой останавливается взгляд, это doSomethingElse( i_exclusiveTimeRange ). Глядя на префикс параметра понимаем, что нам не надо смотреть по коду, как вычисляется i_exclusiveTimeRange, т. к. это входной параметр. Спокойно идем выше по стеку.

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

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

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

G>>Мы остановились в брекпойнте в функции doSomethingElse. Понимаем, что ошибка вызвана неправильным значением входного параметра. Выходим в отладчике из функции doSomethingElse обратно в функцию SetTimeRange. Первая строчка, на которой останавливается взгляд, это doSomethingElse( i_exclusiveTimeRange ). Глядя на префикс параметра понимаем, что нам не надо смотреть по коду, как вычисляется i_exclusiveTimeRange, т. к. это входной параметр. Спокойно идем выше по стеку.

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

Как у вас просто все.

Напоминаю, что "для того, чтобы поймать реальную багу, часто надо просмотреть сотни функций, написанных и подправленных разными людьми, двигаясь по стеку на глубину более 7 вызовов." Добавлю, что это занимает от 3 дней до 2 недель. Код размером мегов так 50. С кодом ты знаком слабо. "Пробовал-ли ты? А ты попробуй!"

И посмотрим, как тебе помогут "нормальные размеры". Кстати, а "нормальные" это сколько? 5, 10, 50, 100, 200? А ты уверен, что все программисты одинаково понимают понятие "нормальные размеры"? И ты сам не грешен, никогда не писал "ненормально" длинных функций? Да? Не верю. Потому что один и тот же программер в разных ситуациях придерживается разного мнения о том, что такое нормальные размеры.

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

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

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

G>Как у вас просто все.

Ну да, а зачем себе и другим жизнь усложнять?

G>Напоминаю, что "для того, чтобы поймать реальную багу, часто надо просмотреть сотни функций, написанных и подправленных разными людьми, двигаясь по стеку на глубину более 7 вызовов." Добавлю, что это занимает от 3 дней до 2 недель. Код размером мегов так 50. С
>кодом ты знаком слабо. "Пробовал-ли ты? А ты попробуй!"

Таких баг мне еще ни разу ни ловить, ни видеть не приходилось, впрочем как и видеть такие уровни вложенности. Максимум — уровня 4-5. И ловилось все отсилы за пару часов без каких-то диких трассировок стека. Гораздо большие проблемы обыно составляет исправление.
И размер под 50 мегов тут особой роли не играет — это же не один модуль.

G>И посмотрим, как тебе помогут "нормальные размеры". Кстати, а "нормальные" это сколько? 5, 10, 50, 100, 200? А ты уверен, что все

Да в общем-то нормально помогают. По крайней мере никогда не видел нужды в каких-либо префиксах (даже в стандартной венгерке).
Нормальные по моим меркам — строк до 30-40.

>программисты одинаково понимают понятие "нормальные размеры"? И ты сам не грешен, никогда не писал "ненормально" длинных функций? Да?

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

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

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

Как будто я этого не знаю.