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

Ответ 1

Там за этим вопросом лежит грамматическое недоразумение. Когда мы включаем фразу формы:

1. X of Y

в

2. Y X

Y изменяет грамматическую роль от существительного в притяжательной (1) до прилагательного в атрибуте (2). Поэтому, хотя в (1) можно умножать как X, так и Y, в (2) можно только умножать X, потому что Y в (2) является прилагательным, а прилагательные не имеют грамматическое число.

Следовательно, например, SetsUnion не соответствует английскому. Вы можете использовать его, если он вам подходит, но вы ухаживаете за непроходимостью, и я советую против этого.

Postscript

В частности, рассмотрим два других притяжательных построения: сначала старомодное построение, использующее притяжательное местоимение "его", единственное:

3a. Y, its X

эквивалентное множественное число:

4a. Ys, their X

и их сокращения, причем 4b гораздо реже, чем 3b:

3b. Y X
4b. Ys' X

Здесь SetsUnion предполагает, что это рендеринг сингулярного притяжательного типа (3) Set Union (= Set, its Union), где вы намеревались сообщать о множественном притяжательном (4) Sets, their Union (сокращенном до меньшего общий Sets' Union).

Поэтому он активно вводит в заблуждение.

Ответ 2

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

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

Ответ 3

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

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

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

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

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

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

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

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

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

Ответ 4

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

• Сделайте это Очистить - для зрительных и слуховых мыслителей.
• Сделайте это Конкретным, но точным.
• Пройдите тест "Переполненный номер" или "Экстренный телефонный звонок" .

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

• "SetsUnion" сразу; Он легко путается для опечатки и говорит об этом (даже в вашей голове), будет путать его с "Set Union" (или хуже).

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

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

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

Что случилось с Union()?

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

Математизация также скажет "объединение (объединение) A и B", или редко "A и B (set) union". "Объединение множеств A и B" не имеет смысла!

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

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

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

Ответ 8

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

Сделайте быстрый поиск по классам в вашей среде IDE, для: Строки *, Наборы *, Векторы *, Коллекции *

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