Хочу узнать ваше мнение о применении Венгерской Нотации в JAVA-коде.
Венгерская нотация обязывает в именах переменных хранить информацию о их типе, например:
все переменные типа String должны начинаться с "s" ("sFileName"),
типа int c "i" ("iCount"),
члены класса с "m_" ("private String m_sFileName"),
параметры метода с "Par", ( "method(int iParCount)" )
массивы и коллекции типа List c "a" ("String[] asFileName")
все остальные объекты с "о" ("oDocument")
Это должно очень сильно увеличить читабельность кода.
Правда, когда все эти правила суммируются, имена переменных получаются очень длинные, типа:
"method(int[] aiParValue)" ("a" — потому что массив, "i" — потому что int "Par" — потому что параметр, "Value" — имя переменной)
Здравствуйте, ESS, Вы писали:
ESS>Хочу узнать ваше мнение о применении Венгерской Нотации в JAVA-коде.
Сразу скажу — отрицательное.
ESS>Венгерская нотация обязывает в именах переменных хранить информацию о их типе, например:
[skipped ну типа я курсе ]
ESS>Это должно очень сильно увеличить читабельность кода.
Не согласен. Только уменьшает. В современных IDE (IDEA for example) нет никаких проблем с определением типа и области видимости переменных. Там можно и цветом выделять и навигация в один клик к определению и много всего другого. В сочетании с разумной организацией кода проблем с идентификацией типа и назначения переменной нет никаких. А применение всяческих префиксов типа lpcz_i существенно ухудшает читаемость кода и кроме того парит мозг программисту у которого и без того забот хватает.
ESS>Правда, когда все эти правила суммируются, имена переменных получаются очень длинные, типа: ESS>"method(int[] aiParValue)" ("a" — потому что массив, "i" — потому что int "Par" — потому что параметр, "Value" — имя переменной)
Вот именно. Пусть этими вопросами лучше озабачивается IDE. Мемберы фиолетовые, параметры белые и локальные переменные белые и т.д. и т.п.
Посмотри хотя бы на исходники страндартных библотек Java. Все понятно и никакой венгерщтны.
Автору темы срочно поднимать все современные соглашения по оформлению кода. Единственная проблема, которая возникает — это путание локальных переменных и полей класса. Но в IDE ее просто нет, по причине описанной выше.
А лучше всего на ваш вопрос ответили ребята из Borland в их стандарте на форматирование кода Delphi.
Мы живем не в Венгрии, а в Америке, поэтому венгерская нотация не для нас.
Здравствуйте, GarryIV, Вы писали:
GIV>Вот именно. Пусть этими вопросами лучше озабачивается IDE. Мемберы фиолетовые, параметры белые и локальные переменные белые и т.д. и т.п.
Это привязка к конкретной IDE. Мы, к сожалению, пользуемся не Intellij Idea, а JDeveloper, где мемберы не подсвечиваются.
В С++ обычно используют венгерку, синтаксис java похожий.
Здравствуйте, ESS, Вы писали:
ESS>Хочу узнать ваше мнение о применении Венгерской Нотации в JAVA-коде.
IMHO эффективность применения Венгерской Нотации зависит от типа проекта.
К примеру если это Struts веб приложение где action обычно состовляет не больше размера видимой области экрана, то ВН излишня. А если это класс сложных математических расчетов или обработки строки, то, вероятно, она будет кстати.
Здравствуйте, ESS, Вы писали:
ESS>Это привязка к конкретной IDE. Мы, к сожалению, пользуемся не Intellij Idea, а JDeveloper, где мемберы не подсвечиваются.
я пишу в FAR, причем давно без Colorer. но я тоже против венгерской нотации
ESS>Хочу узнать ваше мнение о применении Венгерской Нотации в JAVA-коде.
ESS>Венгерская нотация обязывает в именах переменных хранить информацию о их типе, например: ESS>все переменные типа String должны начинаться с "s" ("sFileName"), ESS>типа int c "i" ("iCount"), ESS>члены класса с "m_" ("private String m_sFileName"), ESS>параметры метода с "Par", ( "method(int iParCount)" ) ESS>массивы и коллекции типа List c "a" ("String[] asFileName") ESS>все остальные объекты с "о" ("oDocument")
В java уже есть соглашение об оформлении кода, и, вполне, не плохое. К венгерской нотации, у меня лично, отношение резко отрицательное вообще, а не только в java коде. Само имя переменной если оно задано нормально, уже может многое сказать о типе, неявно, и дополнительные префиксы могут только мешать восприятию. Особенно интересн префикс "m_", для членов класса. Почему бы не использовать this вместо него. Набирается даже быстрее, и в "правильных" IDE сразу позволяет получить список членов и методов.
... << RSDN@Home 1.2.0 alpha rev. 653>>
"СССР — четыре слова и все лживые" — Вагрич Бахчанян
ESS>В С++ обычно используют венгерку, синтаксис java похожий.
Я тоже раньше писал на С++ и использовал венгерку. Это скорее влиение традиции, чем реальная необходимость. В яве тоже есть свои традиции по оформлению кода, думаю их и стоит соблюдать.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR> Я тоже в FAR, но как же без колорера-то? И насколько давно уже так работаешь?
да уж и не помню, на "чисто" фар перешел 3 с половиной года назад, как только освоился с ant'ом. сначала пробовал с колорером, но напрягали тормоза и какие-то глюки. соотв. пронес колорер, с тех пор уже года три как без него.
Здравствуйте, C0s, Вы писали:
C0s>да уж и не помню, на "чисто" фар перешел 3 с половиной года назад, как только освоился с ant'ом. сначала пробовал с колорером, но напрягали тормоза и какие-то глюки. соотв. пронес колорер, с тех пор уже года три как без него.
Здравствуйте, bolshik, Вы писали:
B>А почему фар, почему не ide?
рационального объяснения нет
иррациональное же в том, что хорошо подготовленная программа пишется работающей без помощи ide. имхо, помощь ide — сомнительный трюк, раздутый поставщиками этих ide.
ps. ide, на которых я начинал — типа turbo c, turbo pascal, по функциональности были слабее фара. и ничего, на них писались вполне сносные программы.
pps. про интегрированный отладчик прошу флейм не затевать — аналогичный вроде есть в философии. мое имнсхо, хорошему программисту интегрированный отладчик не нужен, поэтому его наличие в ide преимуществом оных не считаю
Здравствуйте, C0s, Вы писали:
C0s>да уж и не помню, на "чисто" фар перешел 3 с половиной года назад
обманул, на фар в первый раз я перешел еще до java — шесть с лишним лет назад, когда на pl/sql много писал. потом, когда начинал с java, несколько месяцев попробовал с ide, потом забил и вернулся к проверенным средствам
C0s>иррациональное же в том, что хорошо подготовленная программа пишется работающей без помощи ide. имхо, помощь ide — сомнительный трюк, раздутый поставщиками этих ide.
пишется, не спорю, но в ide можно (навскидку):
*) удобно делать рефакторинг;
*) быстрее писать код(автодополнение, добавление импортов);
*) смотреть иерархию вызовов методов;
*) в удобном виде получать информацию обо всех наследниках/имплементаторах, обо всех переопределяющих методах;
*) автоматические подсказки в случае ошибок из-за невнимательности;
...
C0s>ps. ide, на которых я начинал — типа turbo c, turbo pascal, по функциональности были слабее фара. и ничего, на них писались вполне сносные программы. C0s>pps. про интегрированный отладчик прошу флейм не затевать — аналогичный вроде есть в философии. мое имнсхо, хорошему программисту интегрированный отладчик не нужен, поэтому его наличие в ide преимуществом оных не считаю
C0s wrote:
> LCR> Я тоже в FAR, но как же без колорера-то? И насколько давно уже так > работаешь? > да уж и не помню, на "чисто" фар перешел 3 с половиной года назад, как > только освоился с ant'ом. сначала пробовал с колорером, но напрягали > тормоза и какие-то глюки. соотв. пронес колорер, с тех пор уже года три > как без него.
Колорер обновлялся за эти три года, последняя версия вполне сносная, тормозит только если в файле очень длинная строка
(несколько тысяч символов), но 1.5 меговый xml, разумно побитый на строки, вполне сносно в нём редактировать.
А насчёт интегрированного отладчика — я не могу им не пользоваться если надо разобраться в чужом коде, особенно, если
это какая-то левая библиотека.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ESS, Вы писали:
ESS>Добрый день.
ESS>Хочу узнать ваше мнение о применении Венгерской Нотации в JAVA-коде.
Мои 5 копеек. Отрицательно. Сильно снижает читабельность кода. При этом Ява имеет более строгую типизацию, чем Си и соответственно вопрос "какого типа эта переменная" лично у меня возникает очень редко. А случаи когда возникшая путаница скомпилируется и приведет к неправильной работе программы — вообще можно посчитать по пальцам.
Здравствуйте, C0s, Вы писали:
C0s>я пишу в FAR, причем давно без Colorer. но я тоже против венгерской нотации
Не обижайтесь, но я думал что диназавры вымерли ))))
Возможно в FARe лучше чем Turbo C++, но сейчас 2006 год.
)) млин, пойду пацанам расскажу что еще есть программеры которые на java в FARe прогают.