Escrevo código por um bom tempo e não vejo significativas diferenças quanto a escrita do código em inglês para o português, ainda sim parece mais natural a leitura e composição dos nomes em língua inglesa até por conta de padrões adotados como os (beans) get e set e o uso de prefixos como is por conta de não ser possível a utilização de acentos onde e e é não são distinguíveis, também tomo a questão da composição de nomes se livrando de conjunções que na língua inglesa são menos utilizadas.
Li no livro Código Limpo de Robert C. Martin que quanto mais linguagens mais complicado o entendimento, isso se refere tanto as escrita de identificadores, comentários quanto a sub-codificação (metaprogramação) (exemplo: fazer um código em java que escreva HTML diretamente, ou o famoso caso de css, codificação de javascript, e outros dentro de um mesmo código HTML.
Afinal, o que acham mais correto e prático, escrever código em linguagem compatível a da linguagem de programação utilizada ou escrever os identificadores em linguagem nativa do desenvolvedor?
[quote=DavidUser]Escrevo código por um bom tempo e não vejo significativas diferenças quanto a escrita do código em inglês para o português, ainda sim parece mais natural a leitura e composição dos nomes em língua inglesa até por conta de padrões adotados como os (beans) get e set e o uso de prefixos como is por conta de não ser possível a utilização de acentos onde e e é não são distinguíveis, também tomo a questão da composição de nomes se livrando de conjunções que na língua inglesa são menos utilizadas.
Li no livro Código Limpo de Robert C. Martin que quanto mais linguagens mais complicado o entendimento, isso se refere tanto as escrita de identificadores, comentários quanto a sub-codificação (metaprogramação) (exemplo: fazer um código em java que escreva HTML diretamente, ou o famoso caso de css, codificação de javascript, e outros dentro de um mesmo código HTML.
Afinal, o que acham mais correto e prático, escrever código em linguagem compatível a da linguagem de programação utilizada ou escrever os identificadores em linguagem nativa do desenvolvedor?[/quote]
Eu pessoalmente acho que escrever em outra lingua que não seja inglês é jogar dinheiro fora. Vc não sabe onde o codigo vai parar. Vc gostaria de receber um codigo escrito em japonês ? Não, né ?
Se escrever sem ser em inglês, mais cedo ou mais tarde isso via causar problemas. E quando maior for o sucesso do software, mais problemas dá.
Imagine o codigo do Photoshop que foi aberto recentemente e estava em japonês. Seria legal ? Não.
O sergiotaborda deu bons motivos para escrever em inglês.
Para fazer o contraponto, vou dar um motivo para escrever em português.
Sua equipe de desenvolvedores não tem fluência no idioma.
É difícil achar bons desenvolvedores. O inglês torna ainda mais difícil.
Você cria uma barreira artificial para entenderem o código.
Um outro motivo é se você tentar usar uma linguagem ubíqua entre seu projeto e o cliente. (Considerando que seu cliente fala português).
Os termos de negócio serão em português e você terá que fazer um de-para para termos em inglês.
Eu também concordo que é melhor que o código esteja em inglês.
Motivos:
1 - Na minha opinião o código fica bem mais file em inglês.
2 - Qualquer pessoa do planeta poderá ler este código se conhecer inglês.
3 - Português tem acentos e você é abrigado a definir os identificadores e métodos sem acentos o que fica muito feio.
4 - Obriga a você a aprender inglês e no final você acaba tendo mais facilidade para entender código dos frameworks.
Se o projeto é interno não faz sentido complicar só por preciosismo ou ficar pensando em futuro improvável, só traz desvantagens, fica confuso “falar” diferente da língua do cliente.
[quote=AbelBueno]Para variar, acho que isso depende.
O sergiotaborda deu bons motivos para escrever em inglês.
Para fazer o contraponto, vou dar um motivo para escrever em português.
Sua equipe de desenvolvedores não tem fluência no idioma.
É difícil achar bons desenvolvedores. O inglês torna ainda mais difícil.
Você cria uma barreira artificial para entenderem o código.
Um outro motivo é se você tentar usar uma linguagem ubíqua entre seu projeto e o cliente. (Considerando que seu cliente fala português).
Os termos de negócio serão em português e você terá que fazer um de-para para termos em inglês.
[/quote]
Concordo com o AbelBueno. Depende.
Escreva o código de forma que seja mais natural para você, para sua equipe e também para seu cliente.
Imagina você apresentando um modelo de dados para seu cliente com termos comuns do negócio dele traduzidos para uma lingua estrangeira.
[quote=AbelBueno]Para variar, acho que isso depende.
O sergiotaborda deu bons motivos para escrever em inglês.
Para fazer o contraponto, vou dar um motivo para escrever em português.
Sua equipe de desenvolvedores não tem fluência no idioma.
É difícil achar bons desenvolvedores. O inglês torna ainda mais difícil.
Você cria uma barreira artificial para entenderem o código.
Um outro motivo é se você tentar usar uma linguagem ubíqua entre seu projeto e o cliente. (Considerando que seu cliente fala português).
Os termos de negócio serão em português e você terá que fazer um de-para para termos em inglês.
[/quote]
Concordo contigo. E as vezes, mesmo conhecendo inglês, é complicado fazer a tradução de partes muito específicas do negócio.
Mas mesmo escrevendo em português, algumas coisas eu misturo em inglês. Em métodos que retornam boolean, prefiro usar is ao invés de “eh” (isEmissor ao invés de ehEmissor). “And” ao invés de “e”, usar “e” na variável fica ruim por causa do camel case.
Se é um produto que tem a possibilidade de se espalhar pelo mundo (por exemplo um framework ou um software de prateleira) o melhor é escrever tudo em inglês, conforme as boas razões que colocaram aqui.
Já no caso de sistemas internos, feitos para a necessidade do cliente, com regras de negócio específicas da empresa, escrever tudo em inglês pode ser um pouco de preciosismo.
A tradução de termos de negócio fica muito estranha. Por exemplo um caso simples , se você trabalha com um campo que é o número de R.G. de uma pessoa, como traduzir isso se não existe um correspondente universal? Cada país tem suas regras e seus documentos para identificar um cidadão… eu posso traduzir a palavra mas de que isso adiantaria para alguém de outra cultura? Eu poderia fazer todo um trabalho para tornar a identificação da pessoa genérica, o sistema com regras flexíveis para adaptar a outros países… é possível, mas tem que se ver se é isso que o cliente precisa.
Inclusive muitas grandes empresas tem padrões de codificação em língua portuguesa.
(Mesmo nesse caso de usar os termos de negócio em português ainda é melhor manter os termos “técnicos” em inglês, como os métodos acessores, sufixos que identificam patterns, etc)
Outra coisa:
Para trabalhar com código em inglês é preciso ver se existe qualificação na equipe para isso. Em um projeto, um cara (o Mr.J) decidiu que o código seria todo em inglês, e ele mesmo lançou algumas pérolas como:
Traduzir ofício (carta de autoridade) para OFFICE
Solicitação (um pedido de relatório feito pelo usuário) virou SOLICITATION (a palavra até existe, mas tem um contexto diferente)
A famosa flag de “ativo” no usuário foi traduzida como ACTIVE_MALE (Isso mesmo! O cara usou o sentido sexual da palavra)
[quote=gomesrod]Se é um produto que tem a possibilidade de se espalhar pelo mundo (por exemplo um framework ou um software de prateleira) o melhor é escrever tudo em inglês, conforme as boas razões que colocaram aqui.
Já no caso de sistemas internos, feitos para a necessidade do cliente, com regras de negócio específicas da empresa, escrever tudo em inglês pode ser um pouco de preciosismo.
A tradução de termos de negócio fica muito estranha. Por exemplo um caso simples , se você trabalha com um campo que é o número de R.G. de uma pessoa, como traduzir isso se não existe um correspondente universal? Cada país tem suas regras e seus documentos para identificar um cidadão… eu posso traduzir a palavra mas de que isso adiantaria para alguém de outra cultura? Eu poderia fazer todo um trabalho para tornar a identificação da pessoa genérica, o sistema com regras flexíveis para adaptar a outros países… é possível, mas tem que se ver se é isso que o cliente precisa.
Inclusive muitas grandes empresas tem padrões de codificação em língua portuguesa.
[/quote]
Ha aqui uma confusão entre o codigo e o modelo. Nomes não se traduzem. RG é RG sempre. Tentar identificar um identificador universal é Localização ( L10n) da aplicação. Isso é um esforço de modelo, não de código.
Programar em Inglês não significa encontrar um correspondente universal. Isto que fique claro.
Em relação às pessoas não saberem inglês. Aprendem. E não é preciso aprender inglês em si, apenas algumas palavras. Afinal Java tem palavras em inglês (extends, interface, class, return, final, public, etc…) e ninguém diz “o cara não consegue aprender java porque está em inglês” . Essa razão é absurda.Não se pede aos juniors que pensem em inglês. Apenas que usem certas keywords. E não ha diferença entre a “keyword” List e Custumer.
Esse negocio de linguagem Ubiqua. Tudo muito bonito, mas é quando o cliente realmente está envolvido de verdade. Isso é raro.
Por outro lado, para quem escreve código para outrem ( o código é o produto e não o software em si) é preciso perguntar ao cliente em que lingua ele quer. Isso resolve o problema. Se o cara não tem visão e pede em portugues e daqui a 10 anos quer mandar para a india para um upgrade, o problema é dele.
Para quem faz código interno para a própria empresa o problema é o mesmo, a empresa decide.
Código é um asset. É um investimento. Proteger o investimento é a prioridade numero um de uma boa gerencia. Se a Gerencia decide que em PT protege melhor o investimento, que seja. Mas não nos engamenos achando que é uma questão de gosto, ou de medida de esforço.
Em termos de modelagem é melhor fazer o exercicio em outra lingua, se possível em 3 línguas. Isto porque ajuda a identificar conceitos de forma melhor. Colocar “Client” em vez de “Cliente” é um erro. E se for continuar fazendo esse tipo tradução é melhor não fazer mesmo. O conceito qual é ? “Custumer” : Consumidor. Um consumir entra no site para comprar um produto.
Eu ainda brigo com a palavra Usuário que não é a tradução de User. A tradução de User é “pessoa que utiliza um serviço”, ou seja , Utente.)
Usuário é
[quote]adj. s. m.
2. Que ou quem possui ou frui alguma coisa por direito, que provém do uso.
s. m.
3. [Brasil] Pessoa que faz uso do computador, de programas, sistemas ou serviços informáticos. = UTILIZADOR
[/quote]
Quando vc usa o metro, ou usa um sistema, isso não é um direito. Vc paga. Então vc é um Utente.
[quote]adj. 2 g. s. 2 g.
Que ou aquele que usa ou que tem o direito de usar. = UTILIZADOR
[/quote]
Os nomes não são apenas uma questão de modelo, gosto ou negocio, são também uma questão cultural. Faça um ERP sem leval isso em conta e vai ter o mesmo problema que a microsoft , a SAP e outras , que tinham seus ERP lá fora e chegam aqui e tem que jogar fora porque é muito diferente. E ele foram re-escrever o nome das classes ? não.
Ou seja, se não sabe fazer, não tente. Se tem dúvidas pergunte a quem lhe está pagando. Não assuma que é uma problema técnico. Não é. É um problema de comunicação.
É simplista colocar razão de “a equipe entende melhor”. Isso é importante, mas não é o mais importante.
Então você não traduz os nomes e traduz o verbos? e transforma o código em um mistura completa?
Terá um código cheios de métodos updateRg, processContratos, calculateNotasFiscais ?
Qual a vantagem?
Concordo que todo desenvolvedor deveria aprender inglês. Mas essa não é a realidade por aqui. Vou deixar de contratar por isso? Ninguém vai aprender da noite por dia, então se for requisito, vai tirar muita gente.
Java tem 50 palavras reservadas. Qualquer programador vê essas palavras todos os dias, se acostuma por elas.
Os nomes em um domínio vão aparecendo a cada nova iteração.
Nem é necessário o cliente estar tão envolvido. Só o fato dos nomes no código refletir o jargão técnico do cliente já ajuda muito.
Concordo que o cliente tenha direito de decidir a linguagem, e em sistemas internos é o que vejo acontecer.
Só vejo o código como o produto em si no caso de frameworks ou libs genéricas.
Nesse caso concordo que faça mais sentido serem em inglês.
Acho que não entendi seu ponto de vista aqui. O código não tem valor sozinho, só quando tem um propósito.
Se eu achar uma lib pronta que faz tudo que meu código atual faz com melhor qualidade (menor uso de memória, mais desempenho), eu troco meu código facilmente.
O fundamental é garantir que o usuário complete o processo dele…não importa o código.
[quote=sergiotaborda]
Em termos de modelagem é melhor fazer o exercicio em outra lingua, se possível em 3 línguas. Isto porque ajuda a identificar conceitos de forma melhor. Colocar “Client” em vez de “Cliente” é um erro. E se for continuar fazendo esse tipo tradução é melhor não fazer mesmo. O conceito qual é ? “Custumer” : Consumidor. Um consumir entra no site para comprar um produto. [/quote]
Por que 3 línguas? Qual vantagem prática isso traz?
Para customer é fácil, deve fazer parte de 50% dos sistemas por aí.
Quando começa os termos relativos a um negócio específico, até achar a palavra exata para isso, são alguns minutos/horas perdidos em uma pesquisa sem sentido.
[quote=sergiotaborda]
Os nomes não são apenas uma questão de modelo, gosto ou negocio, são também uma questão cultural. Faça um ERP sem leval isso em conta e vai ter o mesmo problema que a microsoft , a SAP e outras , que tinham seus ERP lá fora e chegam aqui e tem que jogar fora porque é muito diferente. E ele foram re-escrever o nome das classes ? não.
Ou seja, se não sabe fazer, não tente. Se tem dúvidas pergunte a quem lhe está pagando. Não assuma que é uma problema técnico. Não é. É um problema de comunicação.
É simplista colocar razão de “a equipe entende melhor”. Isso é importante, mas não é o mais importante.[/quote]
Para mim sua conclusão contradiz o que disse antes.
O problema é justamente de comunicação. O fato da equipe entender melhor ajuda MUITO a comunicação.
Se o cliente quiser um sistema internacional, ótimo, faz sentido escrever em inglês.
Se ele não faz questão, qual o ganho em complicar? Criar barreiras sem qualquer vantagem prática?
Ha aqui uma confusão entre o codigo e o modelo. Nomes não se traduzem. RG é RG sempre. Tentar identificar um identificador universal é Localização ( L10n) da aplicação. Isso é um esforço de modelo, não de código.
Programar em Inglês não significa encontrar um correspondente universal. Isto que fique claro.
[/quote]
Então você não traduz os nomes e traduz o verbos? e transforma o código em um mistura completa?
Terá um código cheios de métodos updateRg, processContratos, calculateNotasFiscais ?
Qual a vantagem?
[/quote]
O ponto é que existe uma diferença entre codificar em inglês e localizar a aplicação.
Eu não programo dessa forma. Se o potugues está disponivel para uso, então ha que haver coerencia e escrever AtualizarRG e CalcularNotafiscal.
O que vc pode fazer é não usar os nomes RG e NotaFiscal que são especificos, então seria UpdatePersonCode e CalculateInvoiceTaxes. E a escolha de PersonCode é uma abstração e não uma tradução ou uma localização. Não me importa realmente que código é aquele, desde que servia o meu proposito de identificar a pessoa. Se quiser ser muito especifico vc usa UpdataBrazilianGeneralRegestryCode e ai vc deixa claro que é um campo que só faz sentido no brasil e está ligado a uma coisa chamada “Registro Geral”, seja lá o que isso for.
O ponto é que a ferramenta é a abstração e/ou simples tradução das palavras sem intenção de localizar o modelo.
É óbivo que nenhum modelo é suficientemente rico para ser ser autoexplicativo, mas se um indiano tiver que dar suporte naquele código pelo menos ele tem uma ideia de para que serve o campo.
Se seu sistema tem mais de 50 entidades, vc tem problemas. Se tem menos, é facilmente decorável, tal como as 50 palavras do java.
“eu troco meu código facilmente” … não se vc não o entender , seja porque está escrito numa língua que vc não conhece, seja porque tem um modelo que vc não conhece. E o tópico aqui é a lingua.
Se lhe derem um sistema em uma lingua q vc não conhece , vc não consegue alterá-lo facilmente. E se vc não tiver o código, vc não consegue alterá-lo.
Se vc perde o código vc perde toda a capacidade do modificar seu sistema, não apenas para o corrigir, mas para o evoluir. Todo o dinheiro que vc investiu vai para o lixo. Se vc precisa modificar alguma coisa, vc precisa escrever outro código.
O código é o software. Se vc não protege o investimento no código vc está - mais cedo ou mais tarde, lascado. É por isso que o open source existe. Não apenas vc consegue colaboração mas vc mantém o investimento. E o investimento não é apenas dinheiro, é tempo, é intelectual, é várias coisas. É por isso que o OpenJDK é tão importante para a comunidade java. Tem muita coisas alí. Coisas que demoraram anos e esforço de muita gente inteligente para construir.
O executável é legal, mas sem o código é como ter um relógio contando os seus dias de vida.
O código é o que mais importa para quem paga pelo software. É o que ele pode modificar para obter melhores resultados. O executável é irrelevante se vc tem o código. E se vc perdeu o código, vc perdeu o know-how, o investimento.
Isto é uma questão económica, não técnica.
Porque o código é o seu maior asset é que muitas empresas têm dificuldade em entender o modelo open source. Para elas vc estar abrindo o código, é como um banco dando dinheiro ou a coca-cola divulgar sua receita completa.
Mas o fato é que existe várias formas de proteger o mesmo asset. E open source, embora vc não protega “o segredo”, vc protege o investimento, a longevidade, a segurança, a robustez, etc…
[quote]
Abstrair melhor. O ser humano só sabe raciocinar o que ele consegue nomear, mas linguas diferentes têm formas diferente de nomear , derivar nomes, derivar conceitos, e justapor conceitos. A justaposição em inglês é trivial. Se não fosse, garanto-lhe que a linguagem base para programação não seria o inglês. Em Portugues a justaposição é possivel, mas limitada em relação ao inglês. O mesmo a derivação que é essencial para nomear métodos e interfaces, por exemplo.
É claro que se vc usa linguas com a mesma raiz , talvez vc não consiga ter conclusões diferentes.
Um exemplo:
Diferença entre Design e Drawing. Em Portugues é Desenho e Desenho. Em espanhol é Diseño e Dibujo. Qual é a abstração correta ?
Se vc precisa dos dois conceitos em um mesmo código está lascado se usar Português. Pensar em 3 linguas permite uma melhor compreensão e abstração do conceito em causa.
É claro que isto é limitado pela cultura das pessoas e da equipe e é realmente dificil aplicar em dominios muito especificos, mas todos os domínios existem em todas as linguas, então é uma questão de pesquisa.
É como pintar. Vc pode usar uma palete de 255 cores ou uma de milhões. É uma questão de pesquisa e do nível de abstração que vc precisa.
[quote]
Mas a comunicação não apenas agora, com a sua equipe de criação. É também depois, com sua equipe de manutenção. É daqui a 10 anos quando a tecnologia ficar obsuleta e vc quiser usar o código como ponto de partida para outro sistema. É quando vc quiser modificar seu sistema porque uma nova oportunidade de negócio apareceu e vc precisa terceirizar para um out-source mais barato. Vc está focando no aqui e agora, para um asset interessa também o além e depois. Por isso que eu falei em gerencia. É uma questão de saber se vale mais fazer em 10 semanas porque o TTM é 20 ou se interessa mais perder esse prazo mas ter um produto que possa competir ano que vem, e no outro, e no outro… É uma questão de saber se vamos poupar na construção ou na manutenção, etc… É importante que a equipe do aqui agora, entenda, mas dependendo das conjecturas, talvez seja mais importante que a equipe do além e depois entenda também.