> For the complete documentation index, see [llms.txt](https://mp4.gitbook.io/standard/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mp4.gitbook.io/standard/knowledge/bim/dev/razrabotka-plaginov/obshie-pravila.md).

# Общие правила

**Основной стек технологий:**

* **Язык программирования:** Все плагины для **Revit** разрабатываются на языке C#.
* **Целевая платформа:** Для совместимости с **Revit 2023** используется **.NET Framework 4.8**.
* **Среда разработки (IDE):** Разработчики могут использовать **Visual Studio Code** или **Visual Studio 2026**.
* **База данных BIM:** Взаимодействие осуществляется с **объектно-реляционной системой управления базами данных PostgreSQL**. Для запросов используется язык **SQL**. Для администрирования и управления БД применяется инструмент **pgAdmin 4**. 

**Хорошие практики кодирования:**

* **Принцип DRY (Don't Repeat Yourself):** Минимизируйте дублирование кода. Повторяющуюся логику следует выносить в отдельные **методы**, функции или вспомогательные классы.
* **Читаемость кода и именование:** Используйте осмысленные имена для переменных, методов и классов, которые четко отражают их назначение. Придерживайтесь стандартных соглашений C#:
  * **PascalCase** для имен классов, методов, свойств и публичных полей;
  * **camelCase** для локальных переменных и обычных полей;
  * **\_camelCase** для приватных полей.
* **Инкапсуляция:** Всегда используйте свойства (`Properties`) для доступа к полям (`Fields`) класса. Это обеспечивает контроль над доступом и возможность добавления логики (валидации, уведомлений об изменениях) в будущем.
* **Обработка ошибок:** Используйте структурированную обработку исключений (`try-catch-finally`) для управления ошибками и обеспечения стабильной работы плагина. Избегайте "пустых" блоков `catch` (которые игнорируют ошибки). В блоках catch следует выводить метод `MessageBox.Show(ex.Message)`;
* **Комментарии и документация:** Используйте XML-комментарии для документирования публичных API (методов, классов, свойств). Комментарии внутри методов должны использоваться только в исключительных случаях, когда код неочевиден без пояснений.
* **Принцип единственной ответственности (SRP):** Каждый класс или метод должен выполнять одну, четко определенную задачу. Это упрощает тестирование, отладку и поддержку кода.