Программистам, пишущим под AutoCAD

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

Как показывает практика, основная масса таких "кодописателей" пребывает в твёрдом убеждении, что пользователи используют исключительно их библиотеки, не допуская мысли, что помимо их творчества, юзер может грузить в AutoCAD что-то ещё. Во всяком случае именно такое впечатление у меня складывается, когда я вижу, что библиотека требует для себя отдельной записи в  "Support Search File Path", и/или определяет в своём составе команды с короткими именами вроде "dt", "otg" и т.п., что нередко приводит к конфликту библиотек между собой.

В своей практике я периодически сталкиваюсь с такими программистами, которые откровенно демонстрируют своё наплевательское отношение к обозначенным мною ниже правилам программирования под AutoCAD.

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

Если вы выкладываете свой код в интернет, или передаёте его соседу, то позаботьтесь о том, чтобы те, кто этот код будут юзать, не получили кучу проблем только потому, что вам было лень писать код нормально, ибо вы писали его "только для себя". Если пишете в стиле "для себя", то не стоит распространять своё "творчество", выкладывая его в интернет, или давая соседу - не создавайте проблем для пользователей. Даже если у Васи Пупкина сегодня всё работает, не факт, что завтра, загрузив очередную библиотеку такого же "пишущего для себя" программиста, он не получит проблем. Когда Вася прибегает с проблемой к таким "кодописателям", те зачастую отвечают, что проблема конечно же вовсе не в их коде, а в коде той библиотеки, которую Вася загрузил сегодня (ведь до "сегодня" всё работало!!!)...

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

VBA/AutoLisp/VisualLisp-программистам

При грамотной организации хранения библиотек, они все должны быть собраны по подкаталогам некоторого общего каталога (соображающие пользователи, как правило, именно так и поступают). Такой подход позволяет пользователю, указать всего лишь один единственный (базовый) каталог в диалоговом окне Options, на вкладке Files в группе Support Search File Path, при условии, что используемые им vba/lisp-библиотеки написаны грамотно, а не через одно место. Например, это может быть некий каталог "%ProgramFiles%\GPSM\AdminCAD\Applications". Т.о. при условии грамотного написания кода, каждая библиотека, отталкиваясь от базового каталога, сможет найти нужный ей ресурс. Под "грамотным написанием" в данной ситуации я подразумеваю то, что программисту в его lisp-коде всегда следует прописывать относительные пути (с указанием недостающей части), относительно некоторого общего каталога библиотек.

Например, вместо "settings.xml" в lisp-коде предусмотрительно следует писать ".\\authorName\\libName_libVersion\\settings.xml". Такой подход потребует от пользователя создать некий дополнительный набор вложенных каталогов, изолировав тем самым файлы вашей библиотеки от файлов библиотек других разработчиков. Кроме того, указанный подход избавит  пользователя от необходимости добавления в "Support Search File Path" дополнительного каталога поиска для вашей библиотеки, что в свою очередь позволит избежать постепенного превращения "Support Search File Path" в помойку - это несомненно происходит, когда каждая lisp-библиотека требует для себя дополнительный каталог поиска. Малое количество каталогов поиска в  "Support Search File Path", в свою очередь положительно повлияет на производительность AutoCAD, сокращая время поиска необходимых ресурсов.

В обязательном порядке создавайте файл ReadMe.txt, содержимое которого обозначено в одном из пунктов следующего раздела.

Обобщённый набор правил

• Создавайте уникальные имена команд и функций, используя для этого префиксы. Соблюдение этого правила позволит избежать конфликтов наименования команд и функций, когда пользователь загрузит помимо вашей библиотеки ещё и библиотеку др. разработчика.
• Не создавайте слишком коротких имён команд и функций, т.к. для этого существует файл acad.pgp - пусть пользователь сам для себя настроит нужные ему псевдонимы для ваших команд. Велика вероятность того, что короткие имена команд переопределят созданные пользователем в файле acad.pgp псевдонимы.
• Назначайте командам и функциям понятные, легко запоминающиеся имена.
• Если в процессе работы вашего кода вы временно изменяете какие-то настройки (например отключаете объектные привязки), то не забывайте восстанавливать их в исходное состояние по завершению работы вашей команды.
• Выносите конфигурационные настройки за рамки кода во внешний файл. Например имена слоёв, стилей, блоков и их настройки следует хранить во внешнем файле, а не в коде, поскольку заданные вами настройки могут конфликтовать с утверждённым Стандартом предприятия по работе с AutoCAD. Редактировать конфирурационный файл гораздо проще, чем перелопачивать исходный код (если он вообще присутствует).
• Снабжайте подробными комментариями ваши конфигурационные файлы, дабы пользователь или администратор CAD смог без труда переопределить настройки нужным ему образом (если это потребуется).
• Дабы избежать хаоса и ускорить работу AutoCAD, старайтесь добавлять в Support File Search Path как можно меньше дополнительных каталогов поиска, необходимых для работы ваших приложений. Вообще, по хорошему, достаточно добавить одну запись, а в коде загрузки использовать относительные пути, которые AutoCAD вычислит относительно добавленного вами каталога. Например так: (load "123/456/test.lsp"). Т.о. вероятность того, что вы загрузите именно тот файл, который хотели, а не одноимённый, найденный в другом месте - значительно возрастает. Кроме того, используя данный подход вы исключите возможность того, что AutoCAD найдёт именно тот файл, который вам нужен, а не одноимённый файл (например файл настроек или файл данных) из каталога приложения Васи Пупкина. В добавленном каталоге следует грамотно структурировать по подкаталогам библиотеки и ресурсы. При необходимости - добавлять readme.txt, поясняющие, какой каталог для чего предназначен и от каких ресурсов зависит (с указанием их размещения в относительной форме).
• Относительный путь размещения библиотеки всегда следует формировать согласно общепринятому правилу: .\\НаименованиеКомпании\\Наименование_и_Версия_Продукта\\. Именно этому правилу следует Microsoft при размещении информации по программе в %ProgramFiles%, %AppData%, реестре (ветки HKLM\SOFTWARE и HKCU\SOFTWARE) и т.п. Данное правило рекомендуется использовать всем разработчикам ПО для MS Windows. Это позволяет группировать программы и их настройки по компаниям-разработчикам.
• Вместе с библиотекой создавайте справку о её командах, а так же инструкцию об установке. Хотя бы обычный ReadMe.txt, в котором были бы перечислены имена и назначения команд библиотеки,а так же прописана относительная иерархия подкаталогов, которую следует создать для данной библиотеки. Создавайте подробную инструкцию по установке (не ленитесь) вашей библиотеки, с указанием необходимых системных требований. Очевидное для вас, не всегда очевидно конечному пользователю.
• Комментируйте исходники своего кода, дабы спустя некоторое время вы, либо др. разработчик могли бы быстро разобраться в нём в случае необходимости внесения изменений.
• Плагин не должен самостоятельно прописывать себя в автозагрузку каждый раз при своей загрузке в AutoCAD. Решение о том, стоит ли добавлять плагин в автозагрузку должен принимать пользователь, а не сам плагин в лице своего разработчика!