Когда с программой работает несколько человек или код слишком большой, то структурирование кода - не единственное, чего надо придерживаться. Очень важно правильно именовать переменные. Уже давно общепринятым стандартом является указание перед именем того, что указывает на тип переменной. Так, при программировании в Delphi принято все имена объектов начинать с буквы Т, а указатели с буквы Р.

При именовании переменных желательно, чтобы в имени было указание на их тип. Что именно вы будете указывать, зависит от личных предпочтений. Я опять же приведу несколько примеров сокращений из своей практики, которые вы можете увидеть в табл. 1.1. Если вы встретили какой-то тип. который неуказан в таблице, то можете придумать для него свое сокращение.

Таблица 1.1. Сокращения для указания типов

Тип

Сокращение

Целое число (integer)

i

Строка (string)

S

Массив (array)

а

Константа (const)

ct

Запись (record)

rd

Дробное число (real)

rl

Дробное число с двойной точностью (double)

dl

Слово (word)

wd

Двойное слово (dword)

dwd

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

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

Теперь вы должны определиться с тем, как записывать названия переменных. Как мы уже разобрались, они должны состоять из двух частей: идентификатора, указывающего тип, и смыслового названия. Допустим, что вам нужна строка для хранения имени файла. Так как это строка, то идентификатор будет иметь название s, а в качестве смыслового имени укажем FileName. Записать это можно по-разному, поэтому приведу несколько примеров:

sFileName : String: s_FileName : String: FileName_s : String;
s-FileName : String: _s_FileName : String:

В настоящее время я склоняюсь к использованию последнего варианта написания, хотя в разных проектах можно увидеть любой из них. Почему именно последний вариант? Потому что по знаку подчеркивания в начале можно сразу определить, что это переменная, а не имя метода, свойства, процедуры или объекта. Этот способ я взял из такого языка программирования, как PHP, где имя переменной должно начинаться со специального знака $. Таким образом, имя переменной отличается от имен процедур, функций и зарезервированных слов.

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

for i := 0 to 10 do В данном случае нет смысла выдумывать какое-то имя для переменной. Если вы встретили в коде переменную с именем i или j, то сразу можно понять, что это счетчик. Здесь уже действует правило: "краткость - сестра таланта".

Когда нужно написать свою процедуру или функцию, то для имени можно задать отдельный префикс Правда, я этого не делаю, потому что имена функций хорошо различимы и без дополнительных индикаторов. А вот имена для процедур нужно писать осмысленные. Тяжело понять в коде, для чего нужна процедура с и-менем Procl. Обязательно используйте такие имена, чтобы они отражали смысл выполняемых действий.

При именовании компонентов на форме у меня также нет определенных законов. Некоторые предпочитают ставить префиксы, а некоторые просто оставляют значение по умолчанию. Первое абсолютно не запрещается, главное, чтобы вам было удобно. А вот работать с компонентами, у которых имена Buttonl, Button2 и т. п., очень тяжело. Изменяйте имя сразу после создания компонента, иначе потом придется менять не только название, но и связанные части кода.

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

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

Для примеров и "одноразовых" утилит (программы, которые пишутся для выполнения единовременной работы) я очень часто отступаю от правил, потому что в таких кодах одна переменная может выполнять множество функций и сложно подобрать общие названия. В этом случае код переполняется переменными с именами типа Temp, Str, но меня это не смущает, потому что в будущем этот код использоваться не будет, и читать его не придется.

Для именования файлов тоже должны быть свои правила. Могу посоветовать выбрать одно из двух:

в перед именем файла ставить префикс и, если этот файл является модулем без визуальной формы. Перед именем файла ставить f, если в нем хранится визуальная форма;

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

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

Я больше люблю второй вариант с одним исключением - модуль, содержащий главную форму проекта, называется MainUnit.pas. Таким образом, какой бы проект я не рассматривал, всегда легко найти главную форму и необходимые файлы.

Старайтесь не хранить в одном файле несколько объектов. Лучше пусть будет несколько файлов, зато потом по их именам можно легко найти нужный объект.

Если какая-то процедура в программе является обработчиком события для компонента или формы, то ее предназначение легко понять по названию. Для создания имени процедуры, вызываемой в ответ на события, в Delphi используются название компонента и имя события. Например, у вас есть компонент с именем MainPageControl типа TPageControl, и вы создаете для него обработчик события OnChange, в этом случае название процедуры будет MainPageControlChange. Это очень удобно и если нет особой надобности в изменении имени, лучше его не трогать. В дальнейшем вы сможете почувствовать мощь и удобство такого подхода.

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

//////////////////////////////////////////////////// // ОПИСАНИЕ: расчет стоимости чего-либо // ПАРАМЕТРЫ: Для расчета нужны: // tCol - количество товара // iCost - цена товара

////////////////////////////////////////////////////
procedure CalcCostdCol. iCost:Integer):
begin
end.

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

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

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

1.2. Структурирование кода || Оглавление || 1.4. Базы данных


Delphi в шутку и всерьез: что умеют хакеры



Новости за месяц

  • Декабрь
    2021
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31