C# Пространство имен проекта с открытым исходным кодом
Я подумываю о выпуске одной из моих библиотек классов, написанных на C#, с открытым исходным кодом. Перед этим я пытаюсь провести рефакторинг, чтобы он отвечал требованиям широкой публики :)
Интересно, какую схему пространства имен лучше всего использовать? В основном я вижу следующие варианты:
- пространство имен MyTool: Мне кажется, это не совсем организовано. Я имею в виду, (почти) все пространства имен в .NET Framework имеют префикс System, поэтому я думаю, что это не совсем стандартный способ сделать это.
- пространство имен MyOrganization.MyTool: Проблема в том, что просто нет "MyOrganization". Пишу в свободное время.
- пространство имен MyName.MyTool: Я бы предпочел что-нибудь более скромное. Я имею в виду, на самом деле, я не хочу, чтобы мое имя было в пространстве имен.
Теперь уже есть пара связанных вопросов по Stackoverflow, таких как это и это, но ни один из них не отвечает на мой вопрос.
Какие-либо предложения?
Ответы 9
Если это открытый исходный код и будут участники, я бы выбрал MyTool.
Если вы можете позволить себе изменить это позже, я бы выбрал MyName.MyTool. Если вы единственный, кто пишет инструмент, вам нужна полная репутация, и ваше имя в пространстве имен никому не повредит.
Если вы берете новых участников, вы можете удалить свое имя из пространства имен, но Только, если другие люди действительно внесли большой вклад. Если большая часть работы принадлежит вам, я бы оставил ее.
Я закончил с Idunno. * Для пары проектов (мой веб-сайт) и SharpSTS. * Для основного (как это название проекта)
MyTool имеет проблему, заключающуюся в том, что имена не уникальны; вы идете к конфликту имен. MyCompany.MyTool не применяется в вашем случае, если вы не хотите навешивать на себя какие-либо ярлыки.
На самом деле мне нравится соглашение Java об изменении URI, связанного с продуктом. Для компаний это сайт компании. Для вас - у вас есть блог / личная домашняя страница, адрес которой вряд ли скоро изменится? Затем используйте имя, поменяв местами TLD и домен второго уровня. В моем случае: net.madrat.MyTool.
Я знаю нескольких людей, которые используют TheirName.MyTool, и это нормально. Однако это становится проблемой, как только появляется второй участник.
Да ... пока java предписывает использовать tld.domname.X (по крайней мере, когда я последний раз касался его 10 лет назад). NET имеет другой набор руководящих принципов и соглашений, которые не привязаны к доменным именам и этому стилю. msdn.microsoft.com/en-us/library/893ke618(VS.71).aspx
@Kev: Я должен сказать, что мне наплевать на правила кодирования .NET. Это одни из худших руководящих принципов, когда-либо созданных Совершенно произвольно и без каких-либо оснований. Это очень плохо для спорных решений. Хотя в данном случае я действительно согласен с тем, что они правы.
@Konrad - Вы читали pearsonhighered.com/educator/academic/product/…. Ни произвольно, ни безосновательно, и аннотировано Рихтером, Брюмме, Мариани. Эти парни не собираются подставлять свои имена под неоправданное «просто потому». Стоит прочитать.
@Konrad - но я в принципе с вами согласен, произвольные стандарты без рифмы и причины - отстой.
Я бы посоветовал получить MyOrganization и использовать ее. Если вы когда-нибудь возьмете деньги за работу, вам понадобится юридическое лицо, которое могло бы защитить вас от ответственности. Настроить что-то довольно просто.
Или просто используйте имя MyOrganization и создайте объект позже, но вы рискуете конфликтовать с юридическими именами и т. д., Если не настроите его сначала.
Вы можете сделать MyToolProject.MyTool. Или вы могли бы просто придумать какое-нибудь креативное название для своей «организации» и иметь его таким, каким будут все ваши будущие проекты с открытым исходным кодом, даже если сейчас это всего лишь один. Тогда у вас может быть MyCreativeOrgName.MyTool.
Я бы выбрал что-то вроде:
namespace OpenSourceProjectCodeName.MajorFunctionalArea
Например:
namespace VideoWizardMagicThing.Audio
namespace VideoWizardMagicThing.Audio.Codecs
namespace VideoWizardMagicThing.Video
namespace VideoWizardMagicThing.Video.Codecs
Вам не нужно полностью сходить с ума с пространствами имен, и все, что вам может понадобиться, это одна или две MajorFunctionalArea. Однако, не зная, как устроен проект и чем он занимается, трудно сказать.
MyOrganization.Technology по-прежнему является рекомендуемым способом начать пространство имен с.
Раньше у меня была аналогичная проблема с именами моего хобби для проектов. Итак, я только что придумал название для одной группы разработчиков (вы хотите иметь короткое и удобочитаемое) и начал его использовать.
Однако имейте в виду, что удобство использования по-прежнему является ключевым фактором. Например, вот одно исключение из правила. Наши Общие библиотеки Lokad с открытым исходным кодом соответствуют пространству имен самой .NET (например: Система или System.Threading). Это потому, что есть множество повседневных помощников и расширений, которые должны быть доступны нашим разработчикам, даже не замечая, что они используют код, отличный от BCL.
Это также улучшает внешний вид объявлений using.
IMHO "вторжение" в официальное пространство имен .net - не лучшая идея. Если код является сторонним, он должен принадлежать стороннему пространству имен. Незнание того, что часть вашего кода использует внешние компоненты, может привести к большим трудностям при отладке / поиске проблем.
Согласовано. Но это был компромисс. Единственная сборка, которая «вторгается» в пространство имен System, фактически используется в каждом прототипе, внутреннем или внешнем проекте нашей компании. Это просто так полезно. Кроме того, он действительно совершенствуется несколькими кодовыми базами, так что проблем с ним пока не возникло.
MyTool очень похож на код проекта / название бренда?
В этом случае, если вы хотите классифицировать его дальше, не используя свою организацию или личное имя, подключите промышленность или проблемная область, для которого он предназначен.
VideoEditing.MyTool
Бухгалтерия.MyTool
ГлавнаяАвтоматизация.MyTool
Что плохого в создании фиктивной MyOrganization? А как насчет Jokepu.YourTool?