Вредные Советы

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

Сложные конструкции очень неудобны для отладки, может так случиться, что и смотреть в отладчике будет не на что.

Используя with statement надо четко представлять его правила интерпретации имен и помнить, что отладчик не всегда сможет показать поля и свойства внутри этого блока.

Смело вкладывай друг в друга
with и case и else/if
не выравнивай ты блоки
end пиши в случайном месте
Код быть должен как картинка
Нарисованый в ascii!

Всегда полагай, что деструктор обнулит все твои ссылки на объект.

Держатель ссылки должен сам заботиться о ее валидности. Для компонентов полезен механизм Notification.

При создании обьекта
Помни - пашет счетчик ссылок
Гадкий access violation
В OnException-е гаси!

Разбивай приложение на exe & dll и смело передавай между ними классы.

Надо помнить, что библиотеки являют собой рудиментарную форму технологии клиент-сервер, а с момента их появления прогресс ушел далеко вперед.

В любом случае, включить модуль в uses проще, чем сделать LoadLibrary.

Ну, и никаких классов в DLL, в случае острой нужды используйте BPL или COM вместо dll.

Больше файлов в приложеньи -
Круче, стало быть, программер
Выпуская обновленье
Из трех файлов сделай пять!

Создавай побольше потоков, заморочиваться же с Synchronize не стоит.

Использование дополнительных потоков следует тщательно планировать, ориентируясь, в том числе, и на количество процессоров целевой системы.

Обращение к VCL объектам должно идти через Synchronize. Нельзя впадать и в другую крайность.

    procedure TMyThread.Execute;
    begin
      while not Terminated do 
        Synchronize(DoWork)
    end;
          

Нарисуешь два потока -
и увидит глупый юзер
как ворочается цикл,
зависает интерфейс.
Но зато послать по аське
ты знакомой кодемонке
сможешь класс со словом thread
пусть завидует младой!

Почаще пользуй функции win32 API и никогда не вызывай Win32Check.

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

Обязательно анализируйте возвращаемый функцией результат в порядке, описанном в MSDN.

Если не хватает кода
Что те Борланд предоставил
Смело лезь к виндам в унутрь!
Там есть все что захотишь!
Подыщи api по смыслу,
С изучением не парься
Знают все - винда мудрит!
От слов handle, check и buffer
Будет мозга несваренье
Очень вредно на ночь чтенье
Глав из книг MSDN!

Используй дельфийские глобальные переменные формы FormX, и навсегда забудь Screen, Application, DecimalSeparator и прочие

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

Чаще используйте шаблоны, подобные следующему вызову модальной формы (удалите ее из списка Auto-create forms):

    with TFormX.Create(nil) do
    try  
      DoSomethingBeforeShow;
      case ShowModal of
        mrOk: DoSomething1;
        mrCancel: DoSomething2;
        ..
      end;    
    finally
      Free;
    end;
          

Другие же глобальные переменные: Screen, Application, Printer и другие, гораздо более полезны и стоят внимательного изучения. Например, для поиска форм всегда используйте Screen.Forms.

Очень умный компилятор
Нам не зря для каждой формы
Имя личное дает.
Их используй не стесняясь!
Создавая по три раза
Формы, имя не меняй!

Убогий TListBox (TDrawGrid, ..) замени парой десятков кнопок, Edit'ов.

Один контрол лучше десяти, внимательно относитесь к выбору контрола, наиболее приспособленного для требуемого действия.

Создавая объект X класса TX вызывай конструктор так: X.Create.

Очень распространенная среди начинающих ошибка.

Кроме того, вызов конструктора как метода может и не выполнить повторную инициализацию объекта, как то обещано хелпом. Смотри, например, TThread.Create

Не забывай вызов конструктора защитить секцией try-finally.

Обработку исключений конструктора оставляйте обработчику более высокого уровня.

    TClass.Create
    try
      ...
          

а не так

    try
      TClass.Create
      ...
          

Не думай, что исключение в конструкторе вызовет деструктор автоматом.

Всегда помните об этом поведении конструктора, особенно, при написании деструктора, то есть перед какими-либо действиями с полями-объектами убедитесь, что это поле не nil.

Функция, возвращающая объект круче его конструктора.

Такие функции сильно сбивают с толку. Проще всего придерживаться правила Т. Бульбы: ответственность за уничтожение лежит на создателе (если ему не удалось спихнуть ее, например, на Owner или Parent).

Похожее можно сказать и про функции(методы)-убийцы. Для большинства дельферов подобное поведение функции будет неожиданным.

Неплохо выглядит и функция, возвращающая PChar на распределенную ею строку.

Это тоже источник путаницы: необходимо ли освобождать память и кто за это отвечает.

Перебирать список лучше так:

             for i := 1 to List.Count
          

а символы String

             for i := 0 to 10
          

Распространенная ошибка.

По случаю напомним о Low, High

Записи из списка всегда удаляй в цикле for начиная с 0.

Распространенная ошибка, рекомендуется цикл for downto или while.

List index out of bounds - это фича, а не баг.

Значит, все таки, мы облажались.

Запомни, что типы PChar & String друг к другу не приводятся.

Конечно, приводятся, но, почему-то, начинающие на этом месте спотыкаются.

Заметим, что иногда полезно приведение Pointer(String), отличающееся от PChar(String) в случае пустой строки.

Неплохо помнить и про SetString.

Record с полями String весьма удобен для файлового ввода/вывода.

Неудобен, конечно. Требуются либо строки фиксированной длины, либо явное указание длины строки.

Не рисуй в PaintBox - это удобней делать на панели, столе, обоях и стенах.

У начинающих, почему то, часто возникает желание использовать контролы не по назначению.

Стремись представить разность дат в годах и месяцах и днях.

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