Вот что о венгерской нотации думает Joel Spolsky: Making Wrong Code Look Wrong (здесь на русском). По моему, в этой интерпритации она достаточно интрересна.
Мне же, например, нравится выделять члены классов префиксом "_", ещё лучше если сразу видно, это статический член или нет за счёт использования разных префиксов. Это удобнее чем обращение через "this.", т.к. использование this это простое соглашение, которого можно не везде придерживаться, никто за это по рукам не надаёт, а если используешь префикс, то его придётся писать всегда (если конечно один раз объявил член класса с этим префиксом).
Здравствуйте, ESS, Вы писали:
ESS>Хочу узнать ваше мнение о применении Венгерской Нотации в JAVA-коде.
Сразу скажу — отрицательное.
ESS>Венгерская нотация обязывает в именах переменных хранить информацию о их типе, например:
[skipped ну типа я курсе ]
ESS>Это должно очень сильно увеличить читабельность кода.
Не согласен. Только уменьшает. В современных IDE (IDEA for example) нет никаких проблем с определением типа и области видимости переменных. Там можно и цветом выделять и навигация в один клик к определению и много всего другого. В сочетании с разумной организацией кода проблем с идентификацией типа и назначения переменной нет никаких. А применение всяческих префиксов типа lpcz_i существенно ухудшает читаемость кода и кроме того парит мозг программисту у которого и без того забот хватает.
ESS>Правда, когда все эти правила суммируются, имена переменных получаются очень длинные, типа: ESS>"method(int[] aiParValue)" ("a" — потому что массив, "i" — потому что int "Par" — потому что параметр, "Value" — имя переменной)
Вот именно. Пусть этими вопросами лучше озабачивается IDE. Мемберы фиолетовые, параметры белые и локальные переменные белые и т.д. и т.п.
Посмотри хотя бы на исходники страндартных библотек Java. Все понятно и никакой венгерщтны.
<Аноним>,
C0s>>я пишу в FAR, причем давно без Colorer. но я тоже против венгерской нотации
А>Не обижайтесь, но я думал что диназавры вымерли )))) А>Возможно в FARe лучше чем Turbo C++, но сейчас 2006 год. А>)) млин, пойду пацанам расскажу что еще есть программеры которые на java в FARe прогают.
Помнишь фразы Вирта?
"... Нет другого, более сильного стимула для аккуратного программирования, чем отсутствие отладчика."
"...отладчики лечат только следствие, а не саму болезнь."
Если тебе эти фразы кажутся бредом, это нормально. Попробуй вернуться через год и прочитать их снова. Удачи
Здравствуйте, 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 проектах.
Здравствуйте, bolshik, Вы писали:
B>А почему фар, почему не ide?
рационального объяснения нет
иррациональное же в том, что хорошо подготовленная программа пишется работающей без помощи ide. имхо, помощь ide — сомнительный трюк, раздутый поставщиками этих ide.
ps. ide, на которых я начинал — типа turbo c, turbo pascal, по функциональности были слабее фара. и ничего, на них писались вполне сносные программы.
pps. про интегрированный отладчик прошу флейм не затевать — аналогичный вроде есть в философии. мое имнсхо, хорошему программисту интегрированный отладчик не нужен, поэтому его наличие в ide преимуществом оных не считаю
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR> Я тоже в FAR, но как же без колорера-то? И насколько давно уже так работаешь?
да уж и не помню, на "чисто" фар перешел 3 с половиной года назад, как только освоился с ant'ом. сначала пробовал с колорером, но напрягали тормоза и какие-то глюки. соотв. пронес колорер, с тех пор уже года три как без него.
Здравствуйте, C0s, Вы писали:
C0s>я пишу в FAR, причем давно без Colorer. но я тоже против венгерской нотации
Не обижайтесь, но я думал что диназавры вымерли ))))
Возможно в FARe лучше чем Turbo C++, но сейчас 2006 год.
)) млин, пойду пацанам расскажу что еще есть программеры которые на java в FARe прогают.
Здравствуйте, ESS, Вы писали:
ESS>Добрый день.
ESS>Хочу узнать ваше мнение о применении Венгерской Нотации в JAVA-коде.
Мои 5 копеек. Отрицательно. Сильно снижает читабельность кода. При этом Ява имеет более строгую типизацию, чем Си и соответственно вопрос "какого типа эта переменная" лично у меня возникает очень редко. А случаи когда возникшая путаница скомпилируется и приведет к неправильной работе программы — вообще можно посчитать по пальцам.
Здравствуйте, TheBIG, Вы писали:
TBI>одно дело когда код пишет один человек (тогда ом может ворорить хоть черта лысого, лишь бы сам разбирался), и совсем другое — когда работает команда разработчиков, с возможностью прихода новых сотрудников, которым еще надо вкурить в то, что их коллеги наваяли. TBI>Когда пишет несколько человек, то использование метаданных о переменных нужно для того, чтобы упростить процесс вникания других разработчиков в новый код.
если бы я был новым человеком на вашем проекте, то .... я бы им, скорее всего, не был — как только мне бы во время предварительных разговоров сказали, что используется венгерка для упрощения процесса вникания, я бы семь раз подумал, надо ли мне такое чудо
TBI>2. Код программы должен (имхо) быть читаем и на мониторе, и на бумаге в распечатке. Поэтому доводы "а зачем это, если у меня на мониторе он и так фиолетовый" неубедительны.
C0s>иррациональное же в том, что хорошо подготовленная программа пишется работающей без помощи ide. имхо, помощь ide — сомнительный трюк, раздутый поставщиками этих ide.
пишется, не спорю, но в ide можно (навскидку):
*) удобно делать рефакторинг;
*) быстрее писать код(автодополнение, добавление импортов);
*) смотреть иерархию вызовов методов;
*) в удобном виде получать информацию обо всех наследниках/имплементаторах, обо всех переопределяющих методах;
*) автоматические подсказки в случае ошибок из-за невнимательности;
...
C0s>ps. ide, на которых я начинал — типа turbo c, turbo pascal, по функциональности были слабее фара. и ничего, на них писались вполне сносные программы. C0s>pps. про интегрированный отладчик прошу флейм не затевать — аналогичный вроде есть в философии. мое имнсхо, хорошему программисту интегрированный отладчик не нужен, поэтому его наличие в ide преимуществом оных не считаю
Ощущение, что приверженцы венгерской нотации пишут в стиле процедурного программирования, объявляя в рамках одного класса несколько сотен переменных и констант, а раз их так много, значит и кода предостаточно — почему и боятся в них запутаться.
Не припомню, чтобы даже в самом тяжелом классе, который бы писал, количество полей класса и локальных переменных достигало бы такого критического количества, при котором можно было бы забывать их назначение. Хотя, нет, вру — было... когда был совсем зеленым программистом, постоянно скатывающимся в процедурное программирование. Как только такое обнаруживал, начинал разбивать класс на логические составляющие. Сейчас, слава богу, кажется, сразу пишу так, что такого и не бывает.
По поводу текстовых редаторов... Очень сомневаюсь, что крупный проект можно написать на таком уровне. Основное в IDE отнудь не подсветка синтаксиса, как мне кажется, а рефакторинг, а также поддержка командной разработки проекта.
GIV>Хуже IDE не станут, так что не надо нас будущим пугать,
Я? Пугаю? ЭТИМ? Бросьте вы
GIV>Никогда не читал код в распечатке. Какой в этом смысл? Это же банально неудобно. Как мне в распечатке найти все места вызова функции? И вокруг тоже никого не знаю с такими привычками... Сейчас же не 70 годы у каждого по компу слава богу а у некоторых и несколько.
Согласен что пример с распечаткой возможно не самый удачный, я хочу сказать что привыкать к раскраске кода и к фенькам IDEшки мо поему не гуд.
TBI>>3. Код должен быть максимально понятен и прозрачен. GIV>Согласен Однако на мой взгяд венгерская нотация этому только мешает.
GIV>Да и не так важно новые сотрудники или старые. Когда проект большой постоянно встречатся куски кода который либо вообще первый раз видишь либо видел когда-то (а то и сам писал) но уже все забыл давно.
Я про то, что у сотрудников разная квалификация, конкретно в моей контроре — обычно приходят студенты, к-ые яву видели 1 раз и твердо уверены что она только для того, чтобы апплеты рисовать. И если позволить им писать каждому по своему, будет свалка кода, которую проще будет переписать, чем перебрать и понять, что и где там не работает. Потому что когда начинают переменные от балды называть qqq, www и прочее — это уже не дело.
Соглашусь, что в квалифицированной команде, где таких детских болезней нет, венгерка возможно и излишня, но когда постоянно приходится держать в голове что, что тебе могут очередного студента подкинуть и придется опять нянчиться с ним — надо же его как-то под общую гребенку причесать.
Здравствуйте, TheBIG, Вы писали:
TBI>Согласен что пример с распечаткой возможно не самый удачный, я хочу сказать что привыкать к раскраске кода и к фенькам IDEшки мо поему не гуд. TBI>И если позволить им писать каждому по своему, будет свалка кода, которую проще будет переписать, чем перебрать и понять, что и где там не работает. Потому что когда начинают переменные от балды называть qqq, www и прочее — это уже не дело. TBI>когда постоянно приходится держать в голове что, что тебе могут очередного студента подкинуть и придется опять нянчиться с ним — надо же его как-то под общую гребенку причесать.
странное дело я вот согласен с написанным, но не считаю, что венгерка тут как-то помогает.
общие правила именования, обязательные для всех — безусловно нужны, и ведущий должен котролировать исполнение оных ведомым. но венгерка тут ни при чем...
ps. впрочем, на давноидущем проекте, в котором она используется, равно как и на следующих, которые будут выполняться ровно тем же коллективом людей, конечно, уже уйти никуда не удастся, да и не нужно это...
Хочу узнать ваше мнение о применении Венгерской Нотации в 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" — имя переменной)
Автору темы срочно поднимать все современные соглашения по оформлению кода. Единственная проблема, которая возникает — это путание локальных переменных и полей класса. Но в 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 похожий.
Я тоже раньше писал на С++ и использовал венгерку. Это скорее влиение традиции, чем реальная необходимость. В яве тоже есть свои традиции по оформлению кода, думаю их и стоит соблюдать.
Здравствуйте, C0s, Вы писали:
C0s>да уж и не помню, на "чисто" фар перешел 3 с половиной года назад, как только освоился с ant'ом. сначала пробовал с колорером, но напрягали тормоза и какие-то глюки. соотв. пронес колорер, с тех пор уже года три как без него.
Здравствуйте, C0s, Вы писали:
C0s>да уж и не помню, на "чисто" фар перешел 3 с половиной года назад
обманул, на фар в первый раз я перешел еще до java — шесть с лишним лет назад, когда на pl/sql много писал. потом, когда начинал с java, несколько месяцев попробовал с ide, потом забил и вернулся к проверенным средствам
C0s wrote:
> LCR> Я тоже в FAR, но как же без колорера-то? И насколько давно уже так > работаешь? > да уж и не помню, на "чисто" фар перешел 3 с половиной года назад, как > только освоился с ant'ом. сначала пробовал с колорером, но напрягали > тормоза и какие-то глюки. соотв. пронес колорер, с тех пор уже года три > как без него.
Колорер обновлялся за эти три года, последняя версия вполне сносная, тормозит только если в файле очень длинная строка
(несколько тысяч символов), но 1.5 меговый xml, разумно побитый на строки, вполне сносно в нём редактировать.
А насчёт интегрированного отладчика — я не могу им не пользоваться если надо разобраться в чужом коде, особенно, если
это какая-то левая библиотека.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
1. Большинстсво мнений по поводу ненужности венгрки, в т.ч. и в этой ветке, сводятся к тому, что IDEшка и так все сама показывает, расскрашивает и красиво подмигивает. Привязываться к контретной IDE, да и вообще к IDE, не есть гуд. Придется сменить IDE — и все, нужно привыкать к новым условиям.Я не призываю конечно писать в текстовом редакторе, поскольку одно дело когда код пишет один человек (тогда ом может ворорить хоть черта лысого, лишь бы сам разбирался), и совсем другое — когда работает команда разработчиков, с возможностью прихода новых сотрудников, которым еще надо вкурить в то, что их коллеги наваяли.
2. Код программы должен (имхо) быть читаем и на мониторе, и на бумаге в распечатке. Поэтому доводы "а зачем это, если у меня на мониторе он и так фиолетовый" неубедительны.
3. Код должен быть максимально понятен и прозрачен. Одиночка писать может как угодно и будет полностью прав — это его код, если ему не нужно шарить его с другими разработчиками, то флаг ему в руки. Когда пишет несколько человек, то использование метаданных о переменных нужно для того, чтобы упростить процесс вникания других разработчиков в новый код.
Здравствуйте, 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>Одиночка писать может как угодно и будет полностью прав — это его код, если ему не нужно шарить его с другими разработчиками, то флаг ему в руки. Когда пишет несколько человек, то использование метаданных о переменных нужно для того, чтобы упростить процесс вникания других разработчиков в новый код.
Нормально вникают сотрудники. И я тоже приходил в прошлый проект, если что и вызывало вопросы то это никак не было связано с проблемами которые пытатся решить с помощью венгерской нотации. А вот периодически встречащиеся мне тесксты с нотацией даются с трудом. Примерно как на незнакомом мне языке. А если учесть, что и все сторонние исходники тоже без нотации то это смешение стилей только усугубит ситуацию.
Да и не так важно новые сотрудники или старые. Когда проект большой постоянно встречатся куски кода который либо вообще первый раз видишь либо видел когда-то (а то и сам писал) но уже все забыл давно.
Я считаю что читаемость венгеской нотации — это дело привычки.
Мне постоянно приходится переключаться между проектами на 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, Вы писали:
C0s>>я пишу в FAR, причем давно без Colorer. но я тоже против венгерской нотации
А>Не обижайтесь, но я думал что диназавры вымерли )))) А>Возможно в FARe лучше чем Turbo C++, но сейчас 2006 год. А>)) млин, пойду пацанам расскажу что еще есть программеры которые на java в FARe прогают.
Здравствуйте, Igor.K, Вы писали:
IK>Спорим, что я быстрее наберу this.account быстрее чем Вы m_Account.
Вообще то это оффтоп, но после m_ помошник мне выкинет тот же список что и Вам после this.
IK>>Спорим, что я быстрее наберу this.account быстрее чем Вы m_Account. A>Вообще то это оффтоп, но после m_ помошник мне выкинет тот же список что и Вам после this.
Я, просто хотел заметить, что набрать this.a будет быстрее, чем m_A, неважно, что там выкинет помошник, и будет ли он вообще. А набрать this.account иногда может быть быстрее без помошника, чем, с включенным "помошником", если он, конечно, мешаться не будет.
"СССР — четыре слова и все лживые" — Вагрич Бахчанян
]
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Я тоже в FAR, но как же без колорера-то? И насколько давно уже так работаешь?
Однако на мой взгяд венгерская нотация этому только мешает.
Пищальников Юрий