Use of Ñ in variable names

I was wondering what prevents me from using the word "year" and wanted to know your thoughts on it: the good, the bad and the ugly; any opinion or comment about it will be useful to me.

1) Work with an international team.

When you work in an international team, using which characters can be a nightmare for other team members; not all keyboards have the same facility to access (for example) our beloved N with comb; so if you use this keyboard:

And your North American co-worker uses this:

It will be a problem for your partner to access the Ñ. And if you work with computers that have very different alphabets, the problem grows exponentially:

int 入玉口千 = 0xFf800000;
int 人王ロ干 = 0xF8000000;

I swear that both variables are different, look closely at the names. I really don't have a good eye for Japanese, so I don't think I can use the correct variable.

Decimal año = 2000; // 365 días
Decimal ano = 2016; // Parte de mi anatomía

For me the difference between both things is very evident, perhaps other co-workers from other countries do not have it so clear.

bool flag = false; // это не является необходимым

I will never know what my colleague Pavlov Provotorov intended to say.

public void Iͬͩͩ̽ͦ̍҉̣͙ņ̨̠̩͈̰͎̹̼̎̊͑̌̀vͪ͐ͮ̒ͣ͒͡͏̠̤̱̪̥ợ̟͔ͭ̃͌c͙̣̱̏̿ͯ̓̅̋͛a̵̝̲͚̭̗ͬ̊ͅ_̷̱̻̤̪̝̥̠͉̂̐͊ͣ͡͝ͅâ̬̱̳̮͆ͭ̕͢ͅl̟͕̳̣ͯͦ̎ͯ̄ͩ͗ͯ̕̕͞_̽ͪ̇ͫ̆҉̧̱͚̻̝̠d̮̗̜͈̝̩̦͆̓̑͐e͂҉̩̩͓͠m̛̠̣͈̠̩̂̂͋̅ô̧͍͑͌͛n̂͏͙̭i̧͉̋ͤ̏̐̍͊͘o̶͕̹̳̟͇͇̝͉ͮͩ͋͆()

I don't even want to think what this function can do.

bool ? = check_error();
if (?) { // shit happens

Someone will find it funny, to me it seems in bad taste .

2) Companions excessively attached to correctness.

I've run into problems like the Ñone with math co-workers writing code like this:

double π = 3.14159265;

Even though π is the correct symbol for that constant, typing it into code is worse than an awkward pain in the ass ; I used to have a text file open with the symbols I couldn't type to copy-paste when I needed to; but that didn't make my life any easier or more comfortable.

Well, but IDEs help to solve this problem right? Suppose you have:

class MathConstants
{
    public const double π = 3.14159265;
    public const double e = 2.71828;
    public const double α = ...
    public const double δ = ...
    public const double φ = ...
    public const double γ = ...
    public const double λ = ...
}

One would expect that typing in the IDE would give me a list of mathematical constants MathConstants.after the point and thus save me from typing them, but in most IDEs that I used at that time, in the best of cases, a list of unknown characters ( or ), I even used a version of Eclipse that would quit (without saving changed files!) if I opened a list of members of an object with weird identifiers , so I ended up changing the code to:.?□

class MathConstants
{
    public const double Pi              = 3.14159265;
    public const double Euler           = 2.71828;
    public const double Phi             = ...
    public const double EulerMascheroni = ...
    public const double Conway          = ...
}

In addition to being more friendly with the IDE, it meant that I didn't have to learn the Greek alphabet and is more explanatory than single-letter variables.

3) Coding and versioning systems.

Another problem that I have experienced with strange characters in the source code (either in comments or in identifiers) is that when uploading the code to the version control system , the files with strange characters were corrupted and when checking-out or updating everything stopped compiling.

Normally this problem came from the different text file encodings between platforms (I usually work on Windows and host the versioning server on Linux) it is solved by properly configuring the version control system and taking into account the characteristics of the platform on which the version is installed. code server is hosted... or just not using weird characters .

Summary.

The font Ñ ñis just the tip of the iceberg in a somewhat more complex problem that is the use of unicode characters in source code. These characters can cause problems without adding a significant improvement to code quality, so their use can be considered a small improvement for a big problem.

On the other hand, if we allow letters from the Spanish alphabet like eñe or ce with cedilla ( ç), we have no reason to ban letters in other languages, which easily escalates to bigger problems. If we work in an international team some programmers will feel more comfortable programming in their language and that is good for them and bad for the team (sorry Pavlov, I can't stand your comments in Cyrillic)... and this is not to mention that each country can have different keyboards or that the IDE that we use may not be prepared to work with these characters or even these characters drive the compiler crazy .

And even if we do not work in an international team, we must consider that most programming documentation is in English, if we have code written with exclusive characters in our language it will make it more difficult for the international community to understand our code when we ask for help on it. .

Conclusion.

I don't see a significant advantage in using Ñor any other exotic character in the source code, but as long as everyone working with such code is comfortable I don't see any reason to ban it either.

It is a highly debated issue. Most of us programmers indeed have a tradition of avoiding "weird" (non-ASCII) characters in identifiers (even filenames...)

On the "ASCII-only" side: that tradition feels healthy. Potential conflicts with different encodings are avoided when developing as a team (eg: some developers use UTF-8, others ISO-8859-1, others UTF-16...) or even when compiling (the compiler must agree to the editor. It's also healthy for when you want to share code (snippets) or ask questions on public sites that are handled mainly in English (SO, without going any further). [*]

On the "anything goes" side: we are in 2016. Most languages ​​(C# among them) support identifiers with Unicode characters without problems. And Unicode should no longer be a mystery to any non-beginner programmer, and all programmers in Spanish should be aware that when we edit a text file (potentially with non-ASCII characters) we are using a certain encoding (and we always have to decide it ourselves). input, don't let our operating system or our IDE do it for themselves). From this point of view, using Unicode in identifiers is, in a certain way, advisable: because it forces us to be aware and consistent in the encodings (and to become familiar with Unicode, if we had a dislike for it before).for the source code.

For my part, I see no objections against using añoas an identifier in C#. But if you do that, and when I ask "What encoding are you using for your source code?" you don't know how to answer me, then yes we are in trouble.

[*] Note, in passing, that most of these arguments would also discourage the use of non-ASCII characters not only in identifiers but in literal values ​​and even in comments - which seems too restrictive.

I am late, but I would like to contribute my grain of sand to this matter.

In my opinion, you should avoid using non-ASCII characters in the identifiers of the code... it is that you should directly avoid using the Spanish language. Everything should be in English. We are in a globalized world, especially in the field of software, and you never know who will be working on your code in the future.

In the case of open source projects, the thing is quite clear: the code will be available to everyone from the first moment and it would be a real shame if all the programmers in the world who do not speak your language are not able to examine it - and therefore they will not be able to send you improvement suggestions or pull requests (which is also bad for the code author himself).

But even in the case of proprietary code developed by a small company that has a single office and all employees are local, it is beneficial to have all the code in English. What if in five years the company has grown and decides to hire remote employees in other parts of the planet? What if an English man comes to live in Spain and it turns out that he is an excellent programmer and he wants to work in your company (I have experienced this)? If the code is in Spanish, it will only be possible to hire Spanish-speaking employees.

And there is another question: if you want to paste part of the code on a website to ask for help (be it the original Stack Overflow, or a company support forum) and you have everything in Spanish, you will have to translate everything every time.

This is how I see it, all my code has been 100% in English for years and I have found that all are advantages. But I understand that not everything is black or white in life, and there will be circumstances in which the code must necessarily be in Spanish for whatever reason. In these cases I agree with PaperBirdMaster: I would avoid any non-ASCII characters like the plague, and write "year" as "year". Programming is already complicated enough and the tools (IDEs, repositories, continuous integration environments...) already cause enough problems by themselves, without risking problems with the encoding of the source files.

Short answer: program always in English . Do not put "año", nor "annio" much less "ano", but "year".

Some advantages:

• It is more compact than other languages ​​(" driver " vs " driver ").
• If you want to share your code, English is universal.
• If you copy functions in English to add them to your code, you save on translating them.
• Normally, the APIs are usually in English, so programming in the same language improves uniformity and readability (" upload(fileTest) " vs " upload(testFile) ").
• You get used to it right away.
• Oh, and you save yourself the hassle of ASCII characters > 128.

As you say, there are no restrictions in terms of C#, but there are culturally. If you are sure that your work team will always be in Spanish, you can use the Ñ. Now this is going to lead you to think about what to do with the accents, that's where it gets a little more complicated, since not everyone knows the use of accents well and it can lead to there being different variables declared that want references to it. object.