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

← →
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]

Игорь Шевченко © (24.06.02 13:12)
Первое, о чем я подумал, так это о фреймах :-)

← →
Игорь Шевченко (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++ часто необходимы были глобальные переменные и константы с похожими именами и разными типами, вот отсюда и пошло: новое имя придумать трудно, поэтому берём похожее имя, добавляем префикс типа и суффикс номера на всякий случай, чтобы всё было уникальным...

← →
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;

← →
VuDZ (2002-06-25 22:44) [81]

Всё не читал, но пару мыслей выскажу (чуству сейчас будут бить. И возможно - даже ногами :>)

Чем хороша венгерская нотация - при большом кол-ве глобальных переменных меньшая путаница.

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

Ну-ну... А как на счёт указателей на переменную типа DWORD, которая всегда должна быть NULL? За оба этих случая убивать надо. Все структуры в хэдерах описаны с использованием венгерской нотации, исключения - для внутреннего пользования... Хотя врят ли - это привычка подставлять префиксы.
Хотя есть много гуру, которых я уважаю, но они не используют венгерку.

Практически в любой крупной конторе, где пишут не Hello, world есть свои правила нотации - они могут отличаться от общепринятых, но они есть, так как это исключает путаницу. особенно это хорошо понятно при сопровождение очеь больших проектов...
____________________________________________________________
Ну и вообще, я пошёл спать, а то holy war это канэшна круто, но приедается...

← →
iZEN (2002-06-27 09:00) [82]

Java-библиотеки (JFC/Swing, например) -- образец для написания полноценных ООП-библиотек. :) Вот. (IMHO)

← →
SPeller (2002-06-27 09:57) [83]

Ну и развели тут.. :) Я лично когда пишу код обзываю переменные так чтобы легко понималось что это такое. frmMain - сразу понятно что форма, да ещё и главная, Counter - счётчик, особых размышлений о его типе не возникает, PTestParams - указатель на структуру. Никаких lp, sz, hz, mz. А венгерскую нотацию в Винапи переживаю как неизбежное. Хотя иногда переопределяю в отдельном модуле некоторые АПИ функции для избежания преобразования типов, и там то указываю имена какие мне нравятся.

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