GB английский или американский английский?

Если у вас есть API, и вы являетесь разработчиком из Великобритании с очень международной аудиторией, должен ли ваш API

setColour()

или

setColor()

(Возьмем одно слово в качестве простого примера.)

Инженеры из Великобритании часто защищают свое «правильное» написание, но можно возразить, что орфография в США является более «стандартной» на международном рынке.

Думаю, вопрос в том, какое это имеет значение? Испытывают ли разработчики в других регионах проблемы с орфографией GB или обычно совершенно очевидно, что это означает?

Все ли должно быть на американском английском?

Я бы предпочел использовать английский (США), так как это стало нормой для других API. Как английский программист, у меня, например, нет проблем с использованием «цвета».

Я не носитель языка. В письменной форме всегда стараюсь использовать en-gb. Однако в программировании я всегда использую en-usвместо британского английского почти по той же причине, по которой я не использую немецкий или французский для своих идентификаторов.

Как правило, я был бы приверженцем орфографии GB, но я думаю, что код читается намного лучше, если он согласован, и я обнаружил:

Color lineColor = Color.Red;

выглядеть намного лучше, чем:

Color lineColour = Color.Red;

Я думаю, что в конечном итоге это не имеет значения.

Зависит от того, где вы видите большинство своих клиентов. Лично я предпочитаю использовать English-GB (например, Color) в моем частном коде, но я выбираю Color для опубликованных извне приложений / API / кода!

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

Предполагая, что это Java или C # API, это, вероятно, не имеет значения, учитывая распространенность функции автозаполнения в IDE. Если это для динамического языка или того, где современные IDE не являются нормой, я бы выбрал американское написание. Конечно, я американец и поэтому явно предвзято, но похоже, что большая часть кода, который я вижу от разработчиков, которые не являются носителями английского языка, использует американское написание для своих имен переменных и т.

Как английский программист, я использую en-US для разработки программного обеспечения. Американский английский настолько хорошо доминирует почти во всех других API, что гораздо проще придерживаться одного типа орфографии и устранить двусмысленность. Это пустая трата времени на поиск метода только для того, чтобы найти орфографию с ошибкой на одну букву из-за локализации орфографии.

Я бы пошел с текущими стандартами и выбрал правописание американского английского. HTML и CSS являются общепризнанными стандартами с написанием «цвет». Во-вторых, если вы работаете с такой платформой, как .NET, то, скорее всего, у вас уже есть цвет в разных пространствах имен.

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

Label myLabel.color = setColour();

У меня проблемы с API, которые не на английском (США). Просто из-за разницы в написании. Я знаю, что означают эти слова, но меня сбивает с толку разное написание.

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

Большая часть документации для разработчиков (как и MSDN) написана на американском английском.

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

У меня есть еще один образец: Serialise и Serialize. :)

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

Как канадец, я постоянно сталкиваюсь с этим. Мне очень сложно набирать «цвет», поскольку моя мышечная память постоянно тянется к «u».

Однако я предпочитаю использовать язык библиотек. В Java есть класс Color, поэтому я использую цвет.

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

В противном случае, как англичанин, я буду использовать en-GB, потому что у меня осталось немного гордости за свою страну и свое происхождение.

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

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

Большинство европейских компаний-разработчиков программного обеспечения (по крайней мере, те, с которыми я работал) ведут себя одинаково - код остается на английском языке просто потому, что это делает код более интернациональным, если к ним присоединится другой программист. Однако внутренняя документация обычно выполняется на родном языке.

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

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

Разработчики языка программирования и его встроенных API сделали выбор, и независимо от того, являются ли пользователи международными или нет, они привыкли видеть правописание, соответствующее этому выбору. Вы ориентируетесь не на говорящих на другом языке, а на пользователей языка программирования. Скорее всего, они выучили довольно много слов на иностранном языке из встроенных API-интерфейсов и могут не знать о различиях между американским английским и британским английским. Не путайте их, меняя стороны пруда.

В первую очередь я использую языки .NET, а .NET Framework использует написание английского языка (США). На этой платформе я бы придерживался американского английского. Я не знаю ни одного языка, стандартизированного для GB English, но если ваш сделал это, то во что бы то ни стало оставайтесь совместимыми с языком.

Я согласен с труппой "go for American". Я лично предпочитаю en-GB при написании электронных писем и тому подобного, но американский английский в значительной степени является стандартом во всех кругах программирования.

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

Определенно американский английский.

Во-первых, я в США. В моем текущем проекте это всегда «цвет», однако слово, которое мы не можем выбрать для написания, это «серый» против «серого».

Это на самом деле стало довольно раздражающим.

Выбор языка для имен идентификаторов не имеет ничего общего с аудиторией, а все связано с исходным языком, на котором был разработан фреймворк или API.

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

ИМХО, слишком велика опасность внесения тонких ошибок из-за разного написания.

Переопределение функции может легко стать псевдоперегрузкой.

Конфигурационный файл может стать недействительным из-за разницы в написании.

Может возникнуть ситуация, когда один и тот же концептуальный объект был определен с использованием нескольких классов с использованием как en-US, так и en-GB.

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

Если все ваши программисты британцы, используйте en-gb. Если ваш код увидят программисты за пределами Великобритании, лучшим выбором будет en-us.

Один небольшой момент: мы полагаемся на службу переводов, чтобы скопировать нашу документацию на другие языки. Мы обнаружили, что при использовании en-us в качестве источника переводы становятся лучше.

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

Я работаю в компании, у которой есть офисы в Канаде и США. Мы используем канадское правописание (очень похожее на британский английский) при создании документации и кодов в Канаде и орфографию США для того, что используется в США.

Некоторые вещи пересекают границы, но разница в написании редко является проблемой. Фактически это может вызвать интересный диалог, когда американцы не знают разных вариантов написания кандианского и британского английского. Иногда они согласны с этим, иногда они настаивают на изменении его написания на «правильное». Это также влияет на форматы даты (дд / мм / гггг в Канаде и мм / дд / гггг в США).

Когда заходит в тупик, мы обычно выбираем орфографию в США, поскольку жители Канады знакомы с обоими вариантами.

Основная причина, по которой я выбрал американский английский, а не британский, заключается в том, что британская аудитория, столкнувшись с американской орфографией, понимает, что это приложение для США (или предполагает, что это так), тогда как американская аудитория, столкнувшаяся с британской орфографией, думает: «... эй, это неправильно .. это цвет, а не цвет '

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

Для меня естественно работать на британском английском, даже не задумываясь об этом. Однако, если вы разрабатываете внутренние процедуры, это не имеет большого значения. Если вы создаете API, которые будут использоваться публично, а ваша аудитория является международной, почему бы не реализовать оба?

Я предпочитаю американский английский.

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

Мое личное мнение по этому поводу, однако, заключалось бы в том, чтобы предоставить оба варианта написания, дать им setColor () и setColour (), написать код в одном из них и просто позволить второму передавать параметры.

Таким образом вы будете довольны обеими группами, при условии, что ваш intellisense станет немного длиннее, но, по крайней мере, люди не могут жаловаться на то, что вы используете «неправильный» язык.

Если вы оглянетесь на несколько сотен лет назад, то обнаружите, что это изменение не имеет ничего общего с США, как многие думают. Изменения происходят из-за европейского влияния, особенно французского. До этого английское слово «цвет» на самом деле произносилось как «цвет».

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

Если вы думаете, что язык - это проблема, вам следует подумать о тайваньском кг, который весит 600 г. Мне еще предстоит выяснить, как им это удалось, но я надеюсь, что они никогда не будут использоваться в качестве заправщиков самолетов!

Я всегда использую en-GB для всех своих программ. Думаю, это из-за сильного влияния британских романов.

Однако может быть невозможно иметь два разных набора API (один для en-US, один для en-GB), которые внутренне вызывают одну и ту же функцию? Это может привести к раздуванию файлов заголовков, так что, возможно, в зависимости от определения препроцессора, условная компиляция? Если вы используете C ++, вы можете сделать что-то вроде ниже ...

#ifdef ENGB
     typedef struct Colour
     {
      //blahblahblah
     };
     void SetColour(Colour c);
#else
    typedef struct Color
    {
      //blahblahblah
    };
    void SetColor(Color c);
#endif

В зависимости от того, определяет ли клиентский программист ENGB или нет, как показано ниже

#define ENGB

он мог бы использовать API в той культуре, которую предпочитает. Может быть, излишество для такой тривиальной цели, но эй, если это кажется важным, почему бы и нет! :)