Всем доброго времени суток!
Прежде всего спасибо тем, кто движимый любопытством, всё-таки решил подписаться на эту рассылку. Буду надеяться, что материалы этой рассылки окажутся для Вас полезными и поучительными. А если у Вас будут свои мнения и взгляды по тем или иным аспектам программирования в Delphi (и не только в Delphi) - милости прошу! Завязывайте дискуссии, делитесь опытом, задавайте вопросы, а то просто расскажите потешную историю. Для знакомства и общения Вы сможете воспользоваться чатом http://ChatWorld.ru/delpher. Сообщения и материалы, присланные на e-mail, будут публиковаться в рассылке.
Выпуск 2
Об использовании языка и роли комментариев
Всем известен афоризм Козьмы Пруткова насчет специалиста, подобного флюсу. Если раньше все специалисты по информационной технологии делились на программистов и операторов, то сегодня выделяется около полутора десятка специальностей, связанных с компьютером. Это, конечно же так: идет процесс расширения и специализации. Но позволю себе заметить, что в реальной жизни программистами часто называют людей, которые никак не связанны с разработкой программного обеспечения. Даже тех, кто занимается поддержкой аппаратуры и системы Windows в рабочем состоянии - и то называют программистами.
К сожалени в нашей стране, где IT-технология никогда не считалась наукой, а компьютерные программы - объектом охраняемого авторского права, многие склонны рассматривать эту деятельность как ремесло (наподобие плотника или слесаря-сантехника). Одной из причин подобного положения дел является широкомасштабное пиратство и общедоступность (бесплатность) компьютерных программ. У нас ни один бухгалтер не назовет стоимость эксплуатируемого в организации программного обеспечения и баз данных; в лучшем случае это будет отнесено к разряду "нематериальных активов". На "диком Западе", как мне рассказывал знакомый коллега, на предприятиях категорически запрещено использование "левых" программ: каждая прога, как и любая материальная ценноость, должна иметь документ о приобретении.
Во всем цивилизованном мире программист - это профессия, которая требует не только наличия диплома или сертификата, гарнтирующего у обладателя определенной суммы знаний, но и постоянного повышения квалификации. У программистов, в отличие от экономистов и юристов, нет регламентированной программы обучения, но для разработки программного обеспечения нужны качественная подготовка, фундаментальное образование и приобретенные навыки решения проблем.
Среди множества навыков, необходимых программисту, важную роль играет стиль программирования, касающийся использования языка Object Pascal. Общее правило гласит коротко и ясно:
«Используйте язык полностью».
То есть разработчику следует изучать и активно использовать возможности языка, и, прежде всего, возможности стандартных компонент, встроенных функций и процедур. Это правило может показаться сущей банальностью, граничащей с примитивизмом, если бы реальная практика не демонстрировала поразительные ляпы неполного использования языка.
Некоторое время назад, проссматривая исходый текст модуля, написанного коллегой по работе (девушкой-программистом), наткнулся на любопытный кусок кода, где приводился алгоритм определения числа суток между двумя датами. Поскольку эта простенькая процедура использовалась в программе неоднократно, то коллега оформила его в виде подпрограммы-функции. И вот как эта функция выглядела:
function DateDays(T1, T2: TDateTime): integer;
var
Year1, Year2, Month1, Month2, Day1, Day2: word;
T: TDateTime;
begin
Result := 0;
DecodeDate(T1, Year1, Month1, Day1);
DecodeDate(T2, Year2, Month2, Day2);
T := T1;
if (Day1=Day2)and(Month1=Month2)and(Year1=Year2) then
Result := 0
else repeat
Result := Result +1;
T := T+1;
DecodeDate(T, Year1, Month1, Day1);
until (Day1=Day2)and(Month1=Month2)and(Year1=Year2);
end;
Странно, но разработчик не нашел ничего лучше, чем просто просканировать в цикле repeat дни от начальной даты до конечной. К тому же две даты сравниваются на совпадение по номерам дня, месяца и года, и для этого пришлось использовать функцию DecodeDate для получения составляющих (число, месяц, год) значения типа TDateTime.
Несмотря на синтаксическую правильность кода, программист, как мы видим, не в ладах с типом данных TDateTime. Замечание о недопустимости подобного алгоритма вызвало сначала недоумение коллеги, а затем последовало возражение, что "ошибки здесь нет, потому что проверка показала правильность результатов". Великолепно! Тогда я предложил сделать проверку на случай, если по какой-либо причине вторая дата (T2) окажется меньше первой (T1). Понятно, что восходящее сканирование не даст результата и программа "провалится" в бесконечный цикл. Но и тут нашлось возражение типа того, что "в нашей задаче такого случая не бывает".
На самом деле задача решается без всякого цикла в два оператора:
function DateDays(T1, T2: TDateTime): integer;
begin
Result := 0;
if (T1 < T2) then
Result := Round(Int(T2) - Int(T1))
end;
Резюме к сказанному:
а) в Delphi значение типа TDateTime следует представлять себе прежде всего как вещественное число (например, типа extended или double), к которому применимы сответствующие операции. Нюанс в том, что в целой части числа хранится число дней, прошедших от определенной даты (это 30 декабря 1899 года), а в дробной - прошедшая доля текущего дня.
б) Программисты, которые полагают, что что их код совершенен, которые отвергают критику, вместо того, чтобы считать ее полезной, как правило, пишут тарабрщину - даже если кажется, что она работает. Таким программистам не мешало бы помнить правило: «В сообществе программистов нет места примадоннам».
Следующее простое правило касается одной очень полезной возможности, предоставляемой средой Delphi в отношении построения конструкций языка Object Pascal:
«Почаще вспоминайте и активно используйте сочетание клавиш Ctrl-J».
При нажатии Ctrl-J на экран выпрыгивает окошечко с перечнем реализованных стандартных структур языка Object Pascal. Вместо того чтобы набирать на клавише, например, if-then-else, достаточно выбрать из перечня соответствующий шаблон и затем подставить нужные тексты. При необходимости разработчик может пополнить набор наблонов. Для этого следует воспользоваться командой меню Tools | Editor Options и выбрать вкладку Code Insite.
В старые добрые времена структурного программирования каждый модуль рекомендовалось начинать с комментариев. В те времена модулем называли подпрограмму (т.е процедуру или функцию), которая компилировалась отдельно. Но и сегодня, когда под термином "модуль" в Delphi имеется в виду программная единица, содержащая различные элементы, в том числе и подпрограммы, это требование не устарело.
Общее правило использования комментариев можно сформулировать так:
«В Delphi каждый модуль и подпрограмма должны начинаться с комментариев».
Лично я для этого использую следующую форму комментария:
//**********************************************
//* Этот текст располагается перед заголовком
//* модуля или подпрограммы и описывает пред-
//* назначение модуля, процедуры или функции.
//**********************************************
В этом случае содержание модуля хорошо просматривается и делается более прозрачным. Такой комментарий желательно оформить в виде шаблона и затем вызывать клавишами Ctrl-J.
Остальные не заголовочные комментарий рекомендуется размещать справа от кода, чтобы просмотр текста подпрограммы не прерывался комментариями. При этом комментариев не должно быть слишком много, ибо они создают впечатление засоренности. Они нужны только там, где это необходимо.
Можно смириться и понять, когда программист не использует комментариев, если программа создается для своих нужд и нужд своих друзей. Но для целей промышленной эксплуатации код без комментариев таит в себе большие неприятности, связанные с сопровождением. К сожалению, некоторые руководители подразделений и даже программисты не совсем понимают термин "сопровождение" и часто путают его с "эксплуатацией". На самом деле
Сопровождение - это деятельность, направленная на исправление недостатков или последовательное улучшение программы в процессе эксплуатации.
Можно считать общепризнанным, что программист, бысто пишущий некомментируемый, хотя может быть и элегантный, код, слишком дорого обойдется предприятию. Фактически он создает не компьютерную программу, а бомбу с часовым механизмом. По истечении некоторого времени другому программисту придется либо потратить на сопровождение такой программы в 10 раз больше времени, либо написать ее заново.
Под занавес этого выпуска позволю привести отрывок из книги Аллена И.Голуба «C&C++. Правила программирования».
Компьютерное программирование является индустрией обслуживания
Меня иногда шокирует неуважение, проявляемое некоторыми программистами по отношению к пользователям своих прогроамм, как если бы "пользователь" (произносится с презрительной усмешкой) был низшей формой жизни, неспособной к познавательной деятельности. Но факт состоит в том, что весь компьютер существует лишь с одной целью: служить конечному пользователю наших продуктов. Если никто бы не пользовался компьютерными программами, то не было бы и программистов.
Печальным фактом является то, что существенно больше половины из ежегодно разрабатываемого кода выбрасывается за ненадобностью. Такие программы или никогда не поступают в эксплуатацию, или используются лишь очень короткое время, после чего выбрасываются. Это означает невероятную потерю производительности, сокращая для большинства управленцев реальные среднесуточные цифры выработки. Подумайте о всех начинающих фирмах, выпускающих программы, которые никогда не будут проданы, о всех группах разработчиков, пишущих бухгалтерские пакеты, которыми нельзя воспользоваться.
Легко увидеть, как возникает эта печальная ситуация: программисты создают программы, которые никому не нужны. Исправить ее тоже легко, хотя в определенном окружении это и сталкивается с неожиданными трудностями: спросите людей, что им нужно, и затем сделайте то, что они вам сказали.
К сожалению, многие программисты производят впечатление лиц, полагающих, что конечные пользователи не знают чего хотят. Вздор. Почти всегда пользователи оказываются так запуганы сыплющим специальными терминами «экспертом», что замолкают. Мне часто говорили: «Я знаю, что мне нужно, но не могу это выразить». Лучший ответ на это: "Отлично, скажите это на нормальном языке — я сделаю перевод на компьютерный".
