Английский или английский?

Ответ 1

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

Color lineColor = Color.Red;

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

Color lineColour = Color.Red;

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

Label myLabel.color = setColour();

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

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

Ответ 11

У меня есть еще один пример: Serialise и Serialize.:)

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

Ответ 12

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

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

Ответ 13

Я пытаюсь найти альтернативные слова, если это возможно. Я позволю -ize слайд. Для цвета я мог бы использовать Hue, Ink, Foreground/Background...

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

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

Ответ 14

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

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

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

Ответ 15

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

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

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

Ответ 16

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

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

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

Ответ 17

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

Ответ 18

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

Ответ 19

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

Ответ 20

Во-первых, я в США. В моем текущем проекте он всегда "окрашивается", однако слово, которое мы не можем называть орфографией, - "серый" и "серый".

На самом деле это стало очень неприятно.

Ответ 21

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

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

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

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

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

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

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

Ответ 22

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

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

Ответ 23

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

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

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

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

Ответ 24

Основная причина, по которой я слышал для выбора US over UK English, - это то, что британская аудитория, столкнувшись с орфографией в США, понимает это приложение в США (или предположим, что это так), тогда как американская аудитория, "... эй, это неправильно.. это цвет не цвет"

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

Ответ 25

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

Ответ 26

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

Ответ 27

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

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

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

Ответ 28

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

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

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

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

#define ENGB

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