Статьи о Delphi

Как написать программу

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

Беру я в руки карандаш…

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

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

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

…им я линию веду

Карандаш, я думаю, ты еще не убрал в надежде на компьютер? Если нет — готовь новый лист бумаги, иначе — ищи по новой карандаш и опять же бери бумагу.
А вот теперь разберем по косточкам каждую придуманную тобой (или не тобой) фичу. Нет, код на бумаге можно целиком не писать, но изобразить блок-схему — обязательно. По ней сразу будет видно, как работает этот участок кода. Если возникают затруднения, не надо все бросать. Можно:

   а) пойти к знакомому за советом;
   б) найти ответ в Интернете;
   в) обратиться к справке или учебнику.

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

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

Когда схема нарисована, отдельные моменты нужно прописать кодом, указав, что это такое.

Кодируем

Теперь переходим к следующему этапу — написанию собственно кода. Реализация программы средствами языка тоже имеет ряд аспектов, мимо которых не следует проходить. Главная ошибка, которую делают начинающие программисты — это неправильное именование функций, переменных, констант. Я тоже этим и от этого страдал, поэтому просто обязан предупредить других. Обычно в самом начале даешь переменным имена из одной буквы: a, b, c, и так далее. Согласитесь, когда переменных набирается много (а это происходит довольно быстро) становится просто нереально вспомнить, что такое «а», а что — «с». Поэтому в первую очередь давайте переменным и константам “говорящие” имена: например Version — содержит версию программы, а Index — хранит в себе какой-то номер.

Обратите внимание, что я написал имена переменных с большой буквы. Это было сделано специально для улучшения читабельности кода. Аналогично следует поступать с функциями и процедурами. А вот здесь краткость совсем ни к чему. Пусть название процедуры будет длинным, зато будет понятно, для чего она. Например, понятно, что функция WSAGetLastError возвращает последнюю ошибку. Следует также каждое слово при слитном написании начинать с заглавной буквы. Сравните с таким вариантом: wsagetlasterror.

Теперь мне следует сделать важное замечание. Все, что было мной изложено в этом разделе, можно безболезненно применять в среде Delphi. Такие языки, как С++, чувствительны к регистру, и если вы поступите так, как я советовал, компилятор выдаст ошибку.

Теперь о менее важном. Всегда делай в коде комментарии. Они помогут тебе вспомнить, что и где ты делал (или помогут понять ход твоих действий другому, если, например, ты работаешь в команде). В комментариях же следует делать для себя пометки типа {Здесь надо найти ошибку} или другие. Не следует бояться, что от комментариев размер конечного «экзешника» сильно вырастет, потому как многие компиляторы просто удаляют их из текста программы. И еще одно. Как я уже говорил, следует часто встречающиеся участки кода выделить в отдельные функции. От этого выиграют все: уменьшится “вес” программы, облегчится поиск ошибок и отладка. А когда в тексте программы наберется слишком много функций, их можно перенести в отдельную библиотеку (кто не понял — DLL). О преимуществах все уже сказано.

Юзабилити

И еще раз о внешнем виде. Поменьше оригинальничай. Запомни, что в M$ сидят совсем не дураки, как многие считают (каюсь, сам грешен), поэтому не надо на каждом шагу вставлять прозрачные окошки невозможных форм и такие же невозможные кнопки только потому, что ты это умеешь. Дизайн всей Windows тщательно продуман, поэтому не будем изобретать велосипед.

Заключение

Надеюсь, что данным трудом я хоть немного пролил свет на некоторые аспекты написания качественной программы. Хочу сказать, что главное в нашем деле — практика. Можно прочесть тысячи страниц текста, но без применения эти знания будут лежать мертвым грузом. Несколько ссылок: www.delphimaster.ru, www.delphikingdom.ru, www.torry.net (ОГРОМНАЯ база компонентов и модулей для Delphi), www.borland.com (если интересна работа с сетевыми функциями при помощи API).

Буду рад, если люди с кривыми руками смогут их выпрямить, следуя некоторым моим советам. Все они необходимы по-своему, проверено на себе. Удачи!

По материалам сайта Новый Мегабайт

В начало