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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Color lineColor = Color.Red;

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

Color lineColour = Color.Red;

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

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

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

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

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

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

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

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

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

Label myLabel.color = setColour();

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы считаете, что язык - это проблема, вам следует подумать о тайваньском кг, который весит 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 в той культуре, которую предпочитает. Может быть, излишество для такой тривиальной цели, но эй, если это кажется важным, почему бы и нет! :)

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

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

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

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

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

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

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