Should I write my program in English or Portuguese?

Question

When I am writing programs, I usually write the names of variables in English (for example, fields, class_name, rec_number), for a number of reasons:

• Names in English don’t have accents, so there’s no strange business like pontuacao
• The names are usually smaller (ref)
• The code may one day be maintained by someone who does not speak Portuguese
• Apis are almost always in English

But there are other things I prefer to keep in Portuguese, especially if it is from the context of the system. Comments, class names or tables, for example, class Funcionario.

For this reason, sometimes the names in Portuguese are mixed with English, for example, there may be a class FuncionarioListView. While it’s perfectly understandable, it seems strange to me.

Also taking into account that every programmer should have basic notions of English, which is the preferred method for choosing the language I should use when programming?

What are the advantages of choosing one method or the other?

Answer 1

To answer this question, you must determine at least 4 factors (listed here in descending order of importance, in my opinion):

1. Is it an internal project [of your company, for example], or something to be exposed to the general public? (even if it is only the API)
2. Who will work on this project (employees? volunteers from any part of the globe?) and what is your mastery of English?
3. What is the field of application of your project? (i.e. what problem does it solve) This domain is something highly localized (e.g., something that needs to comply with local laws or regulations), or has a global character?
4. The programming language / framework / library is overly verbose, or has conventions repeating many names in English?

Visibility

Very few projects are aimed at a global audience, or at least are successful in achieving that goal. The vast majority of projects are to solve internal problems, and the resulting software never leaves the company. Of the rest, many others are closed source, so that even though the software is disseminated its source code is not. And finally, there are projects that - even open source - rarely receive contributions other than from their author/team.

If your project fits one of the above conditions, and if there’s an advantage in developing in Portuguese (more on this later), then it is counterproductive to adopt English only because of the remote possibility of someone who does not master Portuguese needing to touch it in the future. Especially if, by being in a foreign language, he ends up receiving a worse quality documentation - something that will bring more burden to understanding than the simple names in the source code. Since, strictly speaking, they are mathematical variables, they could be replaced by x, y and z and the logic of the algorithm would remain unchanged (I’m not saying that this would be a good idea...).

Contributors/Employees

Those of us who master English have a facility to "recognize" certain names that those who do not speak English do not have. If we see in a code Handler, Listener, callback, etc, we already know purpose behind these variables (manipulate an event, listen to [be notified of] a change of status, get back a call [of the function being invoked], etc.), although we do not yet know the details. The simple choice of name already sends us a lot, greatly facilitating the understanding. And if we want a method to read a file, for example, we have already searched in the index by the letter "R" (read).

It’s hard for us to imagine how non-speakers feel, but anyone who has worked with [or taught classes to] people without a command of English knows how high the language barrier is, and how much more effort that entails in having a similar performance. This means that if whoever moves your code does not possess this "ideal skill", your team will be less productive. You (if employer) will have to pay more and receive less [by the extra number of developers, although each of them earn less by not mastering English]. Even if you put as a requirement for hiring fluency in English, the number of potential candidates will be lower, making it more difficult to fill a vacancy.

This can be mitigated by the use constant and efficient of Portuguese in its code base. The keywords of the language can not change, but at least the common methods and classes (every project has a library "useful", no? ) can be given simple and consistent names, which refer to concepts that its developers already know - or metaphors that aid understanding (as there is for example the throw and catch, although managing exceptions has nothing to do with baseball...).

The opposite strategy, translate into English terms already well known and consolidated (do not forget that the specification of requirements probably will be in Portuguese, since it is the "bridge" between customers and the development team), can raise even more the difficulty of development, especially in a team (I "memorized" the term "Foo" which is used in my code, but my colleague wrote an excerpt using "Bar" which interfaces with mine. What will be "Bar"? ). That is, if you choose to develop in English, be prepared to assemble a team where everyone is fluent in both English and Portuguese [if applicable].

Domain

This section is self-explanatory. If I have to generate the reports DARF and DEGREF, with all its fields already expressed in Portuguese, it would make no sense to use variables in English. And its want to manipulate the GIFT via a library Xpath, will not help to translate the concepts into English...

(Note: both things can occur in the same code - if my DEGREF is represented in XML, first I create a variable node_list to locate my elements, then convert them into a lista_despesas; unless you are explicitly prioritizing Portuguese - for the reasons mentioned in the section above - in which case maybe it is appropriate to use lista_nós)

Conventions

This part is controversial as many languages use the principle "Configuration convention" (Convention over Configuration - Coc), sometimes getting to impose certain conventions such as quasi-mandatories or in fact mandatories (e.g.: you can create a Java Bean using obterFoo and atribuirFoo, but many automated reflection tools will not be able to recognize Foo as a property). Others do not have this type of retribution, uncontacted the names of your semantics (e.g.: in C# you create blocks get and set for a property, but the class consumer code uses its simple name without mixing).

If your tool (language, library) is heavy in Coc, indeed mixing English with Portuguese gets weird, and should be avoided for every common concept. Concepts pertaining to the domain, on the other hand, can justify the "weird" - since the association "this field of the screen is represented by this variable" is easier when using an appropriate nomenclature.

There is also the case of abbreviations, for example IFoo ("Foo" interface), which I personally consider a reasonable concession when name-functionality coupling is unavoidable (I recognize that in certain cases it promotes improved understanding). In this case, the abbreviation ends up becoming the element that refers to the concept, so that when you see the "I" you already think "Ifoo has no concrete methods" - instead of there being an indirect association, as "Ifoo is an interface, and interfaces have no concrete methods".

Because of this "understanding shortcut", I see no problem in using names in Portuguese with abbreviations in English (ex.: FuncionarioLV extends ListView), since the "LV" in the name works almost like a secrecy, with the same advantages [and problems] that this entails.

---

Completion

There is no problem in writing programs in Portuguese, as long as it is well done. Particularities of the project may require one or another language, and this will not occur without costs. What should be avoided is the reductionist thought that "it has to be in English because who 'dominates' uses English", because if that were so we would all be speaking Latin...

Answer 2

Describing certain actions in English is much easier, ex:

setName(string name)

Already in Portuguese:

• setNome, mixture English with Portuguese.
• setarNome, neologism in the word set.
• atribuirNome, a little great to write/read besides making room for certain variations (preencherNome, colocarNome, etc.).

In addition to other advantages (in English):

• Possibility for anyone (different nationalities) to work on their code (essential if open source).
• It’s much more consistent with the names of the Apis/frameworks you’ll use, which are probably in English.

Anyway, after all, writing English is advantageous in my opinion. But for this the rest of your team has to know how to write/read well in English (not to be more a difficulty).

And of course, be consistent. Take a shape in your project and keep it.

Answer 3

I think it depends on the project.

If it’s an open source project, using only English is more appropriate, especially if the code is available on some global site like Github. If it’s a closed project, played in a national company, with a Portuguese speaking team, I don’t see a problem using Portuguese - unless the whole team thinks it’s best to use English. If there is someone on the team who does not know English well, naming everything in this language can even get in the way.

And I try to avoid the two languages as much as I can, but it’s hard to avoid. The example you quoted seems acceptable to me, because Listview is almost a proper name. But I would avoid something like getFunctioning.

Answer 4

Use English (whenever possible)

Portuguese is your native language, so you will have less doubts about the language to develop your projects. The moment you are developing is not the ideal time for you to learn a new language.

Imagine that instead of creating classes Empregador and Funcionario you decide to create classes Employer and Employee, which are the translations respectively. Ever wondered if someone from your team exchanges the balls and puts an employee in the place of an employer or vice versa? The chances of error increase considerably.

Every programmer knows the basic words of English: if, switch, class, set, get, etc; but the other words will depend on the knowledge of each one in English. Imagine if you need to create variables that the names are false cognates? Have you thought about the confusion brewing? I wouldn’t risk adding bugs to my project for communication problems within a team that everyone speaks Portuguese natively. Tell me, why complicate?

As to the setNome, setEndereco, I don’t see the problem with that, since set and get are conventions that we constantly use to make our getters and setters, these words are (or should be) as natural to developers as any other reserved word.

Answer 5

As a professional you are trying to achieve your best, and the best in this case is English.

Sometimes you are a member of a team and it is not up to you to decide this, but you should make your opinion clear.

I usually force myself to describe everything in English, including comments, domain entities, everything. I also encourage other people to do the same.

Perks

1. This improves your English
2. Language uses constructions in English which makes reading more natural and Homogenia.
3. Almost all literature comes out in English rather than Portuguese, all new technologies come out in English before, the best books, the best blogs are in English . If you read enough books technicians, the best authors probably wrote everything in English .
4. Many things in life create more freedom and more possibilities. Learning to walk, to read, to communicate efficiently, to learn to drive all these things generates that. With English is the same thing, it will give you more professional and personal freedom.
5. You stop thinking that your software will be alone in the company and start thinking that your software can reach other places. Anyway you’ll already be ready

In short:

If you are worried about improving as a professional do not accept to do things by the average.

There is a post interesting about this on Akita’s blog that I recommend.

Answer 6

If you are a programmer and the rules are already set by hierarchically superior people, you can only follow them.

Now, if you are responsible or are one of those responsible for defining these rules, you should analyze yourself, your environment and the best cost-benefit of each choice.

By the way, I don’t think you should limit yourself to choosing between "Portuguese" or "English". Standardizing code writing is something that goes beyond that; for example, you can define which method and function names will always start with verbs and which acronyms will always have only the first uppercase letter (such as Html).

I suggest thinking that way, and not just getting in doubt between "English" and "Portuguese".

Try to identify needs and try to make a list of requirements to address as many problems as possible:

• Do you work on a team? If so, what do team members think of each choice? Do they have enough proficiency to write in English? Do they have enough proficiency to write in Portuguese? They know or want to use a translator?
• Consistency and simplicity: In general, making a simple and consistent definition and following it correctly is desirable as it facilitates programming: consistent and simple patterns allow programmers to easily deduce variable names, classes etc.
• Pre-existing Standardization: Eventually, you can work in a company that already uses a certain standardization for various projects and libraries that will be used in your project. Thus, following the same existing rules - if they are satisfactory - may be desirable.
• Culture: Depending on the language you are using, there may be a culture the programmers use a certain type of standard. In this sense, following this pattern can bring several benefits, such as facilitating the integration of a new programmer already accustomed to the culture of language in the project.
• Some other more specific requirement for your case: sometimes you simply have a boss who prefers one way and not another; even if he doesn’t actively participate in the project. ;)

In general, there is no situation where using a certain "win" approach in all of these requirements; it is up to you to analyze and figure out which of these requirements are most important and choose from it. Still, thinking this way helps you report and justify your choices if there is such a need. For example:

I chose to use names in Portuguese because 30% of the team’s programmers do not know English, and the other 70% see no problem using Portuguese.

Answer 7

I believe it depends on the team you work on.

I prefer programming in English (among other reasons, to avoid mixing languages and to avoid strange neologisms), but there are people on my team who do not like it (they say that if we are in Brazil it has to be all in Portuguese...).

And in addition to your current team, you need to take into consideration that the next team that will maintain the code may not understand almost anything in English, or on the contrary: they may be used to international standards and may find adaptations to our language strange (I for example, until today strange when I see "dese" instead of "dev" to refer to development/Development).

At the end of the day, the most important thing is the readability of the code (at least that is my opinion).

Answer 8

It is common to merge the languages as you mentioned in the example "Functionary class", but a good practice is not to mix the languages in the same name as "Funciolistview", only that at the same time you contradict yourself in one of the points that raised "The code can be maintained by someone who does not speak the Portuguese language", when this is taken into account I believe that one should code only in English.

Answer 9

As much as you know English, it can be a trap in large programs that have unusual relationships, actions or objects. In the world of "codes," you will eventually ask yourself, "What is this called?" and waste time searching. If you are like me (you want to see it work soon), you will mix the languages. Of course, the same problem occurs in English, but it is easier to find, correct, or refactor if named within a pattern. However, if it is a code for the community, there is no way: it has to be English.

Answer 10

Yes, seeing the mixture of languages ends up being natural because we speak Portuguese, and almost all environments and programming languages are based in English. I believe that the best thing for these cases is to try to use the nomenclature in English because all the terms of the language are also in English, so as not to generate the mixture of languages. But that’s a matter of opinion :)

Answer 11

By default, good practices, and aiming at a higher maintainability of the code, the most recommended is in English.

But it depends on one simple factor: what you’re using to develop?

English

Whether you like it or not, English is the universal language. With this, it is highly recommended that from now on (even more who works with IT), you know at least technical English.

This facilitates in turn, you find tutorials on the internet, new jobs, participate in a project abroad, etc.

Therefore, besides being practically a prerequisite for our area, creating something in English allows you (and your project) to have the participation of anyone in the world, in this case a GREAT ADVANCE, such as projects open source on Github.

---

Team

The ideal is to talk to your team, to enter into a consensus, so that the project is not harmed by simply name methods and/ or comments.

---

Frameworks

MVC

The vast majority of frameworks are in English, and are prepared to understand everything you create (controllers, models, views) in this same language. So, if your controller is called Users, most of the time the framework will not understand that your model will be called User.

Database

Most code generators perfectly understand their tables if they are named following their convention and in English. With this, if you have a table that is called users, it will already quietly create your controller (Users), model (User) and views (Users/show, Users/Edit, Users/create, Users/index).

---

Tip

In projects that I have already worked on, so that the development would be faster, we chose (me and the team) to keep the nomenclature of everything in English, as well as suggests great parts of the frameworks.

However, all comments were in Portuguese, thus facilitating understanding by team members who did not master technical English.

---

I hope I’ve helped.