2. СОГЛАШЕНИЕ ОБ ИМЕНОВАНИЯХ

Исключая зарезервированные слова и директивы, которые всегда пишутся в нижнем регистре, все идентификаторы Delphi должны использовать InfixCaps, например:

MyIdentifier MyFTPClass

Самое главное исключение для всех правил состоит в использовании оттранслированных заголовочных файлов С/С++. В этом случае всегда используются соглашения, принятые в файле источнике. Например, будет использоваться WM_LBUTTONDOWN, а не wm_LButtonDown.

Имя класса должно быть именем существительным или фразой с именем существительным. Имена интерфейсов или классов должны отражать главную цель их создания.

Для разделения слов нельзя использовать символ подчеркивания. Его использование допускается в следующих случаях:

Правильно:
  AddressForm
  ArrayIndexOutOfBoundsException

Неправильно:
  ManageLayout (глагол)
  delphi_is_new_to_me (подчеркивание)

2.1. ИМЕНОВАНИЕ МОДУЛЕЙ

Наименование модуля должно построено быть по принципу: "u" + "Имя формы". Если модуль не содержит формы (модуля данных), то первая литера "u" сохраняется, далее идет функциональное наименование модуля.

2.2. ИМЕНОВАНИЕ ФОРМ И МОДУЛЕЙ ДАННЫХ

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

Имя формы строится по принципу "Функциональное имя формы" + "Form".

Имя модуля данных строится по принципу: "Имя формы без постфикса Form" + "DM".

Главный модуль данных приложения именуется "MainDM". Главный модуль содержит глобальные параметры подключения к БД, обеспечивает функции для доступа к таблицам с настройками.

Рекомендуется, чтобы каждой форме соответствовал только один модуль данных, ссылающийся только на главный модуль данных приложения. Не допускается наличие у каждого модуля данных своего подключения к БД, если логикой приложения это отдельно не предусмотрено.

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

2.3. ИМЕНОВАНИЕ КЛАССОВ И ИНТЕРФЕЙСОВ

Смотри объявление классов и интерфейсов.

2.4. ИМЕНОВАНИЕ ПОЛЕЙ

При именовании полей всегда необходимо использовать InfixCaps. Всегда объявлять переменные только в приватных частях и использовать свойства для доступа к переменным. Для переменных использовать префикс F.

Имена процедур для установки/получения значений свойств должны составляться по правилу: для получения - Get+имя свойства; для установки - Set+имя свойства.

Правильно
  FMyString: string;

Неправильно
  lpstrMyString: string;

Исключение для Венгерской нотации делается в случае объявления перечислимого типа:
  TBitBtnKind = (bkCustom, bkOK, bkCancel, bkHelp,
    bkYes, bkNo, bkClose, bkAbort, bkRetry,
    bkIgnore, bkAll);
  bk обозначает ButtonKind

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

Переменные цикла именуются I (обычно) и J, K (для вложенных циклов, когда I уже используется). Однако это не значит, что не должны быть использованы более выразительные имена, например, UserIndex.

Другие случаи использования однобуквенных переменных это S (строка) и R (результат). Однобуквенные имена должны всегда использовать символ в верхнем регистре, но лучше использовать боле значимые имена. Не рекомендуется использовать переменную l (эль), потому что она похожа на 1 (единица).

2.5. ИМЕНОВАНИЕ МЕТОДОВ

При именовании полей всегда необходимо использовать стиль InfixCaps. Не допускается использование символов подчеркивания для разделения слов. В имени метода всегда должна содержаться команда к действию или глагольная фраза

Правильно:
  ShowStatus
  DrawCircle
  AddLayoutComponent

Неправильно:
  MouseButton (Существительное, не описывает функцию)
  drawCircle (Начинается с маленькой буквы)
  add_layout_component (Используются символы подчерка)
  ServerRunning (Глагольная фраза, но без команды)

Обратите внимание на последний пример (ServerRunning) - непонятно, что делает этот метод. Этот метод может использоваться для запуска сервера (лучше StartServer) или для проверки работы сервера (лучше IsServerRunning).

Методы для установки или получения значений свойств должны именоваться Get+имя свойства и - Set+имя свойства.

Например:
  GetHeight, SetHeigh

Методы для теста/проверки булевских свойств класса должны именоваться с префиксом Is+имя свойства.

Например:
  IsResizable, IsVisible

Для создания пар операций рекомендуется использовать следующие префиксы.

Не допускается смешивание функций из разных пар (например Get/Save – это неправильно).

2.6. ИМЕНОВАНИЕ ПЕРЕМЕННЫХ

Имена всех локальных переменных должны подчиняться тем же правилам, которые установлены для именования полей, исключая префикс F.

Переменные, содержащие двоичные значения (флаги) могут именоваться либо с префиксом Is+имя свойства, либо с префиксом Flg+имя свойства, не рекомендуется использовать префикс "not", выражающий отрицание, всегда следует в таком случае заменять его на "Is", т.е. не использовать "NotFound", лучше "IsFound".

Рекомендуется использовать префикс "N" если переменная представляет количество чего-либо, например NItems; если переменная представляет номер, то окончание "No", например "RecordNo".

2.7. НОТАЦИЯ (ПРЕФИКСЫ) ДЛЯ ИМЕНОВАНИЯ ПЕРЕМЕННЫХ (ЭКЗЕМПЛЯРОВ ОБЪЕКТОВ) В ЗАВИСИМОСТИ ОТ ТИПА

В целом, стандарты Borland не рекомендуют использование префиксов для обозначения типа в имени переменной. Имя должно быть выбрано таким образом, чтобы определить функциональную принадлежность переменной. При использовании InFixCaps допускается составление имен переменных таким образом, чтобы начальная часть имени переменной указывала на ее функциональное назначение, а завершающая (постфикс) часть содержала указание на тип. Например: DateEdit, CustomerQuery, ErrorList.

Однако опыт разработки свидетельствует, что использование префиксов для именования переменных является эффективным способом стандартизации кода и очень распространено программистами, в том числе, и работающими с Borland Delphi.

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

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

В том случае, если принято решение использовать префиксы, то для именования переменных (за исключением локальных переменных в простых процедурах и функциях) рекомендуется использовать запись с использованием нотации, построенной по следующему правилу:

  1. Удалите из имени компонента префикс Т. Например, TButton превращается в Button.
  2. Из полученного значения удалите все гласные буквы, за исключением первых букв слова. Например, Button превращается в bttn, a Edit превращается в edt.
  3. Удалите сдвоенные согласные буквы. Например, bttn превращается в btn.
  4. Если в результате возникает конфликт имен, возвращайте в полученное промежуточное значение гласные буквы— по одной, слева направо. Например, если появится новый компонент TBatton, его префикс типа войдет в конфликт с префиксом типа компонента TButton. Следовательно, для нового компонента следует установить префикс типа batn.

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

ПрефиксТип
Стандартные типы
iInteger
bbyte
blboolean
chchar
s, strstring
fDouble,Float, real
wword
ptrpointer
arrarray
recrecord
setset of ..
enumenumeration
dtmTDateTime
slTStringList
Стандартные компоненты
fmTForm
mmTMainMenu
pmTPopupMenu
miTMenuItem
pmiTPopupMenuItem
lblTLabel
edtTEdit
memTMemo
btnTButton
cbTCheckBox
rbTRadioButton
lbTListBox
cbbTComboBox
gbTGroupBox
rgTRadioGroup
pnlTPanel
clTCommandList
meTMaskEdit
dgTDrawGrid
imgTImage
sbxTScrollBox
clbTCheckListBox
splTSplitter
actlTActionList
actTAction
fntTFont
chtTChart
Win32
pgcTPageControl
tsTTabSheet
ilTImageList
reTRichEdit
tvTTreeView
lvTListView
hdrTHeaderControl
stbTStatusBar
tlbTToolBar
tbbTToolButton
Системные компоненты
tmTTimer
Компоненты доступа к данным
tblTTable
qrTQuery
spTStoredProc
dbTDataBase, TIBDataBase
crTCursor
trTTransaction
connTConnection
DSQLDSQL
ssnTSession
MIDAS
prvTProvider
cdsTClientDataSet
dcomTDCOMConnection
RX
deTDateEdit
fsTFormStorage

2.8. ИМЕНОВАНИЕ ГЛОБАЛЬНЫХ КОНСТАНТ

Для записи глобальных констант рекомендуется использовать префикс "cnst".

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

Правильно:
  cnstEvaluationMode = true;
  EVALUATION_MODE = true;

Неправильно:
  EvaluationMode (Со взгляда на переменную нельзя определить, константа это или нет)
  EVALUATIONMODE (Сложно прочитать)

2.9. ЗАРЕЗЕРВИРОВАННЫЕ СЛОВА

Зарезервированные слова и директивы должны быть все в нижнем регистре. Производные типы должны начинаться с большой буквы (Integer), однако string – это зарезервированное слово и оно должно быть в нижнем регистре.

2.10. ОБЪЯВЛЕНИЕ ТИПОВ И ЭКЗЕМПЛЯРЫ ПЕРЕМЕННЫХ ОПРЕДЕЛЕННЫХ ТИПОВ

Все объявления типов должны начинаться с префикса Т и должны придерживаться правил, приведенных при описании оформления модуля или описании оформления класса.

Экземпляры переменных должны получать имена, совпадающие с именами соответствующих типов, но без префикса Т. Например, имена экземпляров для типов форм будут иметь следующий вид:

Имя типаИмя экземпляра
TAboutFormAboutForm
TMainFormMainForm
TCustomerEntryFormCustomerEntryForm

2.11. ПЕРЕЧИСЛИМЫЕ ТИПЫ

Имена для перечислимых типов следует выбирать в соответствии с назначением перечисления. Имя типа должно начинаться с буквы Т, которая указывает на объявление типа. Список идентификаторов перечислимого типа должен содержать набранный строчными буквами двух или трехсимвольный префикс, указывающий на имя исходного перечислимого типа, например:

TSongType = (stRock, stClassical, stCountry, stAlternative, stHeavyMetal, stRB);

Экземплярам переменных перечислимого типа следует присваивать имена, совпадающие с именем типа, но без префикса Т (SongType), если нет причины назвать переменную более конкретным именем, например FavoriteSongTypel, FavoriteSongType2 и т.д.

2.12. СТРОКОВЫЕ РЕСУРСЫ

Все строковые ресурсы должны иметь вид "Rs"[Category][Name]. [Category] должно быть аббревиатурой или названием категории кода, где используется строка. [Name] должно быть именем строки ресурса. Например, конструктор TJclCriticalSectionEx.CreateEx вызывает исключительную ситуацию при ошибке инициализации. Сообщение об ошибке объявляется в глобальном модуле ХХXResources.pas с именем RsynchInitCriticalSection.

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

2.13. ИСКЛЮЧЕНИЯ

Все исключения должны начинаться с префикса EХХХ. Все исключения должны быть унаследованы от класса ENхError. При возбуждении исключительной ситуации предпочтительным является ее создание с помощью метода CreateRes:

raise EХХХSomeException.CreateRes(@RsSomeResourceString);

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

СОДЕРЖАНИЕ

Copyright © 2004 Вячеслав Колдовский   Специально для Delphi Plus