GB англійська, або американська англійська?

Якщо у вас є API, і ви розробник із Великобританії з дуже міжнародною аудиторією, ваш API повинен бути

setColour()

або

setColor()

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

Британські інженери часто досить захисно ставляться до своїх "правильних" написань, але можна стверджувати, що правопис США є більш "стандартним" на міжнародному ринку.

Я думаю, питання в тому, чи має це значення? Чи розробники в інших регіонах борються з написанням GB, або, як правило, цілком очевидно, що це означає?

Чи все це має бути американсько-англійською?

Я схильний використовувати американсько-англійську мову, оскільки це стало нормою в інших API. Виступаючи англійським програмістом, я не маю жодних проблем із використанням "кольору", наприклад.

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

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

Як правило, я був би стикер для написання ГБ, але я думаю, що код читається набагато краще, якщо він узгоджується, і я знаходжу:

Color lineColor = Color.Red;

щоб виглядати набагато краще, ніж:

Color lineColour = Color.Red;

Я думаю, що в кінцевому рахунку це насправді не має значення.

Незважаючи на те, що я зазвичай дуже педантично ставлюсь до правильного написання, я, як розробник у Великобританії, завжди дотримуюся американського "кольорового" правопису. У всіх мовах програмування, з якими я стикався, це приблизно так, тому для узгодженості використання "кольору" має великий сенс.

Якщо припустити, що це Java або C # API, це, мабуть, не має значення, враховуючи поширеність функцій автозаповнення в середовищах IDE. Якщо це для динамічної мови або такої, де сучасні IDE не є нормою, я б пішов з американськими написаннями. Звичайно, я американець і тому явно упереджений, але, схоже, більшість коду, який я бачу від розробників, які не є носіями англійської мови, використовують американські орфографії для назв змінних тощо.

Як англійський програміст, я використовую en-US для розробки свого програмного забезпечення. Американська англійська настільки добре домінує майже в кожному іншому API, що набагато простіше дотримуватися одного виду орфографії та усувати двозначність. Це марна трата часу на пошук методу, лише щоб знайти правопис вимкнено на одну букву через локалізацію правопису.

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

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

Label myLabel.color = setColour();

У мене проблеми з API, які не містять американсько-англійської мови. Просто через орфографічні відмінності. Я знаю, що означають слова, але різне написання мене спонукає.

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

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

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

Я отримав ще один зразок: Serialise та Serialize. :)

Особисто я не думаю, що це має велике значення. Я працював над проектами, в яких використовувались англо-англійські країни правопису, і вони використовують британську орфографію. Це все ще англійська мова, і це насправді не має великого значення завдяки Intellisense.

Як канадець, я постійно стикаюся з цим. Мені дуже важко ввести "колір", оскільки моя м'язова пам'ять постійно тягнеться до "u".

Однак я, як правило, приймаю мову бібліотек. Java має клас Color, тому я використовую color.

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

Якщо ні, як англієць, я буду користуватися en-GB, бо в мене залишилася певна гордість за свою країну та своє походження.

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

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

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

Тим не менш, розрізнення тут полягає у двох різних діалектах англійської мови, що не є настільки екстремальним, як бачення двох абсолютно різних мов в одному файлі вихідного коду. Тому я б сказав, зберігайте API на американсько-англійській мові, але ваші коментарі на англійській мові, якщо це вам більше підходить.

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

Дизайнери мови програмування та її вбудованих API зробили вибір, і чи є користувачі міжнародними чи ні, вони звикли бачити написання, що відповідають цьому вибору. Ви націлені не на носіїв іншої мови, а на користувачів мови програмування. Швидше за все, вони вивчили досить багато слів іноземною мовою із вбудованих API, і вони можуть не знати, що існують відмінності між англійською мовою США та англійською. Не плутайте їх, перемикаючи сторони водойми.

Я в основному використовую мови .NET, а .NET Framework використовує написання в американській англійській мові. На цій платформі я б дотримувався американської англійської мови. Мені не відомі жодні мови, стандартизовані на англійській мові, але якщо ваша це зробила, то неодмінно дотримуйтесь мови.

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

Незважаючи на те, що британська англійська мова розмовляють у всьому світі, я рекомендую використовувати американську англійську, яка, як і інші люди, запевняють, домінує на ринку.

Безумовно, американська англійська.

По-перше, я в США. У моєму поточному проекті це завжди "колір", однак слово, для якого ми не можемо підібрати правопис, це "сірий" проти "сірий".

Насправді це стало досить прикро.

Вибір мови для імен ідентифікаторів не має нічого спільного з аудиторією, а все, що пов’язано з мовою оригіналу, на якій був розроблений фреймворк або API.

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

Небезпека впровадження тонких помилок через різні написання занадто велика IMHO.

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

Конфігураційний файл може стати недійсним через різницю в написанні.

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

Отже, незалежно від того, є шматок коду виключно для внутрішнього використання чи призначений також для зовнішнього використання, використовувані орфограми завжди повинні відповідати мові оригіналу платформи / framework / compiler / API.

Якщо всі ваші програмісти британські, використовуйте en-gb. Якщо ваш код побачать програмісти за межами Великобританії, тоді en-us буде кращим вибором.

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

Вам потрібно враховувати свою аудиторію. Хто збирається використовувати код і що вони очікують побачити?

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

Деякі речі перетинають кордони, але різниця в правописі рідко стає проблемою. Це гостро може створити цікавий діалог, коли американці не знають різних варіантів написання для кандіанської та британської англійської мови. Іноді з ними все в порядку, інколи вони наполягають на тому, щоб це змінилося на "правильний" правопис. Це також впливає на формати дат (дд / мм / рррр у Канаді та мм / дд / рррр в США)

Коли виникає глухий кут, ми, як правило, йдемо з американським правописом, оскільки жителі Канади знайомі з обома варіаціями.

Основна причина, яку я чув для вибору американської, а не англійської, полягає в тому, що британська аудиторія, зіткнувшись з американським правописом, усвідомлює, що це американська програма (або припускає, що це так), тоді як американська аудиторія, зіткнута з британським правописом, думає '.. привіт, це неправильно .. це колір, а не колір '

Але, як казали інші, стандартизуйте. Візьміть і дотримуйтесь цього.

Для мене природно працювати англійською мовою, навіть не думаючи про це. Однак якщо ви розробляєте внутрішні процедури, це насправді не має значення. Якщо ви створюєте API, які будуть використовуватися загальнодоступно, а ваша аудиторія міжнародна, чому б не застосувати обидва?

Я віддаю перевагу американській англійській мові.

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

Моя особиста думка щодо цього, однак, полягала б у тому, щоб надати обидва написання, надати їм setColor () і setColour (), записати код в одному з них і просто дати другому передати параметри.

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

Якщо озирнутися на кілька сотень років тому, ви виявите, що зміни не мають нічого спільного із США, як би багато хто так думав. Зміни пов'язані з європейським впливом, зокрема французьким. До цього часу англійське слово "колір" тоді насправді писалося "колір".

Спроби стандартизації були б марними, оскільки половина китайських дітей вивчають доєвропейський вплив та розуміння США англійської мови, тоді як інша половина сприймає це, як сьогодні, як англійську мову.

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