1. Большинстсво мнений по поводу ненужности венгрки, в т.ч. и в этой ветке, сводятся к тому, что IDEшка и так все сама показывает, расскрашивает и красиво подмигивает. Привязываться к контретной IDE, да и вообще к IDE, не есть гуд. Придется сменить IDE — и все, нужно привыкать к новым условиям.Я не призываю конечно писать в текстовом редакторе, поскольку одно дело когда код пишет один человек (тогда ом может ворорить хоть черта лысого, лишь бы сам разбирался), и совсем другое — когда работает команда разработчиков, с возможностью прихода новых сотрудников, которым еще надо вкурить в то, что их коллеги наваяли.
2. Код программы должен (имхо) быть читаем и на мониторе, и на бумаге в распечатке. Поэтому доводы "а зачем это, если у меня на мониторе он и так фиолетовый" неубедительны.
3. Код должен быть максимально понятен и прозрачен. Одиночка писать может как угодно и будет полностью прав — это его код, если ему не нужно шарить его с другими разработчиками, то флаг ему в руки. Когда пишет несколько человек, то использование метаданных о переменных нужно для того, чтобы упростить процесс вникания других разработчиков в новый код.
Здравствуйте, TheBIG, Вы писали:
TBI>1. Большинстсво мнений по поводу ненужности венгрки, в т.ч. и в этой ветке, сводятся к тому, что IDEшка и так все сама показывает, расскрашивает и красиво подмигивает. Привязываться к контретной IDE, да и вообще к IDE, не есть гуд. Придется сменить IDE — и все, нужно привыкать к новым условиям.
Java код без венгерской нотации, без IDE и даже без подсветки в FAR нормально читается.
TBI>2. Код программы должен (имхо) быть читаем и на мониторе, и на бумаге в распечатке. Поэтому доводы "а зачем это, если у меня на мониторе он и так фиолетовый" неубедительны.
И даже на бумаге в книжках без венгерской нотации жить можно.
TBI>3. Код должен быть максимально понятен и прозрачен. Одиночка писать может как угодно и будет полностью прав — это его код, если ему не нужно шарить его с другими разработчиками, то флаг ему в руки. Когда пишет несколько человек, то использование метаданных о переменных нужно для того, чтобы упростить процесс вникания других разработчиков в новый код.
Код может быть прозрачным и нет в независимости от венгерской нотации. Зато есть устоявшийся Java coding convension, который используется в подавляющем большинстве opesource и не только проектов (JDK, Jakarta, Eclipse, Spring, Hibernate). И никто из них венгерскую нотацию не использует. (Может есть проекты на Jakarta о которых я не знаю). Так вот читаемость с венгерской нотацией именно потому и падает. Что она почти не используется в Java проектах.
Здравствуйте, TheBIG, Вы писали:
TBI>одно дело когда код пишет один человек (тогда ом может ворорить хоть черта лысого, лишь бы сам разбирался), и совсем другое — когда работает команда разработчиков, с возможностью прихода новых сотрудников, которым еще надо вкурить в то, что их коллеги наваяли. TBI>Когда пишет несколько человек, то использование метаданных о переменных нужно для того, чтобы упростить процесс вникания других разработчиков в новый код.
если бы я был новым человеком на вашем проекте, то .... я бы им, скорее всего, не был — как только мне бы во время предварительных разговоров сказали, что используется венгерка для упрощения процесса вникания, я бы семь раз подумал, надо ли мне такое чудо
TBI>2. Код программы должен (имхо) быть читаем и на мониторе, и на бумаге в распечатке. Поэтому доводы "а зачем это, если у меня на мониторе он и так фиолетовый" неубедительны.
Вот что о венгерской нотации думает Joel Spolsky: Making Wrong Code Look Wrong (здесь на русском). По моему, в этой интерпритации она достаточно интрересна.
Мне же, например, нравится выделять члены классов префиксом "_", ещё лучше если сразу видно, это статический член или нет за счёт использования разных префиксов. Это удобнее чем обращение через "this.", т.к. использование this это простое соглашение, которого можно не везде придерживаться, никто за это по рукам не надаёт, а если используешь префикс, то его придётся писать всегда (если конечно один раз объявил член класса с этим префиксом).
Ощущение, что приверженцы венгерской нотации пишут в стиле процедурного программирования, объявляя в рамках одного класса несколько сотен переменных и констант, а раз их так много, значит и кода предостаточно — почему и боятся в них запутаться.
Не припомню, чтобы даже в самом тяжелом классе, который бы писал, количество полей класса и локальных переменных достигало бы такого критического количества, при котором можно было бы забывать их назначение. Хотя, нет, вру — было... когда был совсем зеленым программистом, постоянно скатывающимся в процедурное программирование. Как только такое обнаруживал, начинал разбивать класс на логические составляющие. Сейчас, слава богу, кажется, сразу пишу так, что такого и не бывает.
По поводу текстовых редаторов... Очень сомневаюсь, что крупный проект можно написать на таком уровне. Основное в IDE отнудь не подсветка синтаксиса, как мне кажется, а рефакторинг, а также поддержка командной разработки проекта.
Здравствуйте, C0s, Вы писали:
C0s>читаешь распечатку на ночь? много думаешь?
Если уж так ставится вопрос, чем UML не устраивает — не понимаю. Нет, все-таки о каком-то процедурном коде идет речь.
Здравствуйте, C0s, Вы писали:
C0s>если бы я был новым человеком на вашем проекте, то .... я бы им, скорее всего, не был — как только мне бы во время предварительных разговоров сказали, что используется венгерка для упрощения процесса вникания, я бы семь раз подумал, надо ли мне такое чудо придирка к словам, не по существу.
C0s>читаешь распечатку на ночь? много думаешь?
юморист?
R>Если уж так ставится вопрос, чем UML не устраивает — не понимаю. Нет, все-таки о каком-то процедурном коде идет речь.
UML это хорошо, но у нас в конторе специфика такова, что большинство людей, приходящих на работу, студенты 2-3 курсов. В CASE тулзах
они ни в зуб ногой, так что показывать им схемы и на них объяснять не вариант, т.к. ко всему этому код пишут такие же студенты,
как и они, и так же ничего в CASE не понимают и все что умеют — это кодить.
Здравствуйте, TheBIG, Вы писали:
TBI>я за венгерку, почему:
TBI>1. Большинстсво мнений по поводу ненужности венгрки, в т.ч. и в этой ветке, сводятся к тому, что IDEшка и так все сама показывает, расскрашивает и красиво подмигивает. Привязываться к контретной IDE, да и вообще к IDE, не есть гуд. Придется сменить IDE — и все, нужно привыкать к новым условиям.Я не призываю конечно писать в текстовом редакторе, поскольку одно дело когда код пишет один человек (тогда ом может ворорить хоть черта лысого, лишь бы сам разбирался), и совсем другое — когда работает команда разработчиков, с возможностью прихода новых сотрудников, которым еще надо вкурить в то, что их коллеги наваяли.
Хуже IDE не станут, так что не надо нас будущим пугать, вон IDEA 6.0 вышла, еще пачка приятных изменений. И смена IDE тоже не проблема, я год назад сменил VS на IDEA ну пару недель конечно было трудновато а потом выучил новые трюки и все пошло.
TBI>2. Код программы должен (имхо) быть читаем и на мониторе, и на бумаге в распечатке. Поэтому доводы "а зачем это, если у меня на мониторе он и так фиолетовый" неубедительны.
Никогда не читал код в распечатке. Какой в этом смысл? Это же банально неудобно. Как мне в распечатке найти все места вызова функции? И вокруг тоже никого не знаю с такими привычками... Сейчас же не 70 годы у каждого по компу слава богу а у некоторых и несколько.
TBI>3. Код должен быть максимально понятен и прозрачен.
Согласен Однако на мой взгяд венгерская нотация этому только мешает.
TBI>Одиночка писать может как угодно и будет полностью прав — это его код, если ему не нужно шарить его с другими разработчиками, то флаг ему в руки. Когда пишет несколько человек, то использование метаданных о переменных нужно для того, чтобы упростить процесс вникания других разработчиков в новый код.
Нормально вникают сотрудники. И я тоже приходил в прошлый проект, если что и вызывало вопросы то это никак не было связано с проблемами которые пытатся решить с помощью венгерской нотации. А вот периодически встречащиеся мне тесксты с нотацией даются с трудом. Примерно как на незнакомом мне языке. А если учесть, что и все сторонние исходники тоже без нотации то это смешение стилей только усугубит ситуацию.
Да и не так важно новые сотрудники или старые. Когда проект большой постоянно встречатся куски кода который либо вообще первый раз видишь либо видел когда-то (а то и сам писал) но уже все забыл давно.
GIV>Хуже IDE не станут, так что не надо нас будущим пугать,
Я? Пугаю? ЭТИМ? Бросьте вы
GIV>Никогда не читал код в распечатке. Какой в этом смысл? Это же банально неудобно. Как мне в распечатке найти все места вызова функции? И вокруг тоже никого не знаю с такими привычками... Сейчас же не 70 годы у каждого по компу слава богу а у некоторых и несколько.
Согласен что пример с распечаткой возможно не самый удачный, я хочу сказать что привыкать к раскраске кода и к фенькам IDEшки мо поему не гуд.
TBI>>3. Код должен быть максимально понятен и прозрачен. GIV>Согласен Однако на мой взгяд венгерская нотация этому только мешает.
GIV>Да и не так важно новые сотрудники или старые. Когда проект большой постоянно встречатся куски кода который либо вообще первый раз видишь либо видел когда-то (а то и сам писал) но уже все забыл давно.
Я про то, что у сотрудников разная квалификация, конкретно в моей контроре — обычно приходят студенты, к-ые яву видели 1 раз и твердо уверены что она только для того, чтобы апплеты рисовать. И если позволить им писать каждому по своему, будет свалка кода, которую проще будет переписать, чем перебрать и понять, что и где там не работает. Потому что когда начинают переменные от балды называть qqq, www и прочее — это уже не дело.
Соглашусь, что в квалифицированной команде, где таких детских болезней нет, венгерка возможно и излишня, но когда постоянно приходится держать в голове что, что тебе могут очередного студента подкинуть и придется опять нянчиться с ним — надо же его как-то под общую гребенку причесать.
Здравствуйте, TheBIG, Вы писали:
TBI>Согласен что пример с распечаткой возможно не самый удачный, я хочу сказать что привыкать к раскраске кода и к фенькам IDEшки мо поему не гуд. TBI>И если позволить им писать каждому по своему, будет свалка кода, которую проще будет переписать, чем перебрать и понять, что и где там не работает. Потому что когда начинают переменные от балды называть qqq, www и прочее — это уже не дело. TBI>когда постоянно приходится держать в голове что, что тебе могут очередного студента подкинуть и придется опять нянчиться с ним — надо же его как-то под общую гребенку причесать.
странное дело я вот согласен с написанным, но не считаю, что венгерка тут как-то помогает.
общие правила именования, обязательные для всех — безусловно нужны, и ведущий должен котролировать исполнение оных ведомым. но венгерка тут ни при чем...
ps. впрочем, на давноидущем проекте, в котором она используется, равно как и на следующих, которые будут выполняться ровно тем же коллективом людей, конечно, уже уйти никуда не удастся, да и не нужно это...
Я считаю что читаемость венгеской нотации — это дело привычки.
Мне постоянно приходится переключаться между проектами на C++ и Java и для меня более понятна венг.нотация.
GIV>>Никогда не читал код в распечатке. Какой в этом смысл?
Редко, но бывает что печатаю. После долго сидения за монитором глазки устают, глядишь, выйдешь куда нибудь на воздух с распечаткой, мысли свежие прийдут.
TBI>Согласен что пример с распечаткой возможно не самый удачный, я хочу сказать что привыкать к раскраске кода и к фенькам IDEшки мо поему не гуд.
Ну, по-моему, дело не в том что "привыкать к раскраске не гуд", а в том что нотация несет дополнительную информативность (в дополнение к раскраске), которая, если конечно привыкнуть, ускоряет понимание кода (особенно чужого).
TBI>>>3. Код должен быть максимально понятен и прозрачен. GIV>>Согласен Однако на мой взгяд венгерская нотация этому только мешает.
Дело привычки.
TBI>Соглашусь, что в квалифицированной команде, где таких детских болезней нет, венгерка возможно и излишня, но когда постоянно приходится держать в голове что, что тебе могут очередного студента подкинуть и придется опять нянчиться с ним — надо же его как-то под общую гребенку причесать.
С т.з. навести порядок в бардаке — однозначно согласен.
С приходом новых модных IDE и новых соглашений по коду значимость венгерки уменьшилась, но для тех кто уже привык — не мешает, наоборот помогает. Да и m_ короче чем this.
Мне видится, главное — чтобы в команде была договоренность и использовался один стиль кодирования, а уже какой — дело вкуса.
Здравствуйте, GarryIV, Вы писали:
GIV>Хуже IDE не станут, так что не надо нас будущим пугать, вон IDEA 6.0 вышла, еще пачка приятных изменений. И смена IDE тоже не проблема, я год назад сменил VS на IDEA ну пару недель конечно было трудновато а потом выучил новые трюки и все пошло.
Я ежедневно сталкиваюсь с кодом без подсветки (встроенное сравнение файлов в ClearCase), при этом часто это не известные тебе классы, и часто возникает вопрос, а что это за переменная — член класса или описана где-то рядом, если член класса, то статический или нет.
Когда недавно читал статью Джоела, меня не покидало чуство дежа-вю, что где-то я уже это видел. Вчера, когда писал предыдущее сообщение вспомнил, в одной хорошей книге Стива МакКоннелла "Совершенней код"
. Дома проверил, так и есть — глава 11.5, в ней пишется о пользе подобных префиксов и суфиксов, причём примеры связаны с текстовым редактором. Там же рядом пишется о том, что полезно конвенциями именования разделять члены классов, названия типов, имена локальных переменных и т.п.
GIV>>Да и не так важно новые сотрудники или старые. Когда проект большой постоянно встречатся куски кода который либо вообще первый раз видишь либо видел когда-то (а то и сам писал) но уже все забыл давно.
TBI>Я про то, что у сотрудников разная квалификация, конкретно в моей контроре — обычно приходят студенты, к-ые яву видели 1 раз и твердо уверены что она только для того, чтобы апплеты рисовать. И если позволить им писать каждому по своему, будет свалка кода, которую проще будет переписать, чем перебрать и понять, что и где там не работает. Потому что когда начинают переменные от балды называть qqq, www и прочее — это уже не дело.
А m_qqq и sp_www лучше? На тему оформления кода у нас есь документ в котором написано как что именовать.
TBI>Соглашусь, что в квалифицированной команде, где таких детских болезней нет, венгерка возможно и излишня, но когда постоянно приходится держать в голове что, что тебе могут очередного студента подкинуть и придется опять нянчиться с ним — надо же его как-то под общую гребенку причесать.
Конечно надо. Сейчас как раз сижу пишу для таких случаев кучу документов, как что устроено и какой функционал как еализовывать. Проблема то не только и не столько в наименовании переменных, это только малая ее и лгко решаемая ее часть.
Здравствуйте, TheBIG, Вы писали:
TBI>я за венгерку, почему:
В серьезных конторах всегда есть документ, который должен прочитать каждый новый пришедший человек, и документ этот — CodeConvension.
Хочешь ты или не хочешь, любишь или не любишь, но используешь ту форму написания кода, которую тебе дали. Причем это касается не только глобальных вопросов об использовании венгерской нотации, но и о количестве пробелов и переносов строк в каждом типе выражений.
И распостраняется такая система настроек вплоть до дублирования IDE.
С другой стороны документ этот принимался не с потолка, а учитывал общие тенденции и для лучшей читабельности кода.
<Аноним>,
C0s>>я пишу в FAR, причем давно без Colorer. но я тоже против венгерской нотации
А>Не обижайтесь, но я думал что диназавры вымерли )))) А>Возможно в FARe лучше чем Turbo C++, но сейчас 2006 год. А>)) млин, пойду пацанам расскажу что еще есть программеры которые на java в FARe прогают.
Помнишь фразы Вирта?
"... Нет другого, более сильного стимула для аккуратного программирования, чем отсутствие отладчика."
"...отладчики лечат только следствие, а не саму болезнь."
Если тебе эти фразы кажутся бредом, это нормально. Попробуй вернуться через год и прочитать их снова. Удачи
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, C0s, Вы писали:
C0s>>я пишу в FAR, причем давно без Colorer. но я тоже против венгерской нотации
А>Не обижайтесь, но я думал что диназавры вымерли )))) А>Возможно в FARe лучше чем Turbo C++, но сейчас 2006 год. А>)) млин, пойду пацанам расскажу что еще есть программеры которые на java в FARe прогают.
Здравствуйте, Igor.K, Вы писали:
IK>Спорим, что я быстрее наберу this.account быстрее чем Вы m_Account.
Вообще то это оффтоп, но после m_ помошник мне выкинет тот же список что и Вам после this.
Однако на мой взгяд венгерская нотация этому только мешает.
я вот согласен с написанным, но не считаю, что венгерка тут как-то помогает.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Пищальников Юрий