Цвет вместо цвета?

Question

Я работаю над игровым движком на C ++, и у меня есть такие методы, как setColour и вещи, которые используют британскую грамматику. Пока я размышлял о том, как компиляторы C ++ в основном используют английский язык (поправьте меня, если я ошибаюсь) и как большинство API-интерфейсов используют американскую грамматику, стоит ли мне идти по течению и продолжать неофициальный стандарт в высшем совете программистов грамматики или быть бунтарем

Я не уверен, какой.

Answer 1

Вы должны использовать американское написание color. 99% кода там используют это, даже включая большую часть кода, написанного британцами или австралийцами. Если вы используете что-то другое, вы (или кто-то другой, кто использует ваш код) просто в конечном итоге забудут, что использовать в какой-то момент, и допустят ненужную ошибку.

Answer 2

Я британец, и я думаю, что правильно сделать, чтобы стиснуть зубы и использовать Color. Я бы не ожидал, что немецкоязычный программист будет использовать Farbe в общедоступном API [*], и я не ожидал бы, что придется предоставлять альтернативные варианты написания, такие как finalize против finalise или localization против localisation.

Компилятор укажет на любые ошибки, поэтому я думаю, что предоставление альтернативных имен для вещей ошибочно. Если подумать, это может даже помешать некоторым программистам, так как автозаполнению IDE придется больше жевать. Если вы собираетесь использовать единственное написание hten, то «Цвет» - это такое распространенное слово в API, которое обычно пишется без «u», так что это произвольная идиосинкразия, когда пишется по-другому. Это никому не поможет.

Очевидно, что нет аргумента сжатия - вы можете вызывать свои функции method001, method002, если хотите, и код все равно будет работать, поэтому Colour - это небольшая причуда по сравнению. Но есть тонкая грань между "причудливым" и "человеконенавистническим".

[*] Просто потому, что он находит это более читабельным, чем Color, я имею в виду. Если он вообще не говорит по-английски, у него нет выбора.

Answer 3

Будь бунтовщиком! Иди с родным английским.

Если вы чувствуете, что подбрасываете сопли американцам, предоставьте прикрывающим функциям неправильное написание ( яростно : но просто убедитесь, что они работают достаточно медленнее, чтобы предпочитать правильное написание).

Answer 4

Какое соглашение об именовании вы выберете, неважно. Используйте любую форму, с которой вам удобнее, при условии, что вы последовательны, как внутри своего кода, так и с любыми ассоциированными API, с которыми вы работаете.

Answer 5

Я использовал те безумные заклинания, которые они используют на маленьком острове под названием Англия по ряду причин:

• Я здесь работаю
• Все мои коллеги работают здесь
• Хорошо .. это Английский язык
• Нам нравится думать, что мы изобрели Интернет
• Мы все думаем, что у нас все еще есть эта огромная империя и мы правим миром и т. Д.
• Нам не нравятся янки! >: (* ​​1018 *

Однако, прежде всего, я пишу на C #, HTML, CSS, JS и т. Д. Я мог бы оставаться упрямым и использовать собственное правописание, но все эти языки используют американизированные ключевые слова и имена членов. Я закончил с кровавым грузом tosh !

По моему C # :

public Color BrightenColour(Color colour); // eew, minging

или по моему CSS :

.greyColoured { color: gray; } /* not semantic? crikey! */

или мой jQuery :

function serialiseForm() {
    return $('input, textarea, select').serialize() // cor' blimey!
}

или мой HTML :

<div align="center">Centre</div> <!-- goodness gracious me! -->

Итак, сегодня я наконец сдался и выполнил поиск и замену всего моего старого традиционного написания. Хотя мне не нравятся все мои новые кросс-атлантические написания, мой код теперь намного чище: D

Ату!

Answer 6

Как австралиец, я придерживаюсь тех же соображений.

На работе мы не используем американское правописание, в основном, потому что для нас это не вторая природа, чтобы писать по буквам таким образом, поэтому (теоретически) потребуется больше времени для написания кода, если мы будем придерживаться соглашения США, как всегда во-вторых, сами догадайтесь. При этом у нас не возникает проблем с переходом между нашими API-интерфейсами и внешними библиотеками стилей конвенций США, но, если вы считаете, что это возможно, это необходимо учитывать.

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

И если это означает придерживаться вашего правописания в Великобритании, сделайте это с оттенком гордости;)

Answer 7

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

Answer 8

Определенно, самое умное, что нужно сделать, это выбрать одно соглашение и придерживаться его (а также документировать его ). C ++ только «использует» небольшое количество зарезервированных ключевых слов. Все остальное зависит от вас (но, разумеется, сумасшедшее соглашение об именах просто разозлит тех, кто придет за вами).

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

РЕДАКТИРОВАТЬ: Пункт, который я считаю, не затронут всеми ответами, которые говорят, что вы должны просто придерживаться американского правописания: во многих случаях (насколько мне известно) само американское правописание не сходилось, например, «параметризация» против «параметризация» (и обратите внимание, что я использовал «z», так что оба они написаны по-американски).

Answer 9

Как правило, я, канадец, использую «цвет» в идентификаторах и «цвет» в комментариях. Например:

/// <summary>Return the colour in CIE Lab space.</summary>
public GetLabColor() : double * double * double;

Answer 10

Почему бы не интернационализировать имена ваших методов. Я предлагаю два варианта для этого. * Назовите ваши методы следующим образом 'method1 "," method2 "и предоставьте разные шпаргалки для разных местных жителей, чтобы у британцев было method1 = setColour, тогда как в Америке они увидят method1 = setColor.

Другой вариант - использовать что-то вроде ASM для перезаписи файлов классов внутри ваших jar-файлов, чтобы для американцев этот метод был «setColor», в то время как в Британии и остальной части Содружества они видят «setColour». Это избавило бы от необходимости дублирования setColor / setColour, как кто-то предложил.