Грамматически исправьте идентификаторы двойного существительного, множественные версии

1) Я бы использовал SetUnion и SegmentIntersection, потому что я думаю, что в этом случае множественность все равно подразумевается, и это выглядит лучше.

2) я бы снова использовал FilterOutputs и VectorDirections по той же причине. вы всегда можете использовать MultipleFilterOutputs, если хотите быть более конкретным.

но в конечном итоге это полностью зависит от ваших личных предпочтений.

Использование форм множественного числа существительных может сделать их более трудными для чтения.

Когда у вас есть несколько предметов, они обычно хранятся в структуре данных - массиве, списке, карте, наборе и т. д., которые обычно называются коллекцией или абстрактным типом данных. Интерфейс к коллекции элементов обычно является частью среды программирования (например, Collections в java и .net, STL в C++) и хорошо понимается разработчиками как включающий количество элементов.

Вы можете не использовать множественное число существительных, а сделать явным тот факт, что вы имеете дело с несколькими количествами, и указать, как к ним обращаться, включив имя коллекции. Например,

• VectorDirectionList - перечислены векторы и их направления, например, какой-то тип Pair. Особенно хорошо работает, если у вас есть VectorDirection, объединяющий вектор и направление.
• VectorDirectionMap - если направления векторов отображаются на вектор.

Поскольку это тип коллекции, работа с несколькими объектами понимается так, как это свойственно типу коллекции. Это ставит его в один класс с SetUnion - объединение всегда включает как минимум 2 множества, а VectorDirectionList дает понять, что может быть более одного VectorDirection.

Я согласен с тем, что нужно избегать омонимов, когда слово имеет более одного класса слов, например, Filter, (и, собственно, Set, хотя, на мой взгляд, Set не совсем подходит для использования в имени класса в качестве глагола, поэтому я интерпретирую его как существительное). Изначально я написал это, используя FilterOutput в качестве примера, но это не очень хорошо читалось. Использование сложного слова для Filter может помочь в определении - например, ImageFilterOutputs (или, применяя мое собственное замечание, это будет ImageFilterOutputList.)

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

Я предполагаю, что вы говорите о конструкциях языка программирования, хотя то же мышление применимо к таблицам/представлениям. Подразумевается, что они включают в себя количество элементов, и поэтому названия таблиц часто бывают единичными (Customer, Order, Item), даже если они хранят несколько строк. Таблицы сопоставления "многие-ко-многим" обычно являются соединениями связанных сущностей, например, сопоставление заказов с товарами - OrderItem. По моему опыту, использование множественного числа в названиях таблиц делает SQL трудночитаемым.

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

Почему бы не использовать OutputsOfFilters, UnionOfSets и т. Д., Если вы не попали в затруднительное положение из-за системы, управляемой конвенциями (ruby on rails, cakePHP и т. Д.)? Они могут быть необычными, но могут быть более четкими.

Например, довольно ясно, что ProjectionOfLineSegments и ProjectionOfLineSegment - это разные вещи или даже ProjectionOfLineSegments ....

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

Каким общим правилам я должен следовать?

1. Сделайте Ясным - как для визуальных, так и для слуховых мыслителей.
2. Сделайте это Конкретным, но точным .
3. Пройдите тест «переполненная комната» или «вызов службы экстренной помощи» .

Чтобы проиллюстрировать на примере SetsUnion:

• "SetsUnion" прямо отсутствует; Его легко спутать с опечаткой, и, произнося его (даже в уме), можно спутать это с «Союзом Сета» (или того хуже).

• Также подразумевается множественное число, поэтому вторая «s» является избыточной. SetUnion лучше, но все еще неоднозначен.

• UnionOfSets более понятен и должен быть минимальным стандартом.

• Но все это пока бесполезно расплывчато (если вы не работаете с чистой математической теорией).
  Термин действительно должен быть конкретным . Например, «Красные машинки», «Программисты, слишком много времени посвятившие эзотерике» и т. Д.
  Это все объединения наборов, но они говорят вам кое-что полезное. ; -)

.
Наконец, Фил Фактор имел на это право . Перефразируя:

Можете ли вы выкрикнуть (термин) через переполненную комнату, чтобы он был введен и успешно (использован) слушателем на другой стороне?

Попробуйте крикнуть "SetsUnion" или даже "UnionOfSets" в переполненном ирландском баре. ; -)

Я бы предложил использовать единственное число для первого слова: SetUnion, VectorDirections и т.д.

Выполните быстрый поиск классов в вашей IDE, для: Strings*, Sets*, Vectors*, Collections*

В любом случае, что бы вы ни выбрали, будьте последовательны во всем приложении.

Что не так с Union ()?

Более того, «объединение множеств» превращается в «объединение множеств» (объединение двух множеств есть ...); Я уверен, что я не единственный человек, у которого все в порядке с CamelCase, но не с CamelsCaseMinusApostrophes. Если ему нужен апостроф, чтобы иметь смысл, не используйте его. Set.Union () читается точно как «объединение наборов».

Математика также скажет «объединение (множества) A и B», или, в редких случаях, «объединение (множества) A и B». «Объединение множеств A и B» не имеет смысла!

Большинство людей также увидят Vector [] векторы и Directions [] vectorDirections и предполагают, что векторы [i] соответствуют vectorDirections [i]. Если что-то действительно становится неоднозначным, я использую что-то вроде vector_by_index и vectorDirection_by_index. Затем вы можете иметь Map output_by_filter или Map output_by_filter , что делает очень очевидным ключ (это очень важно в Objective -C, где совершенно неочевидно, какого типа ключи или значения).

Если вы действительно хотите, вы можете добавить s и получить vectors_by_index, но тогда согласованность даст вам глупый outputss_by_filter.

Правильнее, конечно, будет что-то вроде struct FilterState {Filter filter; Выход [] выходов; }; FilterState [] filterStates ;.