Соглашение об именовании артефактов

Question

Мы делаем большой проект на OSGi и добавляем несколько общих модулей.Есть некоторая дискуссия по поводу названия артефакта.

Итак, одна из возможностей именования модуля:

cmns-definitions (для общие определения), другой cmns-definition, еще один cmns-def.Это также влияет на имя пакета.Теперь этоxx.xxx.xxx.xxx.xxx.commons.definitions, если изменить на cmns-def это было бы xx.xxx.xxx.xxx.xxx.commons.def.

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

Я лично склоняюсь к cmns-definitions поскольку внутри пакета не только одно определение.Другие люди отмечают, что java.util например, там нет только 1 утилиты.Все еще, java.util является Сокращенное название для меня.Это может означать Java-утилита или Java-утилиты.То же самое происходит с commons-lang.

Как бы вы назвали пакет?Почему вы выбрали это имя?

1. cmns-definitions
2. cmns-definition
3. cmns-def

Бонусный вопрос:Как назвать что-то вроде cmns-exceptions?Вот как я это называю.Вы бы назвали это cmns-xcpt?

РЕДАКТИРОВАТЬ:

Я высказываю свои собственные мысли по этому поводу в надежде, что их подтвердят или опровергнут.Если можете, пожалуйста, сделайте.

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

Мои рассуждения с точки зрения шаблона следующие:

1) Когда происходит обоснование, и оно хорошо известно в отрасли, следуйте ему в своем именовании.
Например:«функции» - это случай по этому поводу.У нас есть модуль cmns-features.Означает ли это, что у нас есть много функций в этом модуле?Нет.Это означает «модуль, реализующий файл «функций» из Apache karaf».
«commons» — это обоснование слова «common», общепринятого в отрасли.Это не значит «много общего».Это означает «Общий код».

Если я вижу extr-commons в качестве имени модуля, я знаю, что он содержит, например, общий код для extr (в данном случае извлечения).

2) Когда несколько классов внутри модуля совместно придают всему целому особое значение «один и только один», используйте форму единственного числа для его названия.

Сюда включено большинство модулей.Если я называю что-то cmns-persistence-jpa, я имею в виду, что все классы внутри взаимодействуют друг с другом, чтобы обеспечить jpa-реализацию cmns-persistence-api.Я не ожидаю, что внутри него будет две реализации, а на самом деле множество классов, которые вместе составляют одну реализацию.Кристально ясно для меня.Нет?

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

Вот пример определений cmns (перечислений, используемых всей системой).

Альтернативно, использование аббревиатуры позволяет обойти проблему, например.cmns-def, который читатель может также «интерпретировать расширенным» до cmns-definitions.Многие люди также используют «xxxx-util», что означает xxxx-утилиты.

Тем не менее, для объединения вещей можно использовать третий вариант, используя имя, которое само по себе означает множественное число.На ум приходит слово «api», но подойдет любое слово, которое образует множественное число, например «pack».

Поддержкой в ​​этих случаях (3) являются хорошо известные модули, такие как commons-collections (используя множественное число), commons-dbcp (используя аббревиатуру) или commons-lang (опять аббревиатура), а также все, что использует API для упаковки классов вместе по сходству.

Из апача:
commons-collections -> множество мощных структур данных, которые ускоряют разработку наиболее важных приложений Java.
commons-lang -> множество вспомогательных утилит для API java.lang
commons-dbcp -> пакет из нескольких пулов подключений к базе данных

Answer 1

'' Это просто имя ... '

Я нахожу в моей длинной карьере, что эти только имена могут сделать огромную разницу в производительности. Я не думаю, что это имеет значение, если вы используете определения , определение или def до тех пор, пока вы согласуются и используете шаблоны в Имя, которое легко запомнить и может быть использовано для автоматизации процессов. Создание на основе последовательной схемы именования бесконечно проще работать с использованием сборки с именами «хорошего человеческого дисплея», которые являются AD-HOC и не имеют различимого шаблона.

Если вы используете шаблоны, имена, как правило, становится короче. Теперь люди, работающие с этими именами, обычно проводили много времени с ними. Таким образом, их читаемость не так важна, как их мнемоническое значение. Оказывается, что сокращения 3 или 4 персонажей удивительно мощны. Одна из причин в том, что они работают хорошо, так это то, что есть только одно возможное сокращение, в то время как вы пройдете дольше, есть много кандидатов.

В любом случае, большинство импортурных деталей - общая согласованность. Удачи.

Answer 2

definitions (или def или definition) — плохое имя, потому что оно не имеет никакой смысловой нагрузки для читателя.Вы находитесь в объектно-ориентированном мире (я полагаю) - постарайтесь следовать его соглашениям и принципам.Модули в Maven следует называть в честь самой большой «абстракции», которую они содержат.«Определение» — это форма, а не смысл.

Ваш вопрос похож на:«Какое имя класса лучше FileUtilities или FileUtils".Отвечать:никто.

Answer 3

в основном то, что вы делаете с определениями и исключениями, состоит в том, чтобы обеспечить вид API для других модулей.Поэтому я предлагаю объединить определения, исключения и добавлять интерфейсы к нему.Тогда имеет смысл назвать всеми CMNS-API.Я обычно предпочитаю сингулярные имена, поскольку они короче, но вы можете решить, как это просто имя.