про венгерскую нотацию и правилам оформления проги на дельфи?

← →
iZEN (2002-06-24 19:23) [40]

И ещё, венгерская нотация была придумана также для избегания конфликта имён во всём приложении. С приходом модульности и инкапсуляции это стало ненужным, даже вредным. Ведь обращение к любому методу/свойству теперь возможно через точечную нотацию (это также справедливо на уровне модулей TurboPascal/ObjectPascal).

Для программ на C/C++ часто необходимы были глобальные переменные и константы с похожими именами и разными типами, вот отсюда и пошло: новое имя придумать трудно, поэтому берём похожее имя, добавляем префикс типа и суффикс номера на всякий случай, чтобы всё было уникальным...

← →
evgeg (2002-06-24 19:27) [41]

Есть мнение, что венгерская нотация появилась из-за того, что Windows изначально писался на ассемблере. В языках с типизацией она совершенно не нужна и вредна.

← →
vuk (2002-06-24 19:33) [42]

to evgeg:
Windows изначально писялся на паскале. А возникновение венгерской нотации с написанием Win никак не связано. Так что откуда такое мнение - непонятно. :o)

А насчет нужна/не нужна - это кому и где как удобнее. Нотация - она ж не догма.

← →
wicked (2002-06-24 20:03) [43]

> Windows изначально писялся на паскале

это нарочно?... :)))

а вообще-то, я когда-то читал хорошую фразу о венгерской нотации:
...this is braindamaged ...

документ был codingstyle для ядра линукс, то есть описывал стиль написания исходников...

← →
iZEN (2002-06-24 20:05) [44]

Продолжу критику "стандарта" кодирования на Delphi ( http://download.olis.ru/pages.php?direction=softlab).

Это моё личное мнение, так что прошу не бить больно :).
Может кто-то со мной согласится, а кто-то нет.

1. Все зарезервированные слова языка лучше записывать строчными буквами: не Begin, но begin.

2. Имена типов (примитивных и объектных) записывать с заглавной буквы:
String, Integer, Boolean, TSome, TTimeRecord.

3. Параметры процедур/функций называть "человеческими" именами без префиксов и суффиксов. Если будет "локальный" конфликт имён, тогда подобрать близкие по смыслу слова и/или использовать точечную нотацию:
procedure SomeProc(const NewUserName: String; const NewUserAge : Integer); begin Self.UserName := NewUserName; Self.UserAge := NewUserAge; .... end;

4. Имена переменных не должны содержать "лишних" обозначений, относительно префиксов и суффиксов, никак не связанных с назначением переменной:
не iUserIndex, а просто -- UserIndex. Ведь и так понятно, что индекс может быть перечислимого типа, но необязательно только целого.

5. Константы записываются ЗАГЛАВНЫМИ буквами и имеют "человеческие" имена, возможно составные, разделённые знаком подчёркивания "_":
LEFT_PADDING.

6. Структура каталогов. Для проектов на Delphi лучше выбрать определённую структура каталогов для себя раз и навсегда -- меньше путаницы.
Вот моё дерево:
"Название проекта". +-bin -- папка с exe, dll и другими готовыми для дистрибуции файлами проекта. +-dcu -- папка временной компиляции модулей. +-doc -- папка документации проекта и API. +-api -- папка с документацией по API проекта. +-man -- папка с документацией для пользователя (help). +-etc -- папка хранения материалов, помогающих вести проект, но сам проект вполне может без них обойтись. +-lib -- папка с синхронными копиями библиотек кода, задействованными (возможно, корректируемыми) в проекте. +-src -- папка с исходниками проекта (*.dpr, *.pas, etc).
Соответственно, в настройках проекта, на вкладке Путей компиляции указываются относительные пути:
Для выходных файлов: "..\bin";
Для DCUs: "..\dcu";
Для библиотек: "..\lib"
и т.д. в таом же духе.
Что это даёт: облегчается архивация всех материалов проекта и быстрая процедура развёртывания проекта и для разработки, и для эксплуатации.

7. Имена файлов. Называйте их "человеческими" именами в разумноых ограничениях -- каталожная структура проекта не даст им "потеряться". А версионный контроль отдайте на откуп системе контроля версий -- не включайте версию в имена файлов и классов.

8. пока всё.

← →
vuk (2002-06-24 20:13) [45]

>это нарочно?... :)))
Нет. :o))) Промахнулся однако... :(

← →
Anatoly Podgoretsky (2002-06-24 20:15) [46]

Wizard_Ex © (24.06.02 18:14)
На том и стоим

evgeg © (24.06.02 19:27)
Нет, так как я много программировал на ассемблере, это пошло с С

← →
iZEN (2002-06-24 20:41) [47]

Продолжаю (по http://download.olis.ru/pages.php?direction=softlab).

Инструкции.

Инструкции if.
Надо избегать нагромождения инструкций if – вместо них лучше использовать (если это возможно) инструкции case. Не следует допускать вложения инструкций if на глубину более 5 уровней. Необходимо избегать лишних круглых скобок в инструкции if. Если с помощью инструкции if проверяется несколько условий, то их следует расположить слева направо в порядке возрастания интенсивности вычислений.

Немного нехорошо.
if лучше case и вот почему: в case сильно ограничен в плане вычислимости "входных" выражений. И, напротив, лучше использовать if-then-else для сложных ветвлений. Круглае скобки приветствуются -- так удаётся разобраться в "заумных" сплетениях условий и жёстко ограничить область их действия.

Инструкции while(repeat).
Не рекомендуется использовать процедуру Exit для выхода из цикла while.

Несовсем так.
Наверно, здесь говорится, скорее, о инструкции break. Так как инструкция Exit прерывает выполнение процедуры/функции и возвращает управление в вызывающий код. Однако, когда в результате выполнения процедуры/функции результаты её работы уже известны/никому не нужны, то имеет смысл использовать break для досрочного прерывания цикла while и Exit для досрочного выхода из процедуры/функции.

Инструкции with.
Инструкции with необходимо применять при достаточных на то основаниях и с большой осторожностью

Согласен. Лучше меньше, но лучше. Лучше вообще отказаться от использования этого оператора из-за потенциального "локального" конфликта имён.

Структурный подход.

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

Переиначу: не забывайте про эпсилон.

Следует быть внимательным и при сравнении строк (например сравнение переменных типов string и ShortString может дать неверные результаты).

Добавлю: будьте внимательны в том, что вы сравниваете. Может оказаться так, что вы будете сравнивать ссылки на строки, но не содержание строк (актуально для Java).

Не следует включать константные значения непосредственно в текст программы. Вместо этого лучше объявить константу в секции const и потом ее использовать.
Общие функции и константы лучше определить в одном модуле.

Лучше всё-таки обойтись инкапсуляцией "глобальных" констант в определённый класс свойств приложения, чтобы не зависеть от модульной организации.

← →
Anatoly Podgoretsky (2002-06-24 20:54) [48]

Ну что ты читаешь желтую прессу :-)

← →
iZEN (2002-06-24 21:05) [49]

/**Для Anatoly Podgoretsky © (24.06.02 20:54).
Ну что ты читаешь желтую прессу :-)
*/

Если имеется ввиду это: http://download.olis.ru/pages.php?direction=softlab
-- то это, скорее одна из альтернатив соглашений о кодировании (по-моему, не самая удачная, но во многих конторах, включая MS, применяемая).

А то, что я выше изложил в качестве своего мнения -- это всё от руки, от сердца, Copyright мой.

← →
Viewer (2002-06-24 21:14) [50]

Да уж..(24.06.02 13:51)
Особенно впечатлило единство Мы и MS = aka равенство.
*************

1.Если фирма(постановщики, major-manager) определила некоторый корпоративный стандарт программирования,
в том числе, стардарт нотации (вообще, а не венгерской) имен - честь ей и хвала !
Значит фирма зрелая, заботиться и дополнительной читабельности.
Конечно, только на нотации далеко не уедешь, но все же..
2. Теперь о самой нотации..
Если мы говорим о читабельности - должен быть разумный компромисс между длиной
поименованных сущностей и смысловой доступностью таких обозначений.
Нет, ну конечно, когда будет предложен неформальный язык (читай синтетический, но по подобию культурных),
когда возможности компиляторов дорастут до наших с Вами возможнсотей, в части понимания произнесенного
(написанного) с учетов интонации голоса, скрещенных пальцев за спиной и подмигивания соседке по балкону
- да, вот тогда..
А до тех пор, пока множество языковых конструкций, а также сами языковые конструкции, рассчитаны на понимание
их профи, но все же человеком, были и остануться попытки с"узить множество возможных "длинных сигналов"
к подмножеству более коротких, легко запоминаемых и правильно интерпретируемых, с высокой вероятностью.
За примерами далеко ходить не надо..
Множество проф.сфер имеет свой сленг (языковый, письменный, звуковой) хорошо понимаемый специалистами
из этих сфер.
Программирование не исключение.
3.Что касается венгерской нотации.
Она сыграла (и до сих пор играет) очень значимую роль в части стандартизации такой сложной сферы,
как нотация.

← →
Viewer (2002-06-24 21:15) [51]

Вот основные принципы положенные в ее основу:

1 мнемоническое значение: идентификатор должен легко запоминаться
2 смысловое значение: роль идентификатора должена быть ясна из его названия
3 преемственность: часто рассматривается как чисто эстетическая идея, но все же, похожие объекты
должны иметь похожие идентификаторы.
4 скорость решения: придумывание, ввод и редактирование идентификатора не должены занимать
слишком много времени, идентификатор не должен быть слишком длинным.

Всякое понимание основывается на выявлении смысла.
Элементарной лингвистической структурой, в которой выражается смысл, является высказывание.
Смысл можно понять, если только он выражен в высказывании или в некоторых лингвистических конструкциях,
построенных из связи высказываний.
Однако и само высказывание содержит более элементарные части - термины.
Чтобы понять высказывание в целом, нужно предварительно знать смысл входящих в него терминов.
Да ???
А как же "высказывание" ? Ведь именно оно, вроде как, таит смысл ?
Ответ состоит в том, что в используемых терминах смысл свернут, он сопутствует терминам неявно
и при малейших затруднениях в понимании фразы он должен быть развернут, т.е. представлен явно,
поясняющим высказыванием.

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

Семантические свертка и развертка относятся к числу основных и типичных смысловых операций,
без которых невозможно ни сформулировать сообщение (текст программы), ни понять его.

← →
Viewer (2002-06-24 21:17) [52]

Ах, да ! О чем это тут..
Да все о том же..
О нотации, о свертке смысловых конструкций и их развертке.
А поскольку, синтетические языки, в своей основе имеют формальный характер, то свертку нотационных
конструкций следует признать значимой составляющей в идеологии нотационного конструирования.
Точно также как и развертку, когда степень свертки выходит за рамки развертывающего ее. (Хи-хи)

Разница в именах и их дескрипциях !
Следует обратиться к Расселу, чтобы кое-что здесь прояснить.
Дескрипции - это ментал, классы, объекты - по нашему.
Имена - это то, что существует, экземпляры объектов, классов.

← →
Viewer (2002-06-24 21:17) [53]

По п.4 в пику русской нотации объектов и функций 1C (скажем) - "Это - что-то"
Ну и вообще, попытки в одном слове, составленном из обозначений-сущностей (тэгов) обозначить
понятную технологическую цепочку классов-методов-типов, мне напоминают методы создания
великолепных индейских имен, которые, будучи прочитанными, оставляют замечательное "образное" впечатление.
И только..
"Дети Орла, живущие у горной реки"
"Тот, сын от отца того, кто перешагнул ту реку, когда белые духи покрыли снежным покрывалом леса, в которых
мы добывали оленей"

Это хорошо для естественного языка.
Для справки:
~6 тыс глагольных форм в языке индейцев чиппева
70 префиксов у индейцев хайда
63 формы настоящего времени у экскимосов
182 символа - самое длинное слово (фрикасе) IV до н.э (кстати, последнее, вроде все поняли ?)
set (58 значений как существительное, 126 как глагол, 10 как прилагательное, образованное от причастия)
"mamihlapinatapai" из фуэгийского диалекта испанского языка - "смотреть друг на друга в надежде,
что один из двух предложит выполнить то, чего хотят обе стороны, не расположенные это делать".

Достаточно ?

← →
Anatoly Podgoretsky (2002-06-24 21:34) [54]

Класс!

← →
kull (2002-06-25 02:25) [55]

> iZEN (24.06.02 20:41)
> Продолжаю (по http://download.olis.ru/pages.php?direction=softlab).

Насчет while(repeat) - Да мне кажется действительно не стоит использовать Exit внутри циклов без особой необходимости IMHO некрасиво и нарушает принципы структурного программирования (то же относится и к Break) из цикла, как мне кажется, желательно выходить по условию в while, для того оно и предназначено. Это просто хороший стиль написания кода.

Насчет того что if лучше чем case. Опять не согласен. Конструкция Case легче читаема особенно если вариантов больше 2, в противоположность нагромождению if-ов.

Код, который поймет машина напишет любой идиот, надо писать код, который понимает человек.

Отсюда и всяческие стандарты, включая префиксную форму.
И не надо опираться на извращенные случаи с полным переопределением поведения предков так что название переменной уже ни о чем не говорит - это уже кривит и принципы ООП.

Я тогда вообще не понимаю на кой люди придумывали ООП и структурное программирование.

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

← →
iZEN (2002-06-25 02:57) [56]

/**kull © (25.06.02 02:25):
<...>
И не надо опираться на извращенные случаи с полным переопределением поведения предков так что название переменной уже ни о чем не говорит - это уже кривит и принципы ООП.<...>
*/

Что это не надо?
Например, абстрагируясь полностью от аппаратуры, создайте программный ООП-аналог терминала (дисплей, клавиатура, принтер). Всё это -- устройства ввода-вывода, но некоторые могут только выводить информацию в изменяемом виде(дисплей) и неизменяемом виде(принтер), другие могут только воспринимать информацию(клавиатура). Конечно, классы всех устройств можно представить как независимые друг от друга классы, но это не есть правильно -- неизбежное дублирование фрагментов кода вскоре сыграет злую шутку. Лучше создать абстрактный класс предка TTerminal для некоторых устройств и продолжить иерархию, переопределяя в классах потомках необходимые методы.
Прототип сторонней процедуры для обработки ввода-вывода формы терминалом: procedure InOutForm(Terminal: TTerminal; DataForm: TDataForm); begin Terminal.InOutProcess(DataForm.GetData()); end;
Абстрактно и непонятно?
Нет. Всё прозрачно. Здесь мы имеем дело с полиморфным вызовом метода какого-то Терминала по обработке данных Формы, причём сами объекты Терминала и Формы будут известны только на этапе выполнения приложения -- это вполне могут быть экземпляры потомков их классов, а не они сами.

ООП по барабану, как названа переменная-объект, главное -- нельзя извращать сами принципы функционирования. Имена с префиксом часто всё затуманивают, чем проясняют. Они явно годятся только для структурного программирования, но для ООП (как более высокого уровня программистской абстракции) префиксы -- хлам.

← →
kull (2002-06-25 03:11) [57]

Вот уж и не хлам.
Если переменная исходно определена каким-либо абстрактным классом который посути (через предков) предназначен для конкретного использования, так называйте ее исходя от абстрактного. По твоему переменные вообше не несут никакой нагрузки?

> Имена с префиксом часто всё затуманивают, чем проясняют.
>

А ьез префикса сильно проясняют? Что за чушь...

← →
kull (2002-06-25 03:27) [58]

Если код пишет кустарь-одиночка, он вправе называть переменные как его душе угодно (хотя в будушем при возвращении к своему "распухшему" коду - желаю успехов), но когда работает несколько человек (даже не над кодом), им просто необходимо найти общий язык.
Но если стандарты по-боку, что ж вперед ребята с топором на танки...

← →
iZEN (2002-06-25 07:26) [59]

Для kull © (25.06.02 03:27).

"На автозаводах сборочные цеха подвергаются постоянному совершенствованию, поскольку люди, делающие непродуктивную работу, осознают, что они непродуктивны, и исправляют это. Оригинальная параллель с программной инженерией должна заключаться в том, что руководства по кодированию должны совершенствовать процесс. Одно из наиболее дорогостоящих последствий барьера между картостроителями и паковщиками состоит в том, что паковщики, паникуя из-за "кризиса программного обеспечения", отстаивают утверждение, что "процесс" -- это необъяснимый и мистический источник всего хорошего и, будучи таковым, он правильный. В некоторых организациях процесс становится механизмом принудительных попыток внедрить тупой роботизм паковщиков на всех рабочих местах, поскольку он кажется правильным состоянием ума на пути к магическому успеху."
( http://www.progstone.nm.ru/reciprocality/r0/Day4.html)

← →
iZEN (2002-06-25 07:41) [60]

Было:
DWORD WINAPI SecondThread (LPVOID lpwThreadParm) { BOOL fDone = FALSE; DWORD dw; while (!fDone) { // Wait forever for the mutex to become signaled. dw = WaitForSingleObject(g_hMutex, INFINITE); if (dw == WAIT_OBJECT_0) { // Mutex became signalled. if (g_nIndex >= MAX_TIMES) { fDone = TRUE; } else { g_nIndex++; g_dwTimes[g_nIndex - 1] = GetTickCount(): } // Release the mutex. ReleaseMutex(g_hMutex); } else { // The mutex was abandoned. break;// Exit the while loop. } } return(0); }

Стало:
DWORD SecondThread(void *ThreadParm) { while(Index < MAX_TIMES && WaitForSingleObject(Mutex, INFINITE) == WAIT_OBJECT_0) { if (Index < MAX_TIMES) Times[Index++] = GetTickCount(): ReleaseMutex(Mutex); } return(0); }

( http://www.progstone.nm.ru/reciprocality/r0/Day2.html)

← →
iZEN (2002-06-25 07:45) [61]

Комментарии:

"Одиннадцать строк против 26. На один уровень меньшая вложенность, но структура полностью прозрачна. Две локальных переменных исчезли. Нет блоков. Совсем нет вложенных else. Меньше мест, где могут скрываться ошибки.

(Если вы еще не программировали используя потоки (threads), то повторная проверка значения Index внутри тела цикла кажется грубой и ненужной. Если же программировали, то повторная проверка естественна и очевидна. Это очень важно: пока текущий поток приостановлен в WaitForSingleObject, другой поток скорее всего будет активен и изменит значение. То, что для вас очевидно, зависит от вашего опыта: еще одна мораль из этого примера -- рассмотрения только структуры куска кода недостаточно.)

Наконец, текст делает совершенно ясным, что разные потоки выполняют функции в разных контекстах. Поэтому совершенно не нужно определять функцию с именем FirstThread(), в точности такую же, как SecondThread(), и вызывать их так:

hThreads[0] = CreateThread(..., FirstThread, ...);
hThreads[1] = CreateThread(..., SecondThread, ...);

Когда можно просто

hThreads[0] = CreateThread(..., TheThread, ...);
hThreads[1] = CreateThread(..., TheThread, ...);"

← →
Игорь Шевченко (2002-06-25 09:23) [62]

iZEN (25.06.02 07:45)

Цитата из ProgStone хороша для небольших проектов (в том числе и для примеров Джеффри Рихтера). Как только объем исходного кода проекта превышает некую величину, удобочитаемость естественных имен приводит к тому, что требуется больше времени для того, чтобы разобраться в отдельных его частях.

С уважением,

← →
PVOzerski (2002-06-25 10:32) [63]

Не могу удержаться от комментариев:
1) kull © (25.06.02 02:25):
>Насчет того что if лучше чем case. Опять не согласен.
>Конструкция Case легче читаема особенно если вариантов
>больше 2, в противоположность нагромождению if-ов.

Это уж как текст форматировать...
if s="First" then
begin
x:=1;
writeln("One");
end
else if s="Second" then
begin
x:=2;
writeln("Two");
end
else
begin
x:=-1;
writeln("Incorrect value");
end;

IMHO, читается не хуже блока case. К тому же, Case применим только для перечислимых типов и требует констант для сравнения, так что сфера примения этого оператора у"же.

Об именах. Если уж мы работаем с VCL, надо уж принятого в ней стандарта и держаться (может быть, с какими-то уточняющими мелочами "для себя"). Даже IDE именно к этому приспособлена. Попробуйте-ка сделать имя типа для формы, начинающееся не с буквы T! Хотя формально синтаксис Object Pascal этому вроде бы не препятствует.

← →
kull (2002-06-25 11:38) [64]

> iZEN (25.06.02 07:45)

SecondThread FirstThread - неудачный пример.
Не надо сравнивать острое с белым.

11 против 26 что-то не понял, ну и отлично - я тоже за то, чтобы без Break обходиться.

> iZEN (25.06.02 07:26)

Здесь я тоже что-то не въехал (глупый наверное).
Я как раз против мистики в программировании - чудес не бывает ( как говорится налажал так налажал).
Как раз строгий, легко воспринимаемый (не только создателем) код,соблюдение стандартов - все это помогает избавится от мистического налета.

← →
kull (2002-06-25 11:51) [65]

> . Попробуйте-ка сделать имя типа для формы, начинающееся
> не с буквы T!

А почему это нельзя делать?
А такие классы: Exception, EAbort ....?

А например типы Byte, Integer, ShortString ... что-то я не наблюдаю особого стандарта...

← →
kull (2002-06-25 12:02) [66]

Нет, что вы, разве я настаиваю?
ТВорите что хотите вот в старину люди дома строили без гвоздей и отличные дома получались.

А какие храмы возводились: каждый камушек - произведение искусства. Чуть ли не каждый элемент индивидуален.
Да это конечно лучше чем современные блочные дома.
НО все эти произведения строилисть десятки, а может и сотни лет.

Стандарты это неотъемлемая часть RAD.
Если бы в Borland-е писался код так как вздумается каждому программеру, то сидели бы вы ребята сейчас под VC++ или VB, да мало ли пакетов хороших.
А про Delphi могли бы и не узнать...

← →
Anatoly Podgoretsky (2002-06-25 12:11) [67]

PVOzerski © (25.06.02 10:32)
Тут немного другое, не связаное с конкретными типами (integer, dword, string) это более высокого уровня, как в жизни - класс, семейство, вид - чистая объектная ориентация.
Что позволяет писать почти в естественном виде

[переменная] ФормаХХХ : типа (Т)ФормаХХХ
[переменная] Abc : типа (Т)Abc

то есть просто любой тип и любая переменная, получаем связанное имя переменной и имя_типа
То же относится и к полям Fxxx и обноименным свойствам

Ну зачем мне знать конкретный тип, его внутреннюю организацию интегер он там или дворд, это дело компилятора, мне нужна только общая суть, одно переменная/свойство порожденная от одноименного типа/поля, совсем другое дело Person : TPerson, то есть только степень подчиненности, родства

← →
Бурундук (2002-06-25 12:24) [68]

2Игорь Шевченко ©
>Цитата из ProgStone хороша для небольших проектов (в том числе >и для примеров Джеффри Рихтера). Как только объем исходного >кода проекта превышает некую величину, удобочитаемость >естественных имен приводит к тому, что требуется больше времени >для того, чтобы разобраться в отдельных его частях.

Кто мне скажет, что в исходниках VCL трудно разбираться, в того я первый брошу камень :-).

ИМХО, в больших проектах для удобочитаемости важно прежде всего правильное проектирование. Если можно так выразиться, дома надо строить из панелей, кварталы из домов, а город из кварталов. Если же строить город из кирпичей, то как их не назови, всё равно в результате получится уродство.

← →
Игорь Шевченко (2002-06-25 13:10) [69]

Бурундук (25.06.02 12:24)

Вы считаете, Windows - это город из кирпичей ?

В исходниках VCL разобраться относительно легко. Правда, комментариев маловато, на мой взгляд. В исходниках Interbase разобраться уже несколько труднее...

← →
kull (2002-06-25 13:24) [70]

> Кто мне скажет, что в исходниках VCL трудно разбираться,
> в того я первый брошу камень :-).

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

Названия классов и типов, которые предназначены для определенного проекта могут быть уже подчинены каким-то правилам.

К тому же в VCL не спроста стоит перед названиями классов префикс T, как раз для того чтобы не было трудно разбираться.

А у интерфейсов I,
а у исключений E,
а у сообшений WM_ ,
а у кодов клавиш VK_ ,
а переменные члены с F начинаются,
а функции возвращающие с Get,
а функции устанавливающие c Set,
а конструкторы Create,
а деструкторы Destroy,
а типы-указатели с P.

Разве это не помогает читать код в Delphi ?

← →
PVOzerski (2002-06-25 13:40) [71]

2kull © (25.06.02 13:24) (и др.)
Только вот смешалось всё в RTL и VCL (м.б., где-то перепутаю, но тенденцию-то покажу правильную):
>А у интерфейсов I,
Это от M$ (WinAPI);
>а у исключений E,
а это от Borland;
>а у сообшений WM_ ,
>а у кодов клавиш VK_ ,
а это опять WinAPI...
>а конструкторы Create,
>а деструкторы Destroy,
>а типы-указатели с P.
а это снова Borland;
А самое смешное - поля записей, конвертнутых из API-шных структур (unit Windows и т.п.), - именно в ВЕНГЕРСКОЙ НОТАЦИИ - как тяжкое наследие Microsoft :^)

BTW, не люблю я, когда T и P сливаются с осмысленной частью названия типа - иногда ненароком читаешь слитно, абсурд какой-то получается. Поэтому, благо Паскаль нечувствителен к регистру, обычно пишу вместо TForm1 tForm1 - и IDE не гневается, и самому удобнее становится.

← →
kull (2002-06-25 13:51) [72]

Так значит tFrom1 а не Form1? все-таки t прибавляешь, значит это вносит какой-то смысл.

Ну ладно, некислая ветка пошла, приятно было пободаться :)

← →
Бурундук (2002-06-25 13:58) [73]

2Игорь Шевченко ©
>Вы считаете, Windows - это город из кирпичей ?
Я, вообще-то, не о виндовс. (Я не видел исходников Виндовс и не знаю, насколько их легко читать). Я о том, что ИМХО очень сложно создать на том же Дельфи большой проект без создания сопутствующей библиотеки специфических для данного приложения объектов (не обязательно компонетнов, даже наоборот).

На самом деле в С венгерская нотация имеет сильную мотивировацию: например, если Вы ошибетесь и в качестве параметра по ссылке вместо DWORD дадите int - то компилятор, прежде чем сказать, что Вы не правы, будет полчаса думать.
В паскале же это секундное дело.

2kull ©
>Исходники VCL предназначены для очень большого круга людей и >представляют библиотеку наиболее распространненых, часто >используемых и не специально не предназначенных для конкретного >проекта классов.

Так что мешает писать библиотеку классов, предназначенных специально для данного проекта, что бы их было также легко читать?

>А у интерфейсов I,
>а у исключений E, ...

Нотация VCL не требует громоздкого префикса для КАЖДОЙ переменной и члена класса.

Лично мне венгерская нотация (особено с дополнительными префиксами типа m_lpszXXX) по сравнению с ней кажется громоздкой и неэлегантной.
Но, как я уже сказал, в С она имеет некоторый смысл из-за медлительности компилятора.

← →
kull (2002-06-25 14:07) [74]

> Но, как я уже сказал, в С она имеет некоторый смысл из-за
> медлительности компилятора.

??????????????????????????????????.
Вот это да !!!!!!!!!!!!!!!

← →
PVOzerski (2002-06-25 14:24) [75]

>Так значит tFrom1 а не Form1
Form1 - переменная, tForm1 - тип. В отличие от венгерской нотации, в нотации, принятой в VCL, в целом, очень ограниченный набор префиксов, потому не порождающей путаницы (я же только сменил регистр префиксов с верхнего на нижний, потому что мне так удобнее читать). А в венгерской нотации, описал я в одном месте локальный тип tMyType=integer (tMyType - это еще не венгерская) и переменную tMTVar1:tMyType (а вот это уже, IMHO, "по-венгерски" :^) ), а в другом - tMyType=string и переменную tMTVar2:tMyType - и что толку в этих префиксах? Я не силен в C/C++, но подозреваю (ошибаюсь - поправьте, на практике не сталкивался), что там локального описания типов (действительного только внутри одной функции) не предусмотрено, отсюда - хоть какая-то осмысленность этих "венгерских" префиксов. А в Turbo/Object Pascal еще и юниты есть...

← →
kull (2002-06-25 14:27) [76]

> Form1 - переменная, tForm1 - тип.

так все-таки t имеет смысл?

← →
PVOzerski (2002-06-25 14:42) [77]

Имеет, конечно, кто же спорит. Только несёт куда более общую информацию, чем при венгерской нотации.

>> Но, как я уже сказал, в С она имеет некоторый смысл из-за
>> медлительности компилятора.
>
>??????????????????????????????????.
>Вот это да !!!!!!!!!!!!!!!

Наверное, автор имел в виду "для медлительности программера" :^)

← →
Игорь Шевченко (2002-06-25 14:48) [78]

О вкусном не спорят :-)))

Бурундук (25.06.02 13:58)

> На самом деле в С венгерская нотация имеет сильную мотивировацию:
> например, если Вы ошибетесь и в качестве параметра по ссылке
> вместо DWORD дадите int - то компилятор, прежде чем сказать,
> что Вы не правы, будет полчаса думать.
> В паскале же это секундное дело.

Это вы, мягко говоря, погорячились :-))

← →
Бурундук (2002-06-25 15:07) [79]

Ну, может быть, погорячился :-))).

← →
Cobalt (2002-06-25 21:16) [80]

А мне, отчего-то, казалось, что венгерская нотация применяется только для простых типов, а не для структур и классов.
P.S. кстати, фрагмент из WinAPI - не использует венгерскую нотацию (ОНА НЕ ВСЕСИЛЬНА!!!;)
typedef struct _ACL { // acl
BYTE AclRevision;
BYTE Sbz1;
WORD AclSize;
WORD AceCount;
WORD Sbz2;
} ACL;

про венгерскую нотацию и правилам оформления проги на дельфи? Найти похожие ветки