9 правил крутого расширения для Visual Studio

Крутые расширения Visual Studio имеют несколько ключевых признаков, которые отличают их от остальных. Они выглядят и на самом деле хорошо продуманы, функциональны и надежны. Кроме того, они делают то, что должны, до уровня совершенства и нативно вписываются во внутренние функции Visual Studio.

Чтобы упростить написание хороших расширений, мы работаем с сообществом над разработкой простого чек-листа. Существует даже GitHub issue template, который вы можете использовать. В этой статье рассмотрим 9 правил крутого расширения. Подробности под катом.

Правила

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

Правило 1: Придерживаетесь правил потоколирования

Добавьте пакет NuGet Microsoft.VisualStudio.SDK.Analyzers в свой VSIX проект. Это поможет вам обнаружить и устранить распространенные ошибки в отношении потоков.

Правило 2: Добавьте иконку в высоком качестве

Все расширения должны иметь значок, связанный с ними. Убедитесь, что значок представляет собой высококачественный файл .png с разрешением 128×128 пикселей и DPI 96 или больше. После добавления значка в проект VSIX зарегистрируйте его в файле .vsixmanifest как значок и изображение для предварительного просмотра. В Visual Studio Marketplace используется более крупный значок, и ваш будет динамически изменяться при отображении в Visual Studio.

Правило 3: Название и описание

Исследования показывают, что пользователи чаще устанавливают расширения с короткими описательными именами и точными данными о них. Убедитесь, что имя отражает суть того, что делает расширение. Описание в файле .vsixmanifest должно создавать ожидания относительно того, что делает расширение. Итого, краткое описание того, какие проблемы решает расширение и какие его функции являются ключевыми.

Правило 4: Напишите хорошее Marketplace-описание

Это одна из самых важных вещей, которую вы должны сделать, чтобы ваше расширение стало успешным. Хорошее описание состоит из:

• Скриншотов/гифок того, что будет добавлено расширением
• Подробного описания фич
• Ссылок на детали, если необходимо

Правило 5: Укажите лицензию

Лицензия отображается в Marketplace, в установщике VSIX и в диалоговом окне Extensions Manager. Всегда указывайте лицензию, чтобы создавать ожидания для пользователей. Подумайте о том, чтобы использовать choosealicense.com для поиска подходящей лицензии. Причиной этого правила является устранение любой неоднозначности, что важно для многих пользователей Visual Studio.

Правило 6: Добавьте уведомление о конфиденциальности

Если расширение собирает данные, например телеметрию, добавьте примечание об этом в описании.

Правило 7: Используйте KnownMonikers где возможно

Visual Studio поставляется с тысячами значков, которые доступны в коллекции KnownMonikers. При добавлении значков к кнопкам проверьте: возможно вы можете использовать существующие значки KnownMonikers, ведь они являются частью языка проектирования, знакомого пользователям Visual Studio. Вот полный список KnownMonikers, а также можно использовать расширение KnownMonikers Explorer, чтобы найти подходящий для ваших сценариев.

Правило 8: Создайте ощущение нативности расширения

Следуйте тем же шаблонам и принципам проектирования, которые использует сама Visual Studio. Это делает расширение естественным для пользователей. Это также уменьшает отвлекающие факторы, вызванные плохо проработанным пользовательским интерфейсом. Убедитесь, что все кнопки, меню, панели инструментов и окна инструментов по умолчанию видны только тогда, когда пользователь находится в правильном контексте для их использования. Есть несколько правил:

• Никогда не добавляйте новое меню верхнего уровня (рядом с Файл, Изменить и т.д.)
• Никакие кнопки, меню и панели инструментов не должны быть видны в контекстах, к которым они не относятся
• Если необходима автозагрузка (скорее всего нет), сделайте ее как можно позже.
• Используйте VisibilityConstraints для переключения видимости команд вместо того, чтобы полагаться на автоматическую загрузку

Правило 9: Используйте правильные диапазоны версий

Может быть заманчиво поддерживать версии Visual Studio вплоть до Visual Studio 2010, чтобы каждый мог использовать ваше новое расширение. Проблема заключается в том, что при этом больше нельзя использовать API, представленные позже, чем та старая версия, которую поддерживает расширение. Часто эти новые API важны и помогают повысить производительность и надежность как вашего расширения, так и самой Visual Studio.

Вот наши рекомендации по принятию решения о том, какие версии Visual Studio поддерживать:

• Поддерживайте только предыдущую и текущую версии Visual Studio — по возможности не поддерживайте более старые версии
• Не указывайте диапазон доступных версий. Например. [16.0,). Узнайте больше о версиях тут.

Ваше мнение

Что вы думаете об этом чек-листе? Согласны ли вы с правилами? Пожалуйста поделитесь мыслями ниже в комментариях или в репозитории GitHub. Я надеюсь чек-лист поможет вам создавать крутые расширения, которые станут действительно популярными.