GB tiếng Anh, hay tiếng Anh Mỹ?

Nếu bạn có API và bạn là nhà phát triển tại Vương quốc Anh với lượng khán giả quốc tế cao, thì API của bạn phải

setColour()

hoặc là

setColor()

(Lấy một từ làm ví dụ đơn giản.)

Các kỹ sư tại Vương quốc Anh thường khá bảo vệ về cách viết 'đúng' của họ nhưng có thể lập luận rằng chính tả của Hoa Kỳ là 'chuẩn' hơn trên thị trường quốc tế.

Tôi đoán câu hỏi là nó có quan trọng không? Các nhà phát triển ở các ngôn ngữ khác có gặp khó khăn với chính tả GB hay thông thường khá rõ ràng về ý nghĩa của mọi thứ?

Tất cả có nên là tiếng Anh Mỹ không?

Tôi có xu hướng sử dụng tiếng Anh-Mỹ vì điều đó đã trở thành tiêu chuẩn trong các API khác. Nói như một lập trình viên người Anh, tôi không gặp vấn đề gì khi sử dụng "màu sắc", chẳng hạn.

Tôi không phải là người bản ngữ. Trong văn bản, tôi luôn cố gắng sử dụng en-gb. Tuy nhiên, trong lập trình, tôi luôn sử dụng en-ustiếng Anh Anh thay vì tiếng Anh vì lý do tôi không sử dụng tiếng Đức hoặc tiếng Pháp cho mã định danh của mình.

Phụ thuộc vào nơi bạn nhìn thấy hầu hết khách hàng của mình. Cá nhân tôi thích sử dụng tiếng Anh-GB (ví dụ: Màu) trong mã riêng tư của mình, nhưng tôi chuyển đến Màu cho các ứng dụng / API / mã được xuất bản bên ngoài!

Nói chung, tôi sẽ là một người hiểu chính tả GB nhưng tôi nghĩ rằng mã đọc tốt hơn rất nhiều nếu nó nhất quán và tôi thấy:

Color lineColor = Color.Red;

để trông đẹp hơn rất nhiều so với:

Color lineColour = Color.Red;

Tôi đoán rằng cuối cùng nó không thực sự quan trọng.

Mặc dù tôi thường rất bối rối về việc viết đúng chính tả, với tư cách là một nhà phát triển Vương quốc Anh, tôi sẽ luôn sử dụng chính tả 'màu' của người Mỹ. Trong tất cả các ngôn ngữ lập trình mà tôi đã gặp, nó như thế này, vì vậy, vì lợi ích của sự nhất quán, sử dụng 'màu sắc' có ý nghĩa rất nhiều.

Giả sử đây là một API Java hoặc C #, nó có thể không quan trọng với tính phổ biến của chức năng tự động hoàn thành trong IDE. Nếu đây là ngôn ngữ động hoặc ngôn ngữ mà IDE hiện đại không phải là tiêu chuẩn, tôi sẽ sử dụng cách viết của người Mỹ. Tất nhiên tôi là một người Mỹ và do đó rõ ràng là thiên vị, nhưng có vẻ như hầu hết các mã tôi thấy từ các nhà phát triển không phải là người nói tiếng Anh bản ngữ sử dụng cách viết Hoa Kỳ cho tên biến của họ, v.v.

Là một lập trình viên người Anh, tôi sử dụng en-US cho nhà phát triển phần mềm của mình. Tiếng Anh Mỹ chiếm ưu thế rất tốt trong hầu hết các API khác, đến nỗi việc bám vào một loại chính tả và loại bỏ sự mơ hồ sẽ dễ dàng hơn nhiều. Thật lãng phí thời gian tìm kiếm một phương pháp chỉ để tìm thấy chính tả bị sai một chữ cái do bản địa hóa chính tả.

Tôi sẽ đi theo các tiêu chuẩn hiện tại và chọn cách viết tiếng Anh của Mỹ. HTML và CSS là các tiêu chuẩn được thừa nhận với cách viết là "color", thứ hai, nếu bạn đang làm việc với một framework như .NET thì rất có thể bạn đã có sẵn màu trong các không gian tên khác nhau.

Thuế tinh thần khi phải đối phó với hai cách viết sẽ cản trở hơn là giúp các nhà phát triển.

Label myLabel.color = setColour();

Tôi gặp sự cố với các API không phải bằng tiếng Anh Mỹ. Chỉ vì sự khác biệt về chính tả. Tôi biết những từ này có nghĩa gì nhưng cách viết khác nhau khiến tôi khó chịu.

Hầu hết các thư viện và khuôn khổ mà tôi quen thuộc đều sử dụng cách viết của Hoa Kỳ. Tất nhiên, tôi là người Mỹ nên ... US-English là ngôn ngữ mẹ đẻ của tôi.

Phần lớn tài liệu phát triển (giống như MSDN) là tiếng Anh Mỹ.

Vì vậy, tốt hơn là bạn nên ở lại luồng chính và sử dụng tiếng Anh Mỹ trong API của mình nếu bạn đang nhắm mục tiêu đến đối tượng quốc tế.

Tôi có một mẫu khác: Serialise và Serialize. :)

Cá nhân tôi nghĩ nó không quan trọng lắm. Tôi đã làm việc trong các dự án sử dụng các quốc gia sử dụng chính tả Anh-Anh và họ sử dụng chính tả Vương quốc Anh. Nó vẫn là tiếng Anh và nó không thực sự quan trọng nhiều do Intellisense.

Là một người Canada, tôi luôn gặp phải vấn đề này. Tôi rất khó gõ "màu sắc" vì bộ nhớ cơ của tôi tiếp tục tìm chữ 'u'.

Tuy nhiên, tôi có xu hướng sử dụng ngôn ngữ của các thư viện. Java có lớp Màu, vì vậy tôi sử dụng màu.

Tôi cố gắng tìm các từ thay thế nếu có thể. Tôi sẽ để -ize slide. Đối với Màu sắc, tôi có thể sử dụng Hue, Ink, Foreground / Background ...

Nếu không, với tư cách là một người Anh, tôi sẽ sử dụng en-GB vì tôi còn lại chút tự hào về đất nước và nguồn gốc của mình.

Tuy nhiên, nếu nó là một phần của một dự án lớn hơn, đặc biệt là một dự án quốc tế, tôi sẽ giữ cho toàn bộ dự án nhất quán ở trên, có một phần nhỏ thuộc một biến thể ngôn ngữ và phần còn lại ở một ngôn ngữ khác.

Tôi cũng sẽ phải làm việc với tiếng Anh-Mỹ, chỉ đơn giản là để giữ mọi thứ nhất quán (như những người khác đã lưu ý ở đây). Mặc dù tôi là người nói tiếng Anh-Mỹ bản ngữ, tôi đã thực hiện các dự án phần mềm với cả các công ty phần mềm của Đức và Thụy Điển, và trong cả hai trường hợp, đôi khi sự cám dỗ khiến đồng đội của tôi sử dụng văn bản tiếng Đức hoặc tiếng Thụy Điển trong mã - thường là để nhận xét, nhưng đôi khi cũng cho tên biến hoặc phương thức. Mặc dù tôi có thể nói những ngôn ngữ đó, nhưng điều đó thực sự chói tai và khiến việc đưa một người mới không phải là người nói vào dự án trở nên khó khăn hơn.

Hầu hết các công ty phần mềm châu Âu (ít nhất là những công ty tôi đã từng làm việc) hoạt động theo cùng một cách - mã vẫn bằng tiếng Anh, đơn giản vì điều đó làm cho mã thân thiện hơn với quốc tế nếu một lập trình viên khác tham gia. Tuy nhiên, tài liệu nội bộ thường có xu hướng được thực hiện bằng ngôn ngữ mẹ đẻ.

Điều đó nói rằng, sự khác biệt ở đây là về hai phương ngữ khác nhau của tiếng Anh, điều này không hoàn toàn nghiêm trọng bằng việc nhìn thấy hai ngôn ngữ hoàn toàn khác nhau trong cùng một tệp mã nguồn. Vì vậy, tôi muốn nói, hãy giữ API bằng tiếng Anh-Mỹ, nhưng nhận xét của bạn bằng GB-tiếng Anh nếu nó phù hợp với bạn hơn.

Tôi muốn nói rằng hãy xem cách các thư viện khác bằng ngôn ngữ của bạn chọn và tuân theo quy ước của họ.

Các nhà thiết kế của ngôn ngữ lập trình và các API tích hợp của nó đã đưa ra lựa chọn và liệu người dùng có phải là quốc tế hay không, họ đã quen với việc xem cách viết phù hợp với lựa chọn này. Bạn không nhắm mục tiêu người nói ngôn ngữ khác mà là người dùng ngôn ngữ lập trình. Kỳ lạ là họ đã học được khá nhiều từ bằng tiếng nước ngoài từ các API được tích hợp sẵn và họ có thể không biết rằng có sự khác biệt giữa tiếng Anh Mỹ và tiếng Anh GB. Đừng nhầm lẫn chúng bằng cách chuyển đổi bên của ao.

Tôi chủ yếu sử dụng ngôn ngữ .NET và .NET Framework sử dụng cách viết tiếng Anh Mỹ. Trên nền tảng này, tôi sẽ gắn bó với tiếng Anh Mỹ. Tôi không biết bất kỳ ngôn ngữ nào được chuẩn hóa trên GB English, nhưng nếu ngôn ngữ của bạn đã làm như vậy thì bằng mọi cách, hãy nhất quán với ngôn ngữ đó.

Tôi đồng ý với đoàn "đi vì người Mỹ". Bản thân tôi thích en-GB khi viết e-mail và những thứ như vậy, nhưng tiếng Anh Mỹ gần như là tiêu chuẩn trong tất cả các giới lập trình.

Mặc dù tiếng Anh Anh là thứ được sử dụng trên khắp thế giới - tôi khuyên bạn nên sử dụng tiếng Anh Mỹ, giống như những người khác đã nói đang thống trị thị trường.

Chắc chắn là tiếng Anh Mỹ.

Đầu tiên, tôi đang ở Mỹ. Trong dự án hiện tại của tôi, nó luôn luôn là "màu sắc", tuy nhiên, từ mà chúng tôi dường như không thể chọn chính tả là "màu xám" so với "màu xám".

Nó thực sự trở nên khá khó chịu.

Lựa chọn ngôn ngữ cho tên định danh không liên quan gì đến đối tượng và mọi thứ liên quan đến ngôn ngữ gốc mà khung hoặc API được phát triển.

Tôi không biết nhiều ngôn ngữ nhưng tôi không thể nghĩ ra một ngôn ngữ nào sử dụng được ngôn ngữ nào khác ngoài tiếng Anh Mỹ.

Nguy hiểm của việc đưa vào các lỗi tinh vi do các cách viết khác nhau là IMHO quá lớn.

Việc ghi đè chức năng có thể dễ dàng trở thành quá tải giả.

Tệp cấu hình có thể trở nên không hợp lệ do sự khác biệt về cách viết.

Một tình huống có thể phát sinh khi cùng một đối tượng khái niệm đã được xác định bằng nhiều lớp, sử dụng cả en-US và en-GB.

Vì vậy, do đó, cho dù một đoạn mã hoàn toàn dành cho mục đích sử dụng nội bộ hay mục đích sử dụng bên ngoài, thì cách viết được sử dụng phải luôn khớp với ngôn ngữ gốc của nền tảng / khuôn khổ / trình biên dịch / API.

Nếu tất cả các lập trình viên của bạn là người Anh, hãy sử dụng en-gb. Nếu các lập trình viên bên ngoài nước Anh nhìn thấy mã của bạn, thì en-us sẽ là lựa chọn tốt hơn.

Một điểm nhỏ, chúng tôi dựa vào dịch vụ dịch thuật để sao chép tài liệu của chúng tôi sang các ngôn ngữ khác. Chúng tôi nhận thấy rằng chúng tôi nhận được bản dịch tốt hơn khi sử dụng en-us làm nguồn.

Bạn cần cân nhắc đối tượng của mình. Ai sẽ sử dụng mã và những gì họ mong đợi để xem?

Tôi làm việc trong một công ty có văn phòng ở cả Canada và Mỹ. Chúng tôi sử dụng cách viết của Canada (rất giống với tiếng Anh của Anh) khi tạo tài liệu và mã ở Canada và chính tả của Hoa Kỳ cho những gì được sử dụng ở Hoa Kỳ.

Một số thứ vượt qua biên giới, nhưng sự khác biệt về chính tả hiếm khi là một vấn đề. Nó có thể tạo ra một số cuộc đối thoại thú vị khi người Mỹ không biết cách viết khác nhau cho tiếng Anh của Candian và Anh. Đôi khi họ đồng ý với nó, đôi khi họ khăng khăng đòi nó phải thay đổi chính tả "đúng". Điều này cũng ảnh hưởng đến các định dạng ngày (dd / mm / yyyy ở Canada và mm / dd / yyyy ở Mỹ)

Khi gặp bế tắc, chúng tôi thường sử dụng cách đánh vần của Hoa Kỳ vì người dân Canada đã quen với cả hai biến thể.

Lý do chính mà tôi đã nghe để chọn tiếng Anh Mỹ thay vì tiếng Anh Anh là vì khán giả Vương quốc Anh, khi đối mặt với chính tả Hoa Kỳ, nhận ra đó là ứng dụng của Hoa Kỳ (hoặc giả sử là như vậy), trong khi khán giả Hoa Kỳ đối đầu với chính tả Vương quốc Anh nghĩ '.. . Này, sai rồi .. màu không phải màu '

Nhưng giống như những người khác đã nói, tiêu chuẩn hóa. Chọn và gắn bó với nó.

Tôi tự nhiên làm việc bằng tiếng Anh Anh mà không cần nghĩ đến nó. Tuy nhiên, nếu bạn đang phát triển các quy trình nội bộ thì điều đó không thực sự quan trọng. Nếu bạn đang tạo các API sẽ được sử dụng công khai và đối tượng của bạn là quốc tế, tại sao không triển khai cả hai?

Tôi thích tiếng Anh Mỹ hơn.

Tôi là một trong những người có nhịp tim và huyết áp tăng mỗi khi tôi buộc phải sử dụng tiếng Anh Mỹ trong các tệp thiết lập, v.v., do phần mềm không cung cấp tùy chọn cho tiếng Anh Anh, nhưng đó chỉ là tôi :)

Tuy nhiên, ý kiến ​​cá nhân của tôi về cái này là cung cấp cả hai cách viết, cung cấp cho chúng setColor () và setColour (), viết mã trong một trong số chúng và chỉ cần cái thứ hai chuyển các tham số qua.

Bằng cách này, bạn giữ cho cả hai nhóm vui vẻ, thời gian hoạt động lâu hơn một chút, nhưng ít nhất mọi người không thể phàn nàn về việc bạn sử dụng ngôn ngữ 'sai'.

Nếu bạn nhìn lại vài trăm năm, bạn sẽ thấy sự thay đổi không liên quan gì đến Hoa Kỳ, nhiều người nghĩ vậy. Những thay đổi bắt nguồn từ ảnh hưởng của châu Âu, đặc biệt là người Pháp. Trước thời điểm đó, từ tiếng Anh "color" sau đó thực sự được đánh vần là "color".

Cố gắng tiêu chuẩn hóa sẽ là vô ích vì một nửa trẻ em Trung Quốc đang học tiếng Anh trước ảnh hưởng của châu Âu và tiếng Mỹ, trong khi nửa còn lại học tiếng Anh như ngày nay.

Nếu bạn nghĩ rằng ngôn ngữ là một vấn đề, thì bạn nên xem xét Đài Loan Kg nặng 600g. Tôi vẫn chưa tìm ra cách họ quản lý cái đó như thế nào, nhưng tôi hy vọng họ không bao giờ được tuyển dụng làm nhân viên tiếp nhiên liệu cho máy bay!

Tôi luôn sử dụng en-GB cho tất cả các chương trình của mình. Tôi đoán đó là do ảnh hưởng nặng nề của tiểu thuyết Anh.

Tuy nhiên, có thể không có hai bộ API khác nhau (một cho en-US, một cho en-GB) gọi nội bộ cùng một hàm không? Tuy nhiên, điều này có thể làm phình các tệp tiêu đề, vì vậy có thể phụ thuộc vào định nghĩa bộ tiền xử lý, biên dịch có điều kiện? Nếu bạn đang sử dụng C ++, bạn có thể làm điều gì đó như dưới đây ...

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

Tùy thuộc vào việc lập trình viên khách hàng có định nghĩa ENGB hay không như bên dưới

#define ENGB

anh ấy có thể sử dụng các API trong nền văn hóa mà anh ấy thích. Có thể quá mức cần thiết cho một mục đích tầm thường như vậy, nhưng này, nếu nó có vẻ quan trọng, tại sao không! :)