Самое первое, к чему я себя приучил, - писать структурированный код. Давайте посмотрим на пример кода (листинг 1.1). В нем представлен неструктурированный код, который записан сплошным текстом без выравнивания. Попробуйте теперь понять, что здесь происходит. Разобраться нелегко.

Листинг 1.1. Неструктурированный код

procedure TForml.ButtonlClick(Sender: TObject);
const tt=12;
var i-Integer;
b.Boolean;
begin
i:=1212*12;
if i>10000 then
begin
b.=true;
i:=1212*2;
if i<12 then
b:=false;
end
else
b:=false;
end;

Теперь посмотрите на новый код (листинг 1.2), где все оформлено по правилам.

Листинг 1.2. Структурированный код

procedure TForml.ButtonlClickCSender: TObject): const
tt = 12:
var
i: Integer;
b: Boolean: begin
i 1212*12; if i > 10000 then begin
b := true:
i := 1212*2;
if i < 12 then
b := false;
end else
b := false;
end:

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

После ключевых слов нет кода. Так, после слов const и var объявления перенесены на следующую строку. Стоит придерживаться этого правила при оформлении кода.

В разделе var и const каждый тип переменных объявляется в своей строке. Когда там будет много элементов, вам легче будет найти необходимый Если объявлений переменных несколько, то их можно оформлять следующим образом:

Index . Integer: b. t Boolean;
sum : Real:

В этом примере названия типов расположены на одном уровне, и объявления выглядят более приятно. Но как нарушается вид кода, когда переменных одного типа слишком много:

Index Integer: Name, Surname. Telephon. Address String;
b. t Boolean;
sum Real;

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

Index Integer;
Name. Surname.
Telephon. Address String;
b, t Boolean;
sum Real;

Разрывов меньше, но читабельность уже не та Именно поэтому я редко располагаю имена типов переменных на одном уровне. Когда приходится разбираться с чужим или давно позабытым кодом, то на переменные обращают внимание в последний момент. Чаще всего можно прямо по коду или префиксу (если имена переменных называют правильно) понять их типы Но об именовании мы поговорим чуть позже.

Помимо этого, весь код, относящийся к ключевому слову, пишется с отступом от края. Величину отступа вы должны выбрать сами. Некоторые ставят два-три пробела или используют для отступа клавишу Tab, а я применяю только один пробел. Это связано с тем, что когда слишком много вложенности ключевых слов begin, if и других, то смещение вправо получается слишком большим и неудобным, потому что часть скрывается за правой кромкой окна. В этом случае постоянно приходится перемещать прокрутку вправо-влево, чтобы увидеть код, не попавший в пределы окна.

После ключевого слова begin и до соответствующего end весь код сдвинут вправо на один пробел. Таким образом, вы легко можете увидеть, какой оператор end соответствует какому begi п.

После ключевых операторов if, while и repeat код также пишется только на новой строке и со смещением. Не надо пытаться все уместить в одну строку. Результирующая программа от этого меньше не станет, а вот понять происходящее во время отладки будет тяжело.

Как альтернатива моему методу оформления есть еще один, который вы можете увидеть в листинге 1.3.

Листинг 1.3. Структурированный код

procedure TForml.ButtonlClick(Sender: TObject). const
tt = 12;
var
i. Integer;
b: Boolean;
begin
i := 1212*12; if i > 10000 then begin b := true;
i := 1212*2, if i < 12 then b := false;
end else
b := false;
end;

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

Помимо этого, ключевое слово begin пишется в одной строке после операторов, таких как if, for, while и т.д. А ключевое слово end ставится на одном уровне с этим оператором begin. Такое оформление очень часто используется в языке программирования Java, но у него есть одно отличие - после операторов if не всегда ставятся begin и end.

Операторы begi п и end можно располагать и на одном уровне с і f:

if і > 10000 then begin
b := true:
і := 1212*2;
if і < 12 then b := false;

end Но, по-моему, смещение хотя бы на один пробел более наглядно

Даже не пытайтесь уместить все в одной строке. Просмотр кода по горизонтали отнимает время, и эти затраты абсолютно бесполезны. Например если в функции 10 параметров, то ее вызов можно написать так:

Имя_Функции(Параметр1, Параметр2.

ПараметрЗ.

...):

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

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

Листинг 1.4. Структурированный код

var
і: Integer: j: Integer;
begin
// Начальные значения і := 0; j := 1;
// Расчет і := 10*j+5: j := 20-И;

// Вывод результата

end:

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

Перед каждой частью стоит комментарий, который служит для понимания текста. Даже если какой-то код вы писали самостоятельно, через пару месяцев вспомнить, что и для чего делалось, будет очень тяжело. Умение программировать постоянно совершенствуется, и уже через полгода, возможно, вы будете писать код по-другому, потому что найдете более удобный способ оформления или именования переменных. Да и помнить все функции Windows API (application program-ming interface - программный интерфейс приложения) или VCL (Visual Compo-nent Library - визуальная библиотека компонентов) невозможно. Конечно же, при хорошем знании английского языка можно определить назначение по названию, но если вы называете свои функции Funcl, Func2 и т. д., то такой код без комментариев прочитать будет невозможно.

В любом случае комментарии на результирующий код не влияют, поэтому лишними не будут. Если какая-то из моих процедур состоит более чем из 10 строк кода, то я обязательно ставлю комментарии. Это помогает читать код даже через длительные промежутки времени и быстрее находить ошибки. Подумайте о будущем уже на этапе разработки программы.

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

Paraml:=Paraml+NetComonent.Count-Form.Wi dth;
Param2:=Form.Hei ght+Screen.Width/2*MAX_SELECT:

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

Paraml := Paraml + NetComonent Count - Form.wïdth;
Param2 := Form.Height + Screen Width / 2 * MAX_SELECT:

Согласитесь, что понять такие записи гораздо проще.

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

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

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

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

Недавно была украдена большая часть исходных кодов ОС Windows, и мне удалось увидеть некоторые части. То, что я видел, оформлено по одним и тем же законам, что позволяет любому программисту быстро включиться в работу. Я даже слышал, что за неправильное оформление программисты получают финансовые штрафы Я думаю, что это не шутка, потому что даже на российских предприятиях действуют подобные правила при разработке больших программ, в написании которых участвует несколько человек. Это правильное решение, и оно дисциплинирует программистов писать код правильно.

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

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

Представьте себе ситуацию, когда все производители памяти начали делать линейки памяти разного размера и формы. Каждый бы делал это эффективно и красиво, но в один и тот же разъем нельзя вставить разные линейки. Чтобы этого не было, придумали стандартизацию, когда основные участки все делают одинаково. Стандартизация - это не пережиток прошлого, это будущее всего мира. Если каждый будет тянуть в свою сторону, то мы не сдвинемся с места и получим эффект "лебедя,рака и щуки".

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

1.1. Правильное оформление кода || Оглавление || 1.3. Именование


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