SASGIS

Веб-картография и навигация

SAS.Wiki

Веб-картография и навигация

Инструменты пользователя

Инструменты сайта


sasdev:соглашения_по_исходному_коду

Это старая версия документа.


Главная страница

Соглашения по исходному коду

Именование файлов

В именах юнитов с исходным кодом приняты следующие префиксы:

  • c_ Юниты в которых объявлены только константы
  • t_ Юниты в которых объявлены только простые типы (Record, Enum и тд)
  • i_ Юниты в которых объявлены только интерфейсы
  • fr_ Юниты в которых объявлены фреймы (Наследники TFrame)
  • frm_ Юниты в которых объявлены визуальные формы
  • u_ Все остальные юниты, не подходящие под предыдущие префиксы

Форматирование кода

Блоки Uses

Название каждого юнита с новой строки примерно в таком порядке:

  • Системные юниты (SysUtils, Types и тд.)
  • Юниты библиотек (GR32, KAZip и тд.)
  • Юниты программы:
    • Юниты в которых объявлены только константы
    • Юниты в которых объявлены только простые типы
    • Юниты в которых объявлены только интерфейсы
    • Обычные юниты с кодом
    • Юниты в которых объявлены фреймы
    • Юниты в которых объявлены визуальные формы

Идентификаторы

В именах типов, классов, методов, переменных, параметров и тд. Нужно использовать CamelCase. Сразу за именем переменной должно стоять двоеточие, потом пробел, потом имя типа. Пример: VOperationID: Integer;

Желательно использовать префиксы:

  • T Имя класса
  • I Имя интерфейса
  • V Локальная переменная функции (Без префикса можно использовать простые счетчики: i, j и тд. но желательно не увлекаться)
  • F Поле класса
  • A Параметр функции
  • C Константа

Форматирование кода

Желательно что бы ширина строчек кода не превышала 80 символов.

Необходимо соблюдать отступы.

Пробелы перед запятой или точкой с запятой недопустимы.

После запятой должен быть пробел.

Операторные скобки begin/end обязательны.

begin располагается на той же строчке, что и операция к которой он относится.

end располагается на новой строчке с тем же отступом, что и команда к которой он относится

Пример кода:

      if FDataRecived then begin
        VDataRecived := True;
        FDataRecived := False;
      end else begin
        if FLastDataReceiveTick > 0 then begin
          if FLastDataReceiveTick > VCurrTick then begin
            FLastDataReceiveTick := VCurrTick;
          end else begin
            VTickDelta := VCurrTick - FLastDataReceiveTick;
            if VTickDelta > VNotDataTimeout then begin
              FGPSRecorder.AddEmptyPoint;
              FGpsTrackRecorder.AddEmptyPoint;
              VDataRecived := True;
            end;
          end;
        end;
      end;

Закомментированный код зло и должен быть удален до коммита.

Общие идеи

Весь функционал максимально прячется за интерфейсами. Это дает такие преимущества:

  • Управление временем жизни объектов при помощи автоматического подсчета ссылок.
  • Интерфейсы можно передавать между границами DLL (Например в плагины и из плагинов), а обычные делфовские объекты нельзя. Пока далеко не все классы имеют интерфейсы и это тормозит появление плагинов.
  • Имея интерфейс, мы можем делать его реализации совсем не связанными между собой.

В интерфейсах нельзя использовать делфовских классов. То есть, если нам нужно возвратить или получить просто бинарные данные, то нужно использовать не TStream, а интерфейс IBinaryData (Сейчас есть пару исключений самое главное TCustomBitmap32, но это временно). Это же касается делфовских динамических массивов, объявленных как array of По возможности в интерфейсах нужно избегать использования указателей. Использовать их стоит только если это действительно оправдано.

Перевод этой страницы: