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

← →
N A N (2002-06-21 14:23) [0]

где можно почитать про венгерскую нотацию по отношению к дельфи и правилам оформления проги на дельфи? Ну типа там правила расстановки отступов, именования идентификаторов, оформление циклов и условий и т.д. Есть ли вообще какой-то стандарт в этом отношении?
А то проблемы возникают в чтении и разборе чужих прог и хотелось бы в конторе например стандартизировать как-то процесс оформления прог!

← →
Игорь Шевченко (2002-06-21 14:33) [1]

За стандарт можно взять исходный код VCL.
Почитать можно у Тейксейры и Пачеко: "Delphi 5. Руководство разработчика" - там целая глава этому посвящена.
О венгенрской нотации там ни слова. :-)

С уважением,

← →
N A N (2002-06-21 14:36) [2]

Тейксейры и Пачеко: "Delphi 5. Руководство разработчика" - на это в он-лайне посмотреть можно где-нибудь?

>За стандарт можно взять исходный код VCL.
а это как-то не очень хотелось бы каких-то фрмализованных правил по оформлению программы -> стандарт короче.

← →
Виктор Щербаков (2002-06-21 14:45) [3]

> О венгенрской нотации там ни слова. :-)

Просто они не говорят что это называется венгерской нотацией.
Я об именах идентификаторов типа GetComputerName.

> на это в он-лайне посмотреть можно где-нибудь?

Сокращенный вариант есть на UBPFD.

← →
N A N (2002-06-21 14:51) [4]

>Сокращенный вариант есть на UBPFD.
а поточнее ссылку ?

← →
Виктор Щербаков (2002-06-21 14:56) [5]

http://delphibase.endimus.com/?action=coderules

← →
kull (2002-06-21 15:13) [6]

Небольшой стандартик:
http://download.olis.ru/pages.php?direction=softlab

← →
Игорь Шевченко (2002-06-21 16:28) [7]

Виктор Щербаков © (21.06.02 14:45)

> > О венгенрской нотации там ни слова. :-)
>
> Просто они не говорят что это называется венгерской нотацией.
> Я об именах идентификаторов типа GetComputerName.

Это не венгерская нотация. Венгерская нотация - это префикс типа перед именем переменной, например lpszComputerName, pnfMyCoolProc, dwSize и т.д.

С уважением,

← →
Виктор Щербаков (2002-06-21 16:39) [8]

Игорь Шевченко © (21.06.02 16:28)
Ага. Что то я перепутал немного :)
Но у Тейксейры и Пачеко и про это есть (префиксы для перечислимых типов).

← →
iZEN (2002-06-23 23:49) [9]

lpszComputerName, pnfMyCoolProc, dwSize и т.д. -- это никому ненужная шелуха, которая засоряет текст программы и алгоритма.

НИКОГДА НЕ ПОЛЬЗУЙТЕСЬ венгерской нотацией, называйте вещи своими именами -- если в имени переменной есть сокращение имени типа, к которому она принадлежит, Вы всё равно не узнаете, что она обозначает.

См. на этот счёт "Программистский камень":
http://www.progstone.nm.ru/reciprocality/r0/index.html

← →
kull (2002-06-24 02:39) [10]

> lpszComputerName, pnfMyCoolProc, dwSize и т.д. -- это никому
> ненужная шелуха, которая засоряет текст программы и алгоритма.

Вот так шелуха!
А может и типы у переменных не нужны?
Давайте-ка из Delphi Visual basic сделаем...

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

Может просто будем писать Button1, Button2, Form1, и т.п.?

← →
Anatoly Podgoretsky (2002-06-24 07:49) [11]

А ты за символы для символов

← →
Praco (2002-06-24 09:20) [12]

iZEN (23.06.02 23:49)
"ненужная шелуха"
Да, не самый лучший способ повышения читаемости кода.

N A N (21.06.02 14:23)
У меня есть чей-то пример стандартов на Delphi & IB. Выслать?

← →
Dok_3D (2002-06-24 09:41) [13]

2iZEN (23.06.02 23:49)
lpszComputerName, pnfMyCoolProc, dwSize и т.д. -- это никому ненужная шелуха

Я тоже раньше так думал.
На самом деле, это очень сильно облегчает навигацию в собственных громоздких текстах кода. Поначалу, конечно, было непривычно увеличивать длину имени каждой переменной на 2-3 символы. Но потом, когда количество строк кода достигает нескольких тысяч эти префиксы помогают быстро понять, что же ты хотел сделать в том или ином участке программы.

Естественно, данная договоренность очень сильно улучшает восприятие кода другим специалистом.

← →
Игорь Шевченко (2002-06-24 10:17) [14]

Dok_3D © (24.06.02 09:41)
> На самом деле, это очень сильно облегчает навигацию в собственных
> громоздких текстах кода. Поначалу, конечно, было непривычно
> увеличивать длину имени каждой переменной на 2-3 символы.
> Но потом, когда количество строк кода достигает нескольких
> тысяч эти префиксы помогают быстро понять, что же ты хотел
> сделать в том или ином участке программы.

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

Любые соглашения об именовании улучшают восприятие кода специалистом, который их принял и ухудшают восприятие кода теми, кто не принял :-)

С уважением,

← →
Anatoly Podgoretsky (2002-06-24 10:30) [15]

iAbc
dwAbc
frmAbc

очень сильно улучшили восприятие

← →
Виктор Щербаков (2002-06-24 10:36) [16]

Я тоже не являюсь сторонником венгерской нотации. Когда типов много (сотни) две три буквы префикса ни о чем не скажут.
Так что Anatoly Podgoretsky © правильно подметил.

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

← →
Dok_3D (2002-06-24 10:41) [17]

2Игорь Шевченко © (24.06.02 10:17)
Любые соглашения об именовании улучшают восприятие кода специалистом, который их принял и ухудшают восприятие кода теми, кто не принял :-)

Согласен, хотя привыкнуть к такому соглашению можно за очень короткий промежуток времени.

2Anatoly Podgoretsky © (24.06.02 10:30)

Да, очень.
В произвольной точке кода можно безошибочно определить тип переменнной, не поднимаясь каждый раз в заголовок.
Написание
AbcMy
AbcMy1
AbcMy2
вообще не даст вам никакой информации о переменной.
А вопрос улучшения восприятия в данном случае так и остается открытым.

← →
Anatoly Podgoretsky (2002-06-24 10:52) [18]

Ты только не думай, что я тебя отговариваю, это дело твое

← →
kull (2002-06-24 11:49) [19]

> iAbc
> dwAbc
> frmAbc
>
> очень сильно улучшили восприятие

Да, наверное
Abc
Abc
Abc
говорят о себе намного больше.

----------------------------
Abc.Close
или
frmAbc.Close
Что легче прочитается с пониманием того что здесь пытаются закрыть, Db курсор или форму?

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

← →
Anatoly Podgoretsky (2002-06-24 11:57) [20]

Ты хочешь понимания?

AbcForm.Close
AbcTable.Close

← →
Игорь Шевченко (2002-06-24 12:08) [21]

Anatoly Podgoretsky © (24.06.02 11:57)

> AbcForm.Close
> AbcTable.Close

Это постфиксная нотация :-)
Венгерская - префикная :-)

← →
Anatoly Podgoretsky (2002-06-24 12:24) [22]

Это не нотация, а естетвенный английский язык, была бы тонация, то это выглядело бы так AbcI, AbcFrm, AbcTbl для постфиксной

← →
kull (2002-06-24 12:26) [23]

> Anatoly Podgoretsky © (24.06.02 11:57)

А чем AbcForm в принципе отличается от frmAbc.
Здесь тоже самое уточнение типа как не крути.
У ж всяко лучше чем Abc.
И зачем что-то выдумывать если за тебя уже подумали и создали какие-то правила.

И к тому же тип (класс) переменной первичнее, например:

Бочонок Водки.
Бочонок Кваса.
Бочонок - это тип он более абстрактен, чем конкретное содержание.
Он определяет что модно с объектом делать и как (например катать ...).

Так почему бы не писать информацию о типе, который определяет поведение, как префикс?

← →
Игорь Шевченко (2002-06-24 12:37) [24]

Сколько лет существуют всякие соглашения об именовании - столько лет вокруг них ведутся священные войны :-))

Дело не в том, какая система названий лучше или хуже, дело в том, что в члены коллектива, принявшего какое-то соглашение об именах, обычно лучше понимаю программы друг друга. Microsoft и Borland тому примеры.

А соглашение хорошо любое, главное, чтобы его придерживалось более одного человека :-)

← →
Anatoly Podgoretsky (2002-06-24 12:39) [25]

Да зачем придумывать символы для символов?

← →
Игорь Шевченко (2002-06-24 12:45) [26]

Anatoly Podgoretsky © (24.06.02 12:39)

> Да зачем придумывать символы для символов?

Как ни странно, поднимает дисциплину в команде :-)

← →
kull (2002-06-24 12:48) [27]

> А соглашение хорошо любое, главное, чтобы его придерживалось
> более одного человека :-)

Эт точно.

> Да зачем придумывать символы для символов?

I don"t understand
Я не понимат. Я очен плохо понимат...

← →
Anatoly Podgoretsky (2002-06-24 12:57) [28]

EditForm это уже символ, на естественном языке, зачем выдумывать еще один символ на искуственном языке, ты же не в С/VB программируе с их слабой типизацией

← →
kull (2002-06-24 13:10) [29]

А понял.
Так это для кого какой язык является естественнее тот так и пишет.
К томуже EditForm тоже что и frmEdit.
Но есть один момент.

EditForm может быть не только формой на экране, но и формой документа для бухгалтера, анкеты, сеансом редактирования (состоянием), или способом редактирования (например в Delphi форму (dfm) можно редактировать мышкой, а можно как текст) и т.д.

А вот frmEdit явно говорит о том, то это именно форма.

← →
Игорь Шевченко (2002-06-24 13:12) [30]

kull © (24.06.02 13:10)

> А вот frmEdit явно говорит о том, то это именно форма.

Явно не говорит. Это вообще ни о чем не говорит тому, кто не знает ваших стандартов об именах.

← →
kull (2002-06-24 13:29) [31]

> Явно не говорит. Это вообще ни о чем не говорит тому, кто
> не знает ваших стандартов об именах.

Да причем здесь конкретный стандарт?
frm можно поставить в любое место в имени или заменить на что другое. Дело не в этом.

Anatoly Podgoretsky, как я понимаю, имеет ввиду то, что достаточно просто назвать переменную понятно.
Но дело в том, что для одного это понятно, а для другого нет, потому что нет общих правил, которых придерживаются.

Один назовет EditForm, другой - FormForEditing. Это просто случай такой понятный попался, а если
кому-то понятно такое WindowForFilling?

← →
Anatoly Podgoretsky (2002-06-24 13:35) [32]

← →
Игорь Шевченко (2002-06-24 13:39) [33]

Случай из жизни: в паскалевской программе встретились объявления:

var
lpForm, lpTo : Boolean;

Перед этим вводилась венгерская нотация.

Спрашиваю у автора - что значит этот префикс (lp)?
Он мне отвечает - локальная переменная. А у самого глаза чистые-чистые :-)))

Так что frmEdit - ничего никогда не объяснит тому, кто не принял этот стандарт

← →
Anatoly Podgoretsky (2002-06-24 13:42) [34]

kull © (24.06.02 13:29)
Суть понял правильно, конечно если речь идет об конкретной форме, то лучше более значимый вариант, ФормаЗаказаБилетов, ФормаРедактированияТаблицыКлиентов, естественно по английски, так как в Дельфи другое нельзя.

← →
Игорь Шевченко (2002-06-24 13:51) [35]

Anatoly Podgoretsky © (24.06.02 13:42)

> ФормаЗаказаБилетов, ФормаРедактированияТаблицыКлиентов

Вот и мы к этому пришли. MS, кстати, тоже.

← →
kull (2002-06-24 13:57) [36]

> Так что frmEdit - ничего никогда не объяснит тому, кто не
> принял этот стандарт

Да разве я с этим спорю...

← →
Wizard_Ex (2002-06-24 18:14) [37]

> Anatoly Podgoretsky © (24.06.02 12:57)
> EditForm это уже символ, на естественном языке, зачем
> выдумывать еще один символ на искуственном языке,
> ты же не в С/VB программируе с их слабой типизацией

Ну молодец,ну молодец
За крутую типизацию горой :-)

← →
iZEN (2002-06-24 19:02) [38]

Иногда бывает нужно сменить предка у класса, причём с кардинальной перестройкой функционирования предка, изменив интерактивное взаимодействие на транзакционное (здесь: грубо заменив форму с кнопками на процедуру генерации Web-формы или принтерной копии, естественно, "без кнопок"). Но класс-наследник-то остаётся почти без изменений в виде визуальной интерактивной формы для обеспечения редактируемости данных (таков дизайн).

Допустим, нам надо передать ссылку на объект интерактивной формы какому-то методу/процедуре/функции, в прототипе которого записано, что он может обрабатывать только данные объекта базового (транзакционного) класса (это вполне согласуется с ООП-парадигмой о полиморфизме в работе с объектами классов-наследников).

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

← →
iZEN (2002-06-24 19:14) [39]

Так что лучше:
вместо frmEdit называть EditForm;
btExit --> ExitButton;
mnuMain --> MainMenu;
miFile -- FileMenuItem;
pnlMessages --> MessagesPanel --> лучше просто, Messages;
lpintI --> i;
slNames --> NamesStringList --> лучше просто, Names;
и т.д.

Главное, чтобы объекты, с которыми ты непосредственно работаешь из кода, имели "человеческие" имена, необязательно с приставкой имени типа. Тип объекта всегда можно узнать, в этом поможет компилятор и сама IDE, если вы не представляете, с чем имеете дело.

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

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

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

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