Оформление кода
От: ESS  
Дата: 29.09.06 18:21
Оценка:
Добрый день.

Хочу узнать ваше мнение о применении Венгерской Нотации в 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" — имя переменной)
Re: Оформление кода
От: GarryIV  
Дата: 29.09.06 18:40
Оценка: 1 (1) +3
Здравствуйте, ESS, Вы писали:

ESS>Хочу узнать ваше мнение о применении Венгерской Нотации в JAVA-коде.


Сразу скажу — отрицательное.

ESS>Венгерская нотация обязывает в именах переменных хранить информацию о их типе, например:


[skipped ну типа я курсе ]

ESS>Это должно очень сильно увеличить читабельность кода.


Не согласен. Только уменьшает. В современных IDE (IDEA for example) нет никаких проблем с определением типа и области видимости переменных. Там можно и цветом выделять и навигация в один клик к определению и много всего другого. В сочетании с разумной организацией кода проблем с идентификацией типа и назначения переменной нет никаких. А применение всяческих префиксов типа lpcz_i существенно ухудшает читаемость кода и кроме того парит мозг программисту у которого и без того забот хватает.

ESS>Правда, когда все эти правила суммируются, имена переменных получаются очень длинные, типа:

ESS>"method(int[] aiParValue)" ("a" — потому что массив, "i" — потому что int "Par" — потому что параметр, "Value" — имя переменной)

Вот именно. Пусть этими вопросами лучше озабачивается IDE. Мемберы фиолетовые, параметры белые и локальные переменные белые и т.д. и т.п.

Посмотри хотя бы на исходники страндартных библотек Java. Все понятно и никакой венгерщтны.
WBR, Igor Evgrafov
Re: Оформление кода
От: LeonidV Ниоткуда http://vygovskiy.com
Дата: 29.09.06 20:24
Оценка:
Автору темы срочно поднимать все современные соглашения по оформлению кода. Единственная проблема, которая возникает — это путание локальных переменных и полей класса. Но в IDE ее просто нет, по причине описанной выше.

А лучше всего на ваш вопрос ответили ребята из Borland в их стандарте на форматирование кода Delphi.

Мы живем не в Венгрии, а в Америке, поэтому венгерская нотация не для нас.

(очень волная цитата)
http://jvmmemory.com — простой способ настройки JVM
Re[2]: Оформление кода
От: ESS  
Дата: 30.09.06 08:41
Оценка:
Здравствуйте, GarryIV, Вы писали:

GIV>Вот именно. Пусть этими вопросами лучше озабачивается IDE. Мемберы фиолетовые, параметры белые и локальные переменные белые и т.д. и т.п.


Это привязка к конкретной IDE. Мы, к сожалению, пользуемся не Intellij Idea, а JDeveloper, где мемберы не подсвечиваются.

В С++ обычно используют венгерку, синтаксис java похожий.
Re: Оформление кода
От: Petrovich_Alex  
Дата: 30.09.06 10:42
Оценка:
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
... << RSDN@Home 1.1.4 stable rev. 510>>
Re: Оформление кода
От: ADG Россия  
Дата: 30.09.06 12:13
Оценка:
Здравствуйте, ESS, Вы писали:

ESS>Хочу узнать ваше мнение о применении Венгерской Нотации в JAVA-коде.

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

Вот что нарыл в рамках QA работ.
Java Programming Style Guidelines. Geotechnical Software Services
Writing Robust Java Code The AmbySoft Inc. Coding Standards for Java
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: Оформление кода
От: C0s Россия  
Дата: 30.09.06 16:12
Оценка:
Здравствуйте, ESS, Вы писали:

ESS>Это привязка к конкретной IDE. Мы, к сожалению, пользуемся не Intellij Idea, а JDeveloper, где мемберы не подсвечиваются.


я пишу в FAR, причем давно без Colorer. но я тоже против венгерской нотации
Re: Оформление кода
От: Igor.K США  
Дата: 01.10.06 02:27
Оценка:
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>>
"СССР — четыре слова и все лживые" — Вагрич Бахчанян
Re[4]: Оформление кода
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 02.10.06 06:20
Оценка:
C0s,

C0s>я пишу в FAR, причем давно без Colorer. но я тоже против венгерской нотации


Я тоже в FAR, но как же без колорера-то? И насколько давно уже так работаешь?
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[3]: Оформление кода
От: LDimas Россия  
Дата: 02.10.06 07:12
Оценка:
ESS>В С++ обычно используют венгерку, синтаксис java похожий.

Я тоже раньше писал на С++ и использовал венгерку. Это скорее влиение традиции, чем реальная необходимость. В яве тоже есть свои традиции по оформлению кода, думаю их и стоит соблюдать.
Re[5]: Оформление кода
От: C0s Россия  
Дата: 02.10.06 07:51
Оценка: 1 (1) +1
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR> Я тоже в FAR, но как же без колорера-то? И насколько давно уже так работаешь?


да уж и не помню, на "чисто" фар перешел 3 с половиной года назад, как только освоился с ant'ом. сначала пробовал с колорером, но напрягали тормоза и какие-то глюки. соотв. пронес колорер, с тех пор уже года три как без него.
Re[6]: offtop
От: bolshik Россия http://denis-zhdanov.blogspot.com/
Дата: 02.10.06 07:54
Оценка:
Здравствуйте, C0s, Вы писали:

C0s>да уж и не помню, на "чисто" фар перешел 3 с половиной года назад, как только освоился с ant'ом. сначала пробовал с колорером, но напрягали тормоза и какие-то глюки. соотв. пронес колорер, с тех пор уже года три как без него.


А почему фар, почему не ide?
http://denis-zhdanov.blogspot.com
Re[7]: offtop
От: C0s Россия  
Дата: 02.10.06 08:02
Оценка: 30 (1) +1
Здравствуйте, bolshik, Вы писали:

B>А почему фар, почему не ide?


рационального объяснения нет

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

ps. ide, на которых я начинал — типа turbo c, turbo pascal, по функциональности были слабее фара. и ничего, на них писались вполне сносные программы.
pps. про интегрированный отладчик прошу флейм не затевать — аналогичный вроде есть в философии. мое имнсхо, хорошему программисту интегрированный отладчик не нужен, поэтому его наличие в ide преимуществом оных не считаю
Re[6]: Оформление кода
От: C0s Россия  
Дата: 02.10.06 08:04
Оценка:
Здравствуйте, C0s, Вы писали:

C0s>да уж и не помню, на "чисто" фар перешел 3 с половиной года назад


обманул, на фар в первый раз я перешел еще до java — шесть с лишним лет назад, когда на pl/sql много писал. потом, когда начинал с java, несколько месяцев попробовал с ide, потом забил и вернулся к проверенным средствам
Re[2]: Оформление кода
От: Blazkowicz Россия  
Дата: 02.10.06 08:12
Оценка:
Здравствуйте, LeonidV, Вы писали:

LV>Единственная проблема, которая возникает — это путание локальных переменных и полей класса.


Это не проблема. Все аннотации настаивают на приставке this. для полей. Поэтому и путаницы возникать не должно.
Re[8]: offtop
От: bolshik Россия http://denis-zhdanov.blogspot.com/
Дата: 02.10.06 08:12
Оценка: +1
Здравствуйте, C0s, Вы писали:


C0s>рационального объяснения нет





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


пишется, не спорю, но в ide можно (навскидку):
*) удобно делать рефакторинг;
*) быстрее писать код(автодополнение, добавление импортов);
*) смотреть иерархию вызовов методов;
*) в удобном виде получать информацию обо всех наследниках/имплементаторах, обо всех переопределяющих методах;
*) автоматические подсказки в случае ошибок из-за невнимательности;
...


C0s>ps. ide, на которых я начинал — типа turbo c, turbo pascal, по функциональности были слабее фара. и ничего, на них писались вполне сносные программы.

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

ок
http://denis-zhdanov.blogspot.com
Re[3]: Оформление кода
От: Blazkowicz Россия  
Дата: 02.10.06 08:13
Оценка: :)
Здравствуйте, Blazkowicz, Вы писали:

B>Это не проблема. Все аннотации настаивают на приставке this. для полей. Поэтому и путаницы возникать не должно.


Блин, не проснулся ещё. Какие нафинг "аннотации"? Конечно же "соглашения о кодировании".
Re[6]: Оформление кода
От: kan Великобритания  
Дата: 02.10.06 08:42
Оценка:
C0s wrote:

> LCR> Я тоже в FAR, но как же без колорера-то? И насколько давно уже так

> работаешь?
> да уж и не помню, на "чисто" фар перешел 3 с половиной года назад, как
> только освоился с ant'ом. сначала пробовал с колорером, но напрягали
> тормоза и какие-то глюки. соотв. пронес колорер, с тех пор уже года три
> как без него.
Колорер обновлялся за эти три года, последняя версия вполне сносная, тормозит только если в файле очень длинная строка
(несколько тысяч символов), но 1.5 меговый xml, разумно побитый на строки, вполне сносно в нём редактировать.

А насчёт интегрированного отладчика — я не могу им не пользоваться если надо разобраться в чужом коде, особенно, если
это какая-то левая библиотека.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re: Оформление кода
От: Denis Tsyplakov Россия  
Дата: 02.10.06 09:03
Оценка: +2
Здравствуйте, ESS, Вы писали:

ESS>Добрый день.


ESS>Хочу узнать ваше мнение о применении Венгерской Нотации в JAVA-коде.


Мои 5 копеек. Отрицательно. Сильно снижает читабельность кода. При этом Ява имеет более строгую типизацию, чем Си и соответственно вопрос "какого типа эта переменная" лично у меня возникает очень редко. А случаи когда возникшая путаница скомпилируется и приведет к неправильной работе программы — вообще можно посчитать по пальцам.
Re[4]: Оформление кода
От: Аноним  
Дата: 02.10.06 09:03
Оценка: 1 (1) +1
Здравствуйте, C0s, Вы писали:

C0s>я пишу в FAR, причем давно без Colorer. но я тоже против венгерской нотации


Не обижайтесь, но я думал что диназавры вымерли ))))
Возможно в FARe лучше чем Turbo C++, но сейчас 2006 год.
)) млин, пойду пацанам расскажу что еще есть программеры которые на java в FARe прогают.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.