To answer this question, you must determine at least 4 factors (listed here in descending order of importance, in my opinion):
- 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)
- Who will work on this project (employees? volunteers from any part of the globe?) and what is your mastery of English?
- 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?
- 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...
This depends on the much of the taste, sometimes you are obliged to follow the standardization of the company or the project, the important thing is NOT MIX STYLES.
– rray
No matter what pattern you follow, as long as you have one.
– Daniel T. Sobrosa
I usually do everything in English. For cases like
Funcionário
,Empresa
, I useEmployee
,Company
,... which is quite easy and obvious. But sometimes it becomes a little difficult to find some terms like CNPJ. In this case I use something generic likecompanyIdentificationNumber
, and in the variable statement or in the SQL script (if it is a database field) I put some comment like:// company identification number used for tax paying purposes
 // CNPJ (Brazil), CUIT (Argentina), EIN (Employer Identification Number in USA), ...
 String companyIdentificationNumber;
– Ecil
I understand there may be differences in style and personal opinion, but I really hoped there would be a Guideline or best practices.
– augustomen
@Augustomen Unfortunately, I don’t know anyone who is authoritative in order to publish a Guideline which was accepted by consensus in the face of so many divergent opinions. I didn’t see it either in college or in industry. I know arguments against and in favor of the use of English and even of the mixture, but nothing "cut in stone". If the question should ever be reopened, I intend to make my contributions, but as much as I try to be objective I fear it would be just one more opinion among so many...
– mgibsonbr
Just an aside, independent of this whole discussion: there are languages (like Scala) that accept accents in their identifiers, allowing, then,
pontuação
.– Daniel C. Sobral
I worked in a company where my team had people with problems with English, the projects were written in Portuguese. IE, if English is a problem use Portuguese, otherwise prefer English, will be consistent with the language itself, Frameworks, Third Party Libraries, etc.
– BrunoLM
Once an acquaintance who’s a project manager at Yahoo! said the first thing to do to become a programmer/analyst/handsome name is to speak English. 99.9% of everything done in computing is in English. Prefer English, when it doesn’t work, use whatever is most logical.
– Sfamcks