Войти
 
 
   
 
  
Новости Notes.ру Библиотека Биржа труда Вопрос - ответ Форум Регистрация Поиск О проекте
Разделы
О Notes
Советы
Шаблоны и примеры
Литература
Презентации
 
Всё о задаче AdminP. Часть вторая   Во второй части мы завершаем рассмотрение AdminP. В ней рассмотрены запросы междоменного администрирования и способы управления функциями AdminP с помощью настроек документа сервера, команд консоли сервера, файла Notes.ini и интервалов очистки базы данных. В этой статье предполагается, что вы опытный администратор Domino и прочитали первую часть
О Notes Читать статью
 
Всё о задаче AdminP. Proxy-действия в R5 и Domino 6   Приложение к статье об административном процессе
О Notes Читать статью
 
Всё о задаче AdminP. Часть первая   Перевод классической статьи 2003-его года о задаче административного процесса (AdminP). Очень полезна для понимания работы механизма этой задачи. В первой части статьи описаны компоненты задачи AdminP, как они работают, и как их использование помогает сделать работу администратора Domino проще. Задача AdminP (сакращённо от Administration Process, Административный процесс) работает с базой административных запросов (Administration Requests, admin4.nsf)
О Notes Читать статью
 


О Notes

Главная   Библиотека   О Notes

Стандарты проектирования и разработки приложений на платформе Lotus Notes

В своё время, после публикации материала Чака Коннелла(Chuck Connel) Как добиться качественного кода (см. >>>) редакция проекта Notesnet.ru получила ряд откликов
Наибольший интерес вызвало письмо Владислава Шубникова, который раскритиковал не собственно правила, а код Чака, иллюстрирующий эти правила
Приводим выдержки из этого письма:
1. Первое, что бросается в глаза - это жуткие наименования переменных.
2. В "Правило хорошего кода 2" есть такая строка кода:
msgbox |Контактная информация:|+fname+| |+lname+|, |+phone
Использование вертикальной черты неудобно, т.к. если строка компонуется из множества составляющих, то при такой записи трудно различить где открывающий, а где закрывающий символы. Лучше использовать фигурные скобки:  {  }

Фигурные скобки следует использовать, если строка собирается для дальнейшего использования в LS. Если же планируется эту строку использовать в @-формулах, то может потребоваться использовать фигурные скобки как часть самой формулы, в таком случае от выделения вертикальной чертой просто не уйти
3. По "Правилу хорошего кода 3 - Константы":
- получаемое значение из InputBox в случаях, когда необходимо получить числовое значение, необходимо обрабатывать Isnumeric(), а потом уже делать Cint(), т.к. пользователь может просто нажать OK (если не было значения по умолчанию, то будет ошибка - пустая строка или пользователь может ввести не число);
- использование оператора Goto по пустякам, можно было организовать цикл Do - Loop с выходом Exit Do;
- показан не лучший пример использования констант. Константы выгодны только при их многократном использовании, иначе их использование ведёт к неоправданному разбуханию программного кода.

Короче.
Если бы я увидел у нас такие скрипты, то очень больно дал бы по рукам.

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

Владислав Шубников, ведущий разработчик, г.Днепропетровск

На данную тему уже было сломано немало копий, также были соответствующие обсуждения, к примеру, на форуме компании Интертраст, инициированное Дмитрием Акуловым >>>
Не знаю, стоит ли говорить, но я поддерживаю следующие реплики этого обсуждения - (>>>) и (>>>), хотя для читателей, вероятно, маловажны мои личные предпочтения.
Поскольку я не видел в сети полностью обобщённых стандартов проектирования/программирования под LND, то решил выложить наши, возможно это будет кому-то интересным.
Целью данной публикации является обмен опытом проектировщиков/разработчиков, потому - жду Ваших отзывов - всегда интересно видеть новые идеи!

Стандарты проектирования и разработки приложений на платформе Lotus Notes

Раздел 1. Написание скриптов вообще

Цель стандартизации - повышение читабельности скриптов; стандарты подобного рода позволяют разбирать "чужие" скрипты очень быстро, чем значительно облегчают разработку и дальнейшую поддержку кода.

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

1. Знать и использовать стандарты названий.

2. Работать с основными зарезервированными (глобальными) переменными.

3. Использовать простые и понятные конструкции. Для неочевидных действий (использования кода) обязательно комментирование!

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

5. Если код получается большим (субъективно: для обычного кода - более 2-х экранов), то за редким исключением (базовый функционал в библиотеках и прочий специализированный функционал) это говорит о неправильной структуре программы.
Необходимо выделять повторно используемые блоки в отдельные функции.

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

Прочие требования:

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

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

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

4. Для повышения читаемости кода оформлять сам текст программы по основным типографским правилам:
- после каждой запятой (в @-формулах - точки с запятой) ставить пробел!
- знак равенства выделять с обеих сторон пробелами (только для LS!).
Примеры:
Неправильно: If PickList("Контакты","SelectAccount",False,"","",NDC)=0 Then Exit Sub
Правильно : If PickList("Контакты", "SelectAccount", False, "", "", NDC) = 0 Then Exit Sub
Символ табуляции использовать только в комментариях!

5. Запрета на использование оператора Goto нет. Есть ограничение - не нужно строить весь код на Goto - это затрудняет отстраивание и дальнейшее понимание логики работы скрипта; стоит помнить и о других операторах (Gosub, Do ... Loop с выходами Exit Do или Exit Sub/Function).
End использовать только в случаях безусловной остановки выполнения программы и только тогда, когда известно, что скрипт будет выполняться ТОЛЬКО в интерфейсе клиента!

6. Не подключать вложенные библиотеки!!! От этого увеличивается размер формы -> уменьшается скорость открытия документа.
Кроме того, в Lotus Notes R6-R7, если будет подключена НЕиспользуемая библиотека, то при исполении данного кода велика вероятность увидеть "NSD is running..." в виде "Малевича серого".

Минимизация кода в свою очередь повышает его читабельность.

Общие требования к оформлению:

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

2. Все шрифты (тексты в колонках, на формах, заголовки колонок видов, текст названий действий) должны быть MS Sans Serif, 8.

3. Кнопки также должны быть MS Sans Serif, 8. Исключение составляют кнопки "удалить" (с крестиком), они должны быть Small Fonts, 4.

Раздел 2. Переменные, функции и их названия

Стандартизация названий переменных и функций:

1. Имя процедуры или функции должно нести смысловую нагрузку, т.е. чтобы по имени можно было определить её назначение.
Функции/переменные/поля желательно называть в переводе на английский язык. Если название на английском получается неочевидным, тогда называть поле в русской транскрипции, только чтобы это не было уродливо (как, к примеру, название функции Snyatscontrolya).
Главное, чтобы название одних и тех же по смыслу полей было одинаковым во всех БД, поэтому необходимо договариваться с другими разработчиками, возможно у нас уже есть и используются в базах поля с аналогичным смыслом.

2. Наименования Объектов, Структур, Массивов, Списков должны начинаться с больших букв или целиком быть аббревиатурами; наименования скаляров - с маленьких, желательно в них не использовать символы верхнего регистра.
Это правило позволяет легко (наглядно) отличать переменные "сложных" типов от простых.

3. Все объектные переменные внутри скрипта должны иметь префиксы отражающие их тип.
Префикс пишется заглавными буквами, является сокращением - заглавные 2-3 буквы из названия класса.
Бардак : Doc1, Doc2, ViewForSearch, db3 и т.д.
Правильно: NotesView - NV
NotesDocument - ND

4. Для разборчивости скрипта избегать использования цифр в названиях переменных.

5. Если в текущем коде имеется несколько переменных одинакового типа (объектов одного и того же класса) - в названия переменных через символ подчёркивания обязательно добавлять информативные суффиксы.
Пример: NDB_Doc
NV_CascadeUpd
NDC_Persons

Утверждённые варианты префиксов:
NotesSession
    NS
NotesAgent
    NA
NotesUIWorkspace
    NUIWS
NotesUIDatabase
    NUIDB
NotesDatabase
    NDB
NotesUIDocument
    NUID
NotesDocument
    ND
NotesDocumentCollection
    NDC
NotesUIView
    NUIV
NotesView
    NV
NotesViewColumn
    NVC
NotesViewEntry
    NVE
NotesViewEntryCollection
    NVEC
NotesItem
    NI, Item
NotesRichTextItem
    RTI
NotesRichTextParagraphStyle
    RTPS
NotesRichTextStyle
    RTS
NotesRichTextTab
    RTT
NotesDateTime
    NDT
NotesDateRange
    NDR
NotesName
    NN
NotesTimer
    NT
NotesACL
    ACL
NotesACLEntry
    ACLE
NotesForm
    NF
NotesDbDirectory
    DbDir
NotesRegistration
    NReg
NotesReplication
    NRepl
NotesLog
    NL
NotesOutline
    NO
NotesOutlineEntry
    NOE
NotesEmbeddedObject
    NEO
NotesViewNavigator
    NVN
NotesInternational
    NInt
NotesNewsletter
    NNL
NotesMIMEEntity
    MIME
Префиксы в основном сформированы по первым буквам в наименованиях классов. Для читабельности желательно чтобы префикс не превышал 3-4 символа.

6. Переменные простых типов (String, Double, Integer, Long) объявляются при помощи зарезервированных суффиксов ($, #, %, &), если точно известно, что данная переменная не будет содержать в себе других типов.

Раздел 3. Переменные (зарезервированные)

Название глобальной переменной

Тип

Назначение

NS

NotesSession 

Текущая сессия

NUIWS

NotesUIWorkSpace 

Текущеее "Рабочее пространство"

NUIDB_Current

NUIDB_Current

текущая UI БД

NDB_Current

NotesDataBase

текущая БД

NUID_Current

NotesUIDocument

текущий UI документ

ND_Current

NotesDocument

текущий документ

NUIV_Current

NotesUIView

текущий UI вид

NV_Current

NotesView

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

NDC_Selected

NotesDocumentCollection

коллекция, содержащая выделенные в виде документы (NotesDatabase.UnprocessedDocuments)

ND_Selected

NotesDocument

1-й документ коллекции NDC_Selected, или текущего вида

ND_Parent

NotesDocument

Родительский документ (инициализировать вручную)

ND_Settings

NotesDocument

Профайл настроек комплекта СЭД.
Большинство указанных переменных инициализируются специальными функциями в зависимости от места вызова: форма, вид, общая инициализация (если код может вызываться и из формы, и из вида, и из агентов).

Продолжение материала >>>

Читайте также
Чак Коннелл Как добиться качественного кода >>>
Десять заповедей по разработке приложений >>>
 
  Опубликовано — 07/08/2007 |    

Vlad Sh, 24.06.2011 17:14:05:
IMHO, скорее от внутренней организации :) и опыта.

Daniel, 08.06.2011 13:45:49:
Стандарты? IMHO зависят от размера организации и опыта.

Sapr, 16.01.2008:
Я абсолютно согласен с данными правилами, особенно если этот код хочет иметь будущее и работа с ним может перейти к другому человеку. А когда каждый пишет, как может – это делает код не читабельным. Чтение кода должно быть похожим на чтение очень интересной книги, от которой не возможно оторваться. А те, кто пишет против этих правил, просто эгоисты и не работали с большими программами (может даже не читали чужие коды).

Dmitry, 31.08.2007:
Плюс еще требование больших букв добивает прикладом!!!! Разве тип так важен для прогания алгоритма???? В венгерке тип указывался малыми буквами и без всякого там подчеркивания. Вспомните как лотус даблклик обрабатывает!!!! Но в то же время, БОЛЬШИМИ префиксами через подчеркивание нужно именовать поля форм, тогда лотусовский даблклик даже помогает при копировании из поля одной формы в другую

Dmitry, 30.08.2007:
Плохой стандарт!!! Так как он просто копирует принцип венгерской нотации, которая создавалась для C++ довольно низкоуровневого языка. Когда люди перешли на C# они поняли, что знать тип переменной не так уж и важно, главное - знать о ее высокоуровневом предназначении и именовать так, чтобы переменные группировались по алфавиту в отладчике и поиске. Зачем мне в лотусе в отладчике сгруппированные переменные по ND_ или NUID_ ??? Мне нужны группы по смысловому содержанию, которым является префикс!!!! Это же относится и к именованию видов, форм, сабформ!!!! Никакой типизации. Ее легко можно посмотреть, если просто исползовать Option explicit и объявлять переменные или нажать точку и увидеть список методов. А то помнить всякие там закорючки.

Vlad Sh, 12.07.2007:
По поводу "dot_notation vs. ReplaceItemValue, GetItemValue"

Я использую расширенный синтаксис в кнопках/действиях, в которых не планируется перенос кода в библиотеки (функции, классы), т.к. код пишется быстрее, да и просто удобно!

Противники расширенного синтаксиса всё время говорят о его недостатке - скорости работы. В лотусовых кругах уже давно ходит басня, как это медленно и в общем-то плохо...
Пока мне до сих пор ни разу не встречалось (в документации или тестах) что это действительно медленнее, чем стандартные ReplaceItemValue, GetItemValue.
Когда раньше програмил в Delphi, то там тоже можно было задавать расширенный синтаксис с помощью default и никто не говорил, что это медленнее, да вопроса такого никогда не стояло.

Несколько месяцев назад на ibm.ru увидел статью Рафаэля Савира "Производительность приложений для Lotus Notes/Domino 7: Часть 1: Свойства базы данных и коллекции документов" (http://www.ibm.com/developerworks/ru/library/notes7-application-performance1/), где говорится:
-------------------------------------
В наших тестах мы никогда не видели различий в производительности между первыми двумя из трех приведенных выше процедур. Использование расширенного синтаксиса класса doc.DateToday = Today кажется таким же быстрым, как и использование doc.ReplaceItemValue ("DateToday", Today). Теоретически, мы должны были бы увидеть некоторое различие в производительности, поскольку в одном случае мы не явно указываем Lotus Notes, что будем обновлять элемент поля, поэтому Lotus Notes должен был бы потратить немного больше времени, определяя, что DateToday на самом деле является полем. Однако практические тесты не показывают отличий.
-------------------------------------
дальше говорят о том, что StampAll быстрее перебора, что неверно (во всяком случае несовпадает с моими тестами), поэтому я этой статье не особо поверил, да и, наверное потому, что мало кому верю вообще... :)
Для себя я решил, что если производительность и хромает на 3-5%, то это не страшно чтобы его использовать так, как я писал вверху.

Но сейчас Вы - "Вопрос ребром поставил "или-или" :) (с) Высоцкий
Самому стало интересно - только что поднял базу, которую я давно писал для тестирования. Результаты оказались с точностью наоборот! Чему я сам удивился немало...

Условия тестирования:
- импорт в локальную БД 80710 документов из текстового файла; при импорте в каждый документ прописывается по 5 полей;
- машина AMD 1,84, мозгов хватает;
- ничего не загружено кроме Lotus Notes;
- каждый тест (3 шт., дальше уже просто было лень) производился поочерёдно, сначала стандартный синтаксис, затем dot.
- перед 3-м тестом "для чистоты эксперимента" снял все задачи в винде, какие только смог.

Стандартный синтаксис:
Тест-1: 92,38 сек.
Тест-2: 88,75 сек.
Тест-3: 94,30 сек.

Расширеный синтаксис:
Тест-1: 78,71 сек.
Тест-2: 86,46 сек.
Тест-3: 87,51 сек.

Базу с результатами (время снималось после каждой тысячи записей) если кого-то заинтересует могу выложить.
Результаты говорят сами за себя - ни разу стандартный синтаксис не был быстрее.
Буду ли я его использовать от этого больше? Нет. :)

В dot лично я вижу только одно неудобство - при переносе кода в функции его придётся сильно менять. Именно поэтому в библиотеках я использую стандартный синтаксис, т.к. имена полей могут передаваться как параметры, константы, ну т.д... Также не использую его в агентах, обрабатывающих множество документов; кстати теперь можно подумать над этим :-\

Omh, 12.07.2007:
Вопрос по коду.
dot_notation vs. ReplaceItemValue, GetItemValue
Метод ReplaceItemValue меня очень радует, а вот про замене всех dot_notation на GetItemValue код получается слишком громоздким. Чем пользуетесь вы?

Andrew Golembiovsky, 11.07.2007:
>>... раскритиковал НЕ собственно правила, а КОД Чака, иллюстрирующий эти правила
2Влад Извиняюсь, не внимательно прочитал начало.

Vlad Sh, 11.07.2007:
Андрей, прежде всего спасибо за Ваш отклик.

>> 1. Какая вам переменная показалось жуткой?<<
Я писал это письмо 2 года назад, если не больше... когда был "модод и гаряч". Стандарты же выложил теперь.
Сейчас, много общаясь с др. разработчиками, увидел множество альтернативных вариантов наименований и т.д.. В этой статье я дал личное видение стандартов и, в отличие от простого, "надо делать только так", я попытался обосновать почему в наших стандартах именно так. Поэтому я не буду спорить о том, какие переменные и как именованы, т.к. это бессмысленно (больше зависит от личных предпочтений, привычки, т.е. субъективно). Главное, что в стандартах есть логика, а не просто потому что "я так привык" и или "мне так нравится". Я признаю, что раньше сам я оценивал чужие скрипты "нравится-не нравится" по внешнему виду, сейчас больше смотрю на логику в целом. Во вступлении написал "для читателей, вероятно, маловажны мои личные предпочтения", и это правильно; поэтому высказывание остаётся бездоказательным. То же самое по кавычкам.

2. >>показан не лучший пример использования констант. Опять бездоказательное высказывание и тут я с вами не согласен. Показан классический пример использования констант... Может конечно сам пример с возрастом не очень удачен :-)<<
Это я и имел ввиду! Const AGE_INPUT_QUESTION = "Введите ваш возраст".
По моему он не удачен, т.к. в БД вообще это выражение вряд ли будет использоваться несколько раз. Т.е. мы здесь друг друга поняли. :)

>>1.6. Под НЕподключением вложенных библиотек имелось ввиду, что:
ситуация: Globals формы подключена библиотека "B", в свою очередь подключающая библиотеку "A"; мы туда же, на Globals формы, вешаем ещё Use "A", сохраняем - вроде всё хорошо. При работе с этой формой Вы очень скоро увидите NSD is Running... в виде "Малевича серого". Если же проделать то же в видах, то при переходе из базы в базу (особенно часто работая с почтой) велика вероятность увидеть вообще "Малевича красного". Это справедливо для LND R6,7, в R5 подобного не было, т.к. раньше "повторное" подключение игнорировалось.

>>2.1...У меня аргумент только один: английский - международный язык общения и не только в программировании. Да, можно сказать: "я не знаю английского..." или "иногда завернут такое..." - не можешь назвать, спроси у соседа.<<
Понятно, что мы лезем в словарь и смотрим... "Проблема" в том, что разработчик может назвать функцию по английски правильно, но другой будет искать эту функцию очень долго, т.к. названа она неочевидно (в словаре множество вариантов перевода); то же самое с полями. 2). Часто функции называют составными именами, и когда получается слитое название (разнобой смысла - разница в понимании) найти её бывает ещё труднее! Понятное дело, что мы советуемся, но редкие исключения всё же бывают.

>>Раздел 3. ...общая инициализация (если код может вызываться и из формы, и из вида, и из агентов).... UI - глобальным переменным у меня доверия нет (только в рамках объекта формы). ..в любом случае глобальная переменная, только при необходимости.<<
Знал, что этот вопрос будет! :) Что тут сказать... Глобальные переменные используют все (или почти все), только почему-то "стесняются" :) об этом говорить; наверное из-за того, что где-то что-то написано или кто-то из "монстров рока" что-то сказал... :)
Мы действительно используем перечисленные глобальные переменные, в проекте они уже лет 8, если не больше. За это время все глюки изучены, их всего 3, соответственно 3 предостережения, 2 из которых есть в этих стандартах. 3-е - не делать Delete объекту текущей БД, т.е. NDB_Current; достаточно присваивать Nothing либо обходить, иначе при программном открытии/закрытии базы и переход в неё открытием документа можем увидеть господина "Малевича красного". После достаточно большого опыта работы с гл.пер. не вижу смысла отказываться от них, т.к. это удобно - многое ненужно передавать как параметры.

>>Общее добавил бы: в последнее время если функция из другой библиотеки, в комментарии добавляю к примеру такой код (подсмотрел у Роки Оливера, т.к. отсутствует нормальный Designer)->'from lib: LibName если константа -> 'const from lib: LibName Да признаю, тяжело будет если с библиотекой что-то происходит в результате пересмотра архитектуры приложения.<<
+1 Сам похожее иногда использую для указания где вызывается функция/агент.

>>Раздел 4.2. Следствие из п.1. - желательно, чтобы названия форм-документов были на русском языке >>и точно соответствовали названию документа! Не использовать псевдонимы, если названия формы >>и реального документа совпадают! Использовать английские псевдонимы всегда, если используется русское название формы. В Раздел 4 добавил бы про новый крыжик у формы - если форма вспомогательная, обязательно поставить "Do not add field names to field index".<<
+100

>>Раздел 5.6. Если в форме используются скрытые поля Сюда бы добавил - на форме завести кнопку Debug ON, чтобы в случае необходимости админ мог посмотреть инфу<<
Хорошая идея. Или общее действие. При закрытом дизайне это может помочь, но больше разработчику, т.к. если админ не участвовал в разработке, то инфа в полях вряд ли чем ему поможет.

>>Раздел 8.1.<< Именование агентов можно просто более жётско стандартизировать: B - это Button, A - Action и т.д... будет занимать меньше места, если речь о нём. Посто в комментах расписание :)

P.S. Спасибо за ссылки на документы! Кое что читал, но большинство придётся проштудировать, т.к. тема интересна ;)

Andrew Golembiovsky, 11.07.2007:
Первое критика критика:
Как мне кажется, Чак в своей статье хотел показать тот здоровый минимум, который лучше применять при написании LS-кода.
Даже точнее, те общие правила, которые существуют в мире написания кода, он переложил на LS-язык.

Вы же пытались свой расширенный стандарт наложить на его код и увидели, что кто-то в мире не применяет ваш расширенный стандарт.
Нисмотря на то, что само письмо не видел и там может всё-таки, что-нибудь существенное есть.
>>1. Первое, что бросается в глаза - это жуткие наименования переменных.
Какая вам переменная показалось жуткой? Бездоказательное высказывание. Чак является носителем того языка,
на котором некоторые пытаются общаться. В вашей же статье я нашел аналогичные наименования переменных.
>>В "Правило хорошего кода 2"...
>>Лучше использовать фигурные скобки: { }
Очень субъективное. Я сам использую {}, но если мне нужно вывести текст как есть, то иногда
напишу так,
tmp=|начало текста

конец текста|, чем tmp={начало текста} +Chr$(13)+ {конец текста}

>>По "Правилу хорошего кода 3 - Константы"
>>показан не лучший пример использования констант.
Опять бездоказательное высказывание и тут я с вами не согласен. Показан классический пример использования констант - если необходимо изменить по каким-либо причинам сообщение, то не надо искать место, где мы его выдали, а вместо этого исправить значение константы. Аналогично с верхней и нижней границей. Может конечно сам пример с возрастом не очень удачен :-)

Думаю, если уж была необходимость критиковать, то имело смысл критиковать именно правила, а не код. К правилам, я так понял из вашего стандарта, особых отрицаний нет.

Второе: спасибо, что решились выложить свой внутренний стандарт написания. Думаю, если кто в будущем будет писать, возьмут за основу. В свое время, то же писал. Моя общая рекомендация выглядела так: помните, код - ваше лицо. Добавлю также, что еще вариант видения есть в Redbook: Domino Designer 6: A Developer’s Handbook
(14.4 LotusScript programming tips and considerations).

Третье: отккоментирую не слишком частное, возможно и по существу.
>>Раздел 1. 4. Для повышения читаемости кода оформлять сам текст программы по основным типографским
+100

>>Раздел 1. 6. Не подключать вложенные библиотеки!!! От этого увеличивается размер формы -> уменьшается скорость открытия документа.
Не совсем понял - т.е. в форме, нельзя использовать Lib "B", если Lib "B" использует Lib "A"?!
Что касается использования библиотек - то это просто необходимость (модульность приложения).
см. Performance Considerations for Domino Applications\3 Programming Considerations\Code Reuse\Script Libraries page 81
см. Domino Designer 6: A Developer’s Handbook - п.14.4.4

Важно следить за иерархией библиотек:
нельзя писать так
Lib "C"
Use "B"
Use "A"
...code
Lib "B"
Use "A"
...code

Вместо этого надо писать
Lib "C"
Use "B"
...code
Lib "B"
Use "A"
...code

>>Раздел 2. 1....Если название на английском получается неочевидным, тогда называть поле в русской транскрипции
не допустимо (хоть и ОЧЕНЬ субъективно). У меня аргумент только один: английский - международный язык общения и не только
в программировании. Да, можно сказать: "я не знаю английского..." или "иногда завернут такое..." - не можешь назвать, спроси
у соседа.

>>Раздел 2. 3. Все объектные переменные внутри скрипта должны иметь префиксы
по префиксам - +1. У меня таблица была другая, есть и такой вариант в
Redbook Domino Designer 6: A Developer’s Handbook по сокращениям (14.4.2)

>>Раздел 3. ...общая инициализация (если код может вызываться и из формы, и из вида, и из агентов)....
UI - глобальным переменным у меня доверия нет (только в рамках объекта формы). Из BE- объект NotesSession один и
так. Возможно просто не понял, что имеется в виду, в любом случае глобальная переменная, только при необходимости.

Общее добавил бы:
в последнее время если функция из другой библиотеки, в комментарии добавляю к примеру такой код (подсмотрел у Роки Оливера,
т.к. отсутствует нормальный Designer)->'from lib: LibName
если константа -> 'const from lib: LibName
Да признаю, тяжело будет если с библиотекой что-то происходит в результате пересмотра архитектуры приложения.

>>Раздел 4. 2. Следствие из п.1. - желательно, чтобы названия форм-документов были на русском языке
>>и точно соответствовали названию документа! Не использовать псевдонимы, если названия формы
>>и реального документа совпадают!
Использовать английские псевдонимы всегда, если используется русское название формы.

В Раздел 4 добавил бы про новый крыжик у формы - если форма вспомогательная, обязательно поставить
"Do not add field names to field index".

>>Раздел 5. 6. Если в форме используются скрытые поля
Сюда бы добавил - на форме завести кнопку Debug ON, чтобы в случае необходимости админ мог посмотреть инфу

>>Раздел 8. 1. Стандарт наименования агентов:
Жесть. Максимум это "<Элемент дизайна откуда произв. запуск>-<Наименование элемента дизайна>#<Объект, откуда произв. запуск>- <Наименование объекта>"
- поместил бы в комментарий.

Владислав Шубников ака Vlad Sh, 11.07.2007:
Спасибо за Ваш отзыв!

У нас тоже не всё так гладко. Это требования, которые у нас действуют/выполняются в настоящий момент, т.е. конечно же "старьё" осталось, но мы его стараемся от версии к версии постепенно убирать. Об этом я когда-то писал:
http://www.intertrust.ru/Site/itforum.nsf/all/0FAB7AD35FBBEB3DC3256F85005550B6?OpenDocument
http://www.intertrust.ru/site/itforum.nsf/49341ed5f4f44f64c3256cee002eeae7/ccae3ab8830ecb6ec32571fe00486a6e!OpenDocument
последняя ссылочка вообще интересная, если подняться в самый вверх.

1-ю часть стандартов, т.е. "скриптовую" можно начинать применять практически сразу, в этом сложностей нет. Именно эту часть мы больше всего "подтягиваем" к нашим стандартам; это несложно даже в ходе разработки (текучки).
2-ю часть, "интерфейсную" (ту, что задевает интерфейс): псевдонимы/наименования представлений и т.п. менять уже сложнее, т.к. тестирование поисков (GetDocumentsByKey...) и отлов "посеревших" :) PickList'ов, и проч... может занять значительное время.
Самая сложная 3-я часть, т.е. то, что связано непосредственно с данными - наименования полей! Такие изменения влекут за собой конвертацию данных в базах заказчиков (если мы конечно же хотим поддерживать у них актуальное состояние дизайна). Поэтому это нужно или делать всё сразу или не делать вовсе. Хорошо, если инет-безлимитка... в противном случае репликация данных выйдет недёшево. Мы такие изменения делаем очень редко, даже не всегда при переходе к новой версии, а если и делаем, то уведомляем заказчика, чтобы знал чем ему это "грозит" :)

P.S. Люди, делитесь идеями по Вашим стандартам! Наверняка ж у всех есть какие-то наработки! :)

Omh, 09.07.2007:
В целом - отлично, даже отличнейше! Даже жаль, что у нас всё стандартизованно не столь жёстко.



Добавить комментарий
Имя * :
e-mail
Комментарий * :
Код подтверждения * :


Мероприятия
Пресс-релизы
Биржа труда
Последнее на форуме
 
А так же:
Как удалить профиль?
16.04.2016 00:08:51
Скопировать в буфер поле документа
24.05.2015 08:55:52
Импорт DXL-описания документов в Lotus Domino. Одноимённые поля
16.04.2015 16:49:58
 
© LOGOSPHERE.RU