Программирование для начинающих от CompDocs - 5
Перед тем как начинать изучать более сложные понятия, нужно знать хоть что-то о упрощении как самой программы, так и ее читаемости для людей. Об этом мы сегодня и поговорим.
Прежде всего, это, конечно же, комментарии к коду. Комментарий - это любая текстовая информация. Вы можете добавлять сколько угодно комментариев. Они служат исключительно для более быстрого понимания/вспоминания кода человеком. Конечно, такие небольшие программы, что мы писали их до этого, можно не то что не комментировать, их можно просто написать в одну строчку и запомнить :). Но вот когда начинаешь писать более-менее крупную программу, там уже возникают проблемы. Если по ходу дела еще кое-как ориентируешься, то стоит оставить разработку даже на неделю, как, вновь принявшись за работу, программист уже чувствует себя неудобно - приходится заново подолгу вспоминать длинный код: что это такое, а зачем эта переменная, а где тут это и т.д. Другое дело, если написаны комментарии. Такая же ситуация и с чтением кода другого программиста - без комментариев пройдется читать (и осмысливать ее смысл :)) чуть ли не каждую строчку кода, чтобы понять принцип работы или изменить что-то. В общем, чую, вы уже уверены на 100% в надобности комментариев. Тогда, собственно, следует отметить, что комментарии бывают двух типов: однострочные и много строчные. Суть их, я думаю, ясна: специальными зарезервированными словами - идентификатором комментариев, мы даем понять компилятору, что далее идет комментарий - в случае если это команда однострочного комментария, то все что стоит после него в данной строке является комментарием; у многострочных комментариев есть два зарезервированных слова: начало и конец комментария, все что находится между ними, интерпретируется компилятором как комментарий. Надо отметить, что даже если в комментарии присутствуют Pascal код программы, он считается как комментарий. Одним словом, как я уже говорил - все что за или (в зависимости от типа - многострочный / однострочный) - комментарий. Вообще-то в классическом Паскале доступны только многострочные комментарии (их можно использовать для комментария и в одну строку, просто приходится дописывать закрывающий код комментария), но, так как мы изучаем не столько паскаль, сколько программирование, я не мог не упомянуть и двух типах комментариев. Ну, а в Паскале, многострочный комментарий осуществляется с помощью зарезервированных слов { и } или же (* и *) - кому как больше нравится. Пример использования комментариев:
{программа - пример использования комментариев это пример
классического многострочного комментария если бы написали
этот текст без символов комментария, то при компиляции
программы, компилятор вывал бы ошибку синтаксиса}
var
i : integer; {переменная цикла}
n : byte; {количество чего-то там :)}
color : word;{цвет для того-то...}
begin
(* начало программы, сейчас будем делать то-то... ну и т.д. ...*)
end.
Обратите внимание, что если не поставить закрывающее слово комментария, комментарий закомментирует все что за ним, даже код программы. Чтобы убедиться в этом, попробуйте в вышеуказанном коде удалить символ конца комментария - } в первом комментарии.
А теперь представьте, что вы увидели вышеуказанный пример, только без комментариев. И давай догадываться для чего там какая переменная - это можно сделать порой только изучив весь код программы, где применяется эта переменная. А так, только посмотрел - уже все ясно. Фактически, пишется две программы: одна в виде кода на языке программирования, вторая в виде смыслового описания, на человеческом языке. Вторая и есть комментарием. А каким бы хорошим программистом не был бы человек, он прежде всего человек и человеческий язык для него всегда будет понятней (ну, в редких исключениях - отшельники не в счет ;)).
Второе, что можно отметить из средств по улучшению читаемости кода человеком, является форматирование. Под форматированием мы будем понимать выделение строк кода путем отступа от левого края. Для форматирования можно использовать либо символ пробела, либо символ табуляции. Один символ табуляции по длине равен восьми символам пробела. Синтаксис Паскаля, как и других многих языков программирования, позволяет разработчику использовать эти два символа форматирования кода в любых количествах. Т.е. вы можете ставить хоть по 100 пробелов или табуляций в начале строки. То же можно делать и между операторами и операндами. Только учтите, что разделять символы самих операнд или операторов не в коем случае нельзя. Например, следующая запись:
i := a*b + sqrt(c/15-d) - sqr(e*f*g/pi) + sin(12*h) * cos(12*g);
синтаксически является корректной и читается легче, чем та же запись, но без пробелов:
i:=a*b+sqrt(c/15-d)-sqr(e*f*g/pi)+sin(12*h)*cos(12*g);
однако, как я уже говорил, ни операнды, ни операторы (впрочем, как и все другое, например имена процедур или функций) ни в коем случае разделять символами форматирования нельзя! Например, следующая запись является синтаксически некорректной:
i := a*b + s q r t (c/15-d) - s q r(e*f*g/p i) + s i n(12*h) * c o s(12*g);
Ошибки я выделил жирным шрифтом. Ну, думаю понятно, что s i n это просто три буквы, через пробел. Что это может быть? Возможно какие-то процедуры или переменные, но уж никак не функция sin. В общем, думаю понятно, что смысл предложения не поменяется от того, если между словами ставить больше пробелов. А вот если пробелы добавлять в сами слова, тогда уже выйдет ерунда...
Как применять форматирование - дело ваше. Я вообще, форматирование, в отличии от комментариев, почти не применяю, в отличии от многих других программистов. Мне достаточно четко оформить блок объявление переменных. Напрмаер, так:
var
i : integer;
n : byte;
color : word;
Также в виде исключений, в случаях, когда присутствует множество зонных кодов, например что-то типа такого:
for i:=1 to 10 do
begin
a:=i*b+15;
c:=i*a-15;
d:=a+c;
for j:=1 to d do
begin
r:=round(j*i*pi);
if (r > (100*j+100*i)) OR (r < (100*j-100*i)) then
begin
g=r;
inc(j);
inc(i);
end
else
begin
dec(j);
dec(i);
end;
end;
end;
За смысл данного кода не отвечаю :). Набирал я его совершенно спонтанно. Цель одна - показать, что так его воспринимать намного легче, чем так:
for i:=1 to 10 do
begin
a:=i*b+15;
c:=i*a-15;
d:=a+c;
for j:=1 to d do
begin
r:=round(j*i*pi);
if (r > (100*j+100*i)) OR (r < (100*j-100*i)) then
begin
g=r;
inc(j);
inc(i);
end
else
begin
dec(j);
dec(i);
end;
end;
end;
... когда все в куче. Кстати, оставлять begin и end; у начала строки это чисто моя идея (идея @ Путяк Владислав =) гы-гы-гы). А если серьезно, я нигде не встречал такого типа форматирования, применяющегося в программе или примере для Паскаля: ни в многочисленных прочтенных книгах, ни в исходниках или статьях... А зря, в отличии от наиболее традиционного (волнового, когда течение сменяет инкремент отступного форматирования строки декрементом и наоборот) типа форматирования кода в Паскале, примерно такого:
for i:=1 to 10 do
begin
a:=i*b+15;
c:=i*a-15;
d:=a+c;
for j:=1 to d do
begin
r:=round(j*i*pi);
if (r > (100*j+100*i)) OR (r < (100*j-100*i)) then
begin
g=r;
inc(j);
inc(i);
end
else
begin
dec(j);
dec(i);
end;
end;
end;
Как по мне, в моем способе форматирования зависимые блоки кода видны лучше не только благодаря выделению begin и end;, которые, к стати, в волновом форматировании найти столь же не просто, сколь и при отсутствии форматирования (имеется в виду не просто сами слова, а их зависимые пары), но и благодаря равному отступу зависимых блоков.
Как применять форматирование - дело ваше, как вам удобнее. А мы продолжим.
Продолжая тему улучшения читабельности путем чисто визуальных изменений кода, затронем имена переменных. Прежде всего, посоветовал бы вам давать нормальные имена переменных, а не какие-то a, b, c, d... В идеале, само имя переменной должно говорить ее предназначение. Например, переменная с именем BorderColor у людей, хоть немного разбирающихся в терминах ПК (или просто хоть немного знающих английский ;)) сразу поймут, что данная переменная служит для не ясно чего точно (как я сказанул, а? сразу поймут что... :)), но! Можно с точностью говорить о том, что данная переменная указывает на цвет какого-то бордера (т.е. бордюра, но не того что на тротуаре, а того, что например, по краям окон). А вот ее, пусть даже сокращение типа BC уже ни о чем не говорит. В крайнем случае, можно применять устоявшиеся аббревиатуры, например BrdrClr или BrdCol. Хотя новички не поймут, а многие могут перепутать Clr с командой CLR (CLear sCreen - очистить экран, зону, а в случае с BrdrClr - выходит очистить бордюр), а Col можно спутать с Collapse - шириной бордюра. Одним словом, не поленитесь набирать несколько лишних символов, дав имя переменной - это не тяжело, зато понимать значение переменных вам будет намного легче.
Еще один метод улучшения восприятия переменных - эти добавленных суффикса или постфикса. Предположим, есть переменная с именем Title (заголовок, например окна - верхняя, обычно синяя полоска в окнах Windows). Но что именно можно подразумевать под этой переменной? Имя заголовка, его координаты, размеры, цвет...? Часто для облегчения этой, а также некоторых других задач, а также чтобы немного сократить имена переменных используют суффиксы или постфиксы. По сути, это просто имя переменной, модифицированное одним или несколькими символами и отделенными символом "_". Например, чтобы ясно понять, что Title это именно текст заголовка, можно назвать эту переменную с применением суффиксов: s_Title или постфиксов Title_s. В данном случае, ставка идет, конечно, на тип переменной - string - строковая переменная - тут уж ясно, что это не цвет и не координаты, задающиеся числом. Хотя, можно просто дать переменной более широкое имя, например TitleText. Кому как больше нравится. Также, в отдельных случаях, можно быстрее ориентироваться в пределах переменных, например, имея два имени summa_i summa_l, программисту сразу ясно, что второе из них может хранить большее число - типы переменных integer и longint.
В заключении, хочу поведать о опять так, своей маленькой инновации. Называю я ее сферой переменных. Применяя в именах отображение сферы применения переменных, мне намного легче ориентироваться даже в сокращенных именах - просто количество переменных сразу визуально уменьшается и становится легче все помнить :). Под сферой я подразумеваю четкое выделение имени переменной специальными символами. К сожалению, чем длиннее имя переменной, тем меньшее воздействие имеет сфера, так что ее стоит применять в переменных с именем, пожалуй, не более чем в 5 символов. Хотя, применяя сферы в специфических местах кода, я всегда отказываюсь от длинных, понятных имен переменных в пользу сфер - в тех случаях, когда переменных не очень много и область их применения ограничена. Так, например, для обозначения переменных, служащих для передачи информации между различными модулями программы, иногда - процедурами или даже между отдельными программами, а также, в веб-программировании, к именам переменных для передачи данных между скриптами, я добавляю символ "_" в начало имени переменной. Таким способом, имея переменную с именем, например _id, я чётко знаю, что эта переменная была передана из другой части кода. Вообще, такой метод названия переменных зародился у меня, видимо после частого применения стандартных PHP-совских массивов $_POST, $_GET и т.д. Есть у меня и множество других типов сфер. Например, увидев переменную с именем, обрамленным символом "_", типа такого: _Title_ я сразу понимаю, что она служит для визуализации и ее содержание будет непосредственно отображено в результате выполнения кода. В частности, исходя из ее имени в примере, я могу сразу, не глядя в код, сказать, что использую я ее для отображения текста заголовка окна. Вот так вот... =)
Продолжение следует. Если не хотите забыть скачать новый выпуск CompDocs, подпишитесь на наши рассылки, формы для подписки на главной странице.
В следующий раз мы также поговорим о упрощении восприятия кода. Точнее закончим наш разговор на эту тему, по крайней мере, на ближайшее будущее, рассмотрев вторую часть темы. Но это уже будет не визуальное оформление кода, а что ни есть, самое настоящее изменение кода, применение различных конструкций и методов для улучшения его восприятия человеком.
Ссылки по теме:
Модуль Timer для Паскаля и не только
Как я стал полиндромомФункции API (часть I): функции вызова диалоговых оконBorland Kylix 2Delphi HotKeys - горячии клавишыРабота с буфером обмена в DelphiРабота с Jpeg-изображениями в DelphiПрограммирование для начинающих от CompDocs - 1Программирование для начинающих от CompDocs - 2
|
Версия для печати [доступна только on-line]