Сегодня я хотел бы поделиться с Вами не листингами программ и даже не идеями по написанию приложений, а скорее советами, которые необходимо соблюдать начинающим программистам, чтобы их программы вызывали восторг не только у пользователей, но и у тех, кто будет изучать программный код (прошу не путать со взломщиками программ). Да и в принципе эти же советы будут полезны самим программистам, так как в итоге «из-под пера» будет выходить понятный и легко читаемый код, а это немаловажный момент при «реанимации» старых идей. Кстати, эти же рекомендации будут полезны не только программистам, пишущим на Delphi, но и тем, кто занимается написанием программного кода на других языках: php, C++ и т.д.
Рекомендации к оформлению кода
Отступы.
Больной вопрос, наверное даже для некоторых опытных программистов. Для организации отступов рекомендуется использовать по 2 пробела для каждого уровня. Не рекомендуется использовать символы табуляции, т.к. пользователи могут по-разному установить параметры табуляции и реальная ширина отступов будет различной.
С проблемой отступов я столкнулся в своем блоге, когда размещаемый в посте листинг при публикации поста напрочь терял свою читабельность из-за того, что все отступы пропадали. Сейчас вроде бы проблема решена.
Ширина поля
Устанавливайте ширину поля равной 80 символам. Исходный текст должен укладываться в указанную длину строки — за исключением ситуаций, когда необходимо закончить слово. Если инструкция занимает несколько строк, то продолжение на последующих строках оформляется с помощью отступа, равного двум символам.
Дело в том, что при установке ширины поля более 80 символов Вы рискуете с толкнуться с большими проблемами при распечатке листинга программы — часть текста просто не войдет на лист формата А4.
Блок begin…end (операторные скобки)
Инструкция begin занимает отдельную строку. Исключение — когда begin оказывается частью предложения else. Т.е. else begin можно записывать в одной строке. Инструкция end занимает отдельную строку. Если инструкция begin не является частью предложения else, то соответствующая ей end занимает тот же отступ, что и begin.
Поясню на примере. Вот так писать не правильно:
procedure MyProc; begin writeln('HelloWorld') end;
Операторные скобки должны располагаться на отдельных строках, т.е. правильно писать следует так:
procedure MyProc;
begin
writeln('HelloWorld')
end;
По поводу связи с конструкцией if…then…else. Не правильный код:
procedure MyProc;
var ...
begin
if i=1 then writeln('HelloWorld') else begin
i:=i+1;
j:=j+1
end
end;
Как видите, несмотря на то, что else и begin стоят рядом, end не имеет того же отступа, что и begin и, соответственно читабельность кода снижается.
Более правильно было бы оформить представленную конструкцию так:
procedure MyProc;
var ...
begin
if i=1 then writeln('HelloWorld') else begin
i:=i+1;
j:=j+1
end
end;
Как видите, все отступы соблюдены и код становится на порядок понятнее.
Круглые скобки
Между открывающей скобкой и следующим символом не должно быть пробела, как и между закрывающей круглой скобкой и предыдущим символом.
Например:
MyProc ( param ) //неправильно - лишние пробелы MyProc (param) //правильно
Также не следует использовать круглые скобки без необходимости.
Например, не стоит использовать круглые скобки вот в такой конструкции:
if (i=1) then
т.к. проверяется всего одно условие и Delphi вполне прекрасно его поймёт. Другое дело, когда круглые скобки крайне необходимы, например при проверке нескольких условий:
if (i=1) or (j=1) then
Если не поставить скобки, то, согласно приоритетности выполнения операций в Delphi, условие будет интерпретировано неверно.
Ключевые слова
Зарезервированные ключевые слова должны записываться строчными буквами:
begin //верно BEGIN, Begin //неверно
Согласитесь, что правильное написание делает программный код более изящным?
Присвоение имен
Имена подпрограмм должны начинаться с прописной буквы. С прописных букв следует начинать составные части имен:
procedure mysuperproc; //не верно procedure MySuperProc; //верно
Как видите, название второй процедуры будет более понятно и Вам и стороннему программисту. Также значительно сокращается время на то, чтобы разобрать само название.
Идентификаторам, процедурам, функциям и параметрам процедур и функций следует присваивать имена, отражающие их назначение:
procedure FormatHardDrive; //сразу понятно, что это за процедура :) var IsNull: boolean; //признак нуля
Исключением из правила можно считать, например имена переменных для организации циклов. Обычно такие переменные именуются как: i, j, k и т.д.
Названия типов, которые являются зарезервированными словами, должны быть полностью написаны строчными буквами. Типы Win API полностью пишутся прописными буквами. Другие имена типов должны начинаться с прописной буквы, кроме того, с прописной буквы должны начинаться составные части имен. Пример:
var MyString: string;//составное имя WindowHandle: HWND;//тип Win API I: Integer; //счётчик цикла
Имена перечислимых типов следует выбирать в соответствии с назначением перечисления. Имя типа должно начинаться с буквы T, подсказывающей пользователю, что идентификатор является типом. Список идентификаторов перечислимого типа должен содержать набранный строчными буквами двух- или трехсимвольный префикс, указывающий на имя перечислимого типа. Например:
TSongType = (stRock, stClassic, stPop, stAlternative); //обратите внимание на префикс
Если при описании типов не использовать рекомендацию, то в итоге, могу дать гарантию, что через месяц, открыв программу вы не сможете с точностью определить, что перед Вами написано: простая переменная или её тип.
Параметры
Формальные параметры одного и того же типа следует по возможности объединять в одну инструкцию:
procedure MyProc(Param1, Param2: Integer; Param3, Param4: string);
Порядок следования параметров имеет важное значение, если используется соглашение о вызове fastcall. Параметры, используемые часто, должны следовать в начале списка, редко используемые – в конце. Более общие параметры следует размещать перед параметрами узкого назначения в порядке слева направо. Если значения параметров не модифицируются подпрограммой, то их следует помечать зарезервированным словом const. При этом, в случае если тип параметра запись, строка (ShortString), массив или интерфейс, будет сгенерирован более оптимальный код. Если параметр предназначен ТОЛЬКО для передачи значения из подпрограммы, то его следует помечать зарезервированным словом out.
При использовании двух модулей, содержащих подпрограммы с одинаковым именем, всегда предваряйте вызовы таких подпрограмм именем соответстующего модуля:
SysUtils.FindClose(SR); // или Windows.FindClose(Handle);
Типы
Тип Real использовать не рекомендуется, т.к. он оставлен лишь для обратной совместимости (есть такой тип данных с плавающей точкой в Pascal). Для работы с данными в формате с плавающей точкой лучше использовать тип Double. Этот тип является форматом данных, определенным стандартом IEEE для представления чисел с плавающей точкой. Тип Exteneded следует использовать только в тех случаях, когда точности предоставляемой типом Double, недостаточно. Типы данных Variant и OleVariant рекомендуется использовать только для COM-ориентированных задач.
Использование библиотек
Разрешается пользоваться всеми модулями, входящими в комплект поставки Delphi. Библиотеками сторонних производителей пользоваться не рекомендуется.
Компиляция
Исходные тексты подпрограмм ДОЛЖНЫ компилироваться без ошибок, предупреждений и подсказок компилятора! Следует по возможности избегать переключения опций компилятора (как то: контроль границ диапазонов, контроль ошибок ввода/вывода) в исходном тексте ваших подпрограмм. Разрешается использовать директивы условной компиляции для предопределенных символов: VER130, WIN32, CPU386, CONSOLE и т.п.
Использование визуальных компонентов сторонних производителей
Не рекомендую использовать сторонние компоненты в своих приложениях, т.к. в случае переноса своих исходников на другую машину Вам придётся носить с собой все эти компоненты и включать их в Delphi. Также может возникнуть риск утери одного из компонентов и тогда программный код потребует серьёзной переработки.
Вот такие советы и рекомендации хотелось бы дать начинающим программистам. Пользоваться или нет этими советами — решать Вам, но все-таки изящность программы «изнутри» довольно немаловажный фактор, определяющий Вас как профессионала.
В следующей части я расскажу про оформление кода в плане защиты от непредвиденных ситуаций и ошибок. Так что подписывайтесь на RSS и следите за обновлениями.