This means the code can be read by anyone anywhere in the world on any operating system and that string payloads can similarly be read by anyone anywhere in the world.
But in cases where the program will be dealing with some concept that doesn't exist in English, being able to refer to things by their actual name, in the native language (assuming that's also the native language of the customer and development team), is much better than inventing a confusing and unnatural English translation.
Uh, no? You are not supposed to be able to read this valid Unicode string literal in Korean: `"그뤼고 이 문좌열은 일부려 기ㅖ버역을 어럽게하러고 오타비문이 산개해 있구먼요."`
Also a significant portion (and possibly the majority) of codes would be ever read and written by a small group of people, often sharing a common language other than English, so non-English code is just fine for them. If you are saying that a public library should be written in English, I almost agree---there would be some exceptions though.
public class 그뤼고
{
private 이 이 {get;set;}
public 그뤼고()
{
var 문좌열은 = 이.문좌열은;
var 기ㅖ버역을 = Enumerable.Range(0, 10);
var 오타비문이 = 기ㅖ버역을.Select(요 => 요);
}
}
public class 이
{
public int 문좌열은 {get;set;}
}I have seen numerous instances of pseudo-English when it comes to naming. It is hard to name things in non-native tongues. When reasonable, reducing that overhead can be indeed beneficial.
Plus it is pain to alt+shift between languages all the time.