You are here: Foswiki>Gnumed Web>NamingConventionsRu (20 Mar 2013, IvanLykov)EditAttach

Соглашения по именованию

имена файлов

  • для файлов кода python используйте gm*.py и CamelCase, eg. gmDocumentWidgets.py
  • для сценариев SQL в начальном загрузчике используйте vXX-schema-table|view_name-dynamic|static.sql, скажем v16-dem-v_basic_person-dynamic-sql, где vXX ссылается на бау данных, в которую этот сценарий входит
  • не дублируйте имена файлов
  • поместите вверху каждого файла строку регистрации, указывающую его предназначение

код

  • начинайте имена класса с c, с последующим CamelCase, подобно cAllergyState
  • начинайте имена класса singleton с "gm", используйте CamelCase, подобно gmCurrentPatient
  • используйте нижний регистр + подчеркивание для методов, переменной и др., подобно method_foo() или allergy_status
  • используйте метод speaking и имена переменных (аллергия = ... вместо а = ...)
  • и следуйте этим рекомендациям для значимых имен
  • пишите код на английском для кодирования, но переводите для отображения (используя в строках _())

база данных

  • в табличной схеме базы данных
    • pk для первичных ключей
    • fk_* для внешних ключей в таблицах
    • pk_* для обоих, первичных и внешних ключей в производных таблицах
      • Смысл заключается в том, что в таблицах fk_<что-нибудь_но_чаще_имя_таблицы>, например, fk_marital_status или fk_identity, ссылается на "реальные" внешние ключи. Однако, производная таблица является просто совокупностью полей, например, несколько первичных ключей и связанных с ними данных. Так как внешние ключи берутся из нескольких таблиц, в производной таблице в большинстве случаев невозможно сказать, что является внешним ключом, а что нет. Следовательно, все они рк_*.
    • ufk_* для непривязанных внешинх ключей

клиент

  • Экранные ярлыки и написание пунктов меню "Верхний нижний", например, блокировка клиента, входящие специалиста --> Блокировка клиента, Входящие специалиста, например, GNUmed > Параметры > Интерфейс пользователя ----> Интерфейс пользователя?


старая информация

для ясности и эффективности упорядочите именования, например,

Ох, горе и сила неправильного именования! Мы попали в эту трясину, когда кто-то предположил, что, так как есть getActiveName(), то и setActiveName() должно существовать тоже. Это все красиво и хорошо в определенных ответвлениях теории программирования, но это не имеет смысла в API бизнес-объекта. Название просто неоднозначно. Должно ли оно быть activate_name() или add_name_and_activate() ? (Мой UPDATE над строкой имён, так или иначе нарушает наши деловые соглашения, поскольку мы не изменяем записи имён, а только выступаем против них.) Следовательно, мы должны решить запретить setActiveName в пользу addName (). После этого разъяснения мы узнаем, что можем добавить аргумент флага "activate", не вводя больше двусмысленность. addName() внутренне делает SELECT add_name (), которая является хранимой процедурой, пытающейся заботиться о некоторых вопросах, таких как имя, которое будет добавлено к уже существующему для этого человека. Это тоже обрабатывает флаг активации.
Karsten http://mail.gnu.org/archive/html/gnumed-devel/2003-11/msg00204.html


Разное

На данный момент удобство ошибок может стать проблемой, но логика довольно проста (просто хранить имена и перекрестные ссылки, а также использовать описание курсора и двигаться вперед и назад между именами для виджетов по названиям таблиц, полей и ссылок). Единственной зависимостью именований является то, что таблица имеет несоставной первичный ключ, который называется id, ссылки именуются id_xxxxx, где ххх является ссылочной таблицей, а единственная именованная целевая таблица находится в верхней части дерева ссылок. отношения один-ко-многим еще не обрабатываются ---Syan http://mail.gnu.org/archive/html/gnumed-devel/2003-10/msg00024.html

Когда формальные документы отсутствуют, код может стать решающим фактором. Я предварительно комментирую незарегистрированный код. Но это был понятный код и его предназначением была интуитивность черз хорошие именование переменных, методов и классов. Применение профессиональной фразеологии определенных языков программирования даёт больше для достижения самодостаточности документирования кода. Я тоже, конечно, был предметом оправданных запросов на документацию, скажем, от Hilmar.---Karsten http://mail.gnu.org/archive/html/gnumed-devel/2003-05/msg00168.html

Компиляционная запись о том, как Epydoc рассматривает код Python и извлекает свои комментарии --- Jim http://lists.gnu.org/archive/html/gnumed-devel/2004-06/msg00211.html

-- JamesBusser - 15 Jul 2004
Topic revision: 20 Mar 2013, IvanLykov
 
Download.png
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark