Padrão de Codificação

Oi pessoal,

[color=black] [/color]:slight_smile:

Eu e meus colegas estamos criando um framework utilitário e com foco específico, voltado para os brasileiros (nós). Na verdade, para usuários de língua portuguesa.

Bom, pensando em padrões de codificação e padrões em geral, queria saber a opinião de todos sobre a codificação ser em ?português rico? (acentuação, cedilhas, etc.). Lógico que padrões Java serão sempre mantidos como ?gets? e ?sets?. Mas nesse caso teríamos ?getInscrição()?, por exemplo, ao contrário de ?getInscricao()?. E padrões de projeto e outros seriam preservados pelo padrão (Inglês).

Poucos sabem, e os que sabem, poucos usam, mas, tanto na compilação como no javadoc pode-se informar qual o tipo de codificação do arquivo está sendo usado (UTF-8, ASCII, ISO-xyz, etc.). E dependendo de qual vc utilize, a representação será fiel e sem problemas. Isso melhora bastante a portabilidade e legibilidade do código (robustez da legibilidade).

Quer dizer, mais ou menos. Tivemos uma experiência com algumas ferramentas que fazem análise de código fonte, mostrando que tais ferramentas desconsideram a LOCALIZAÇÃO da língua; e também, não executaram sua função corretamente.

Então, resumindo, queria fazer algumas perguntas:

1- Seria bom ter uma biblioteca (voltada para a língua portuguesa) utilizando caracteres especiais de nossa língua?

2- O não reconhecimento de nossos caracteres por parte de ferramentas(IDEs, Framwoks, etc.) é falha nossa ou delas, não fornecendo a opções como: Idiomas, Codificação, entre outros?

3- Devemos evitar o processo de LOCALIZAÇÃO desperdiçando esse recurso do Java e diminuindo a legibilidade do código para nós?

4- Ou ainda, um código localizado com nossos caracteres especiais simplesmente não é uma boa idéia por que não é mais legível (esquecendo a pergunta 1)?

[color=darkblue] [/color]

Vou responder suas perguntas com outra pergunta:

O que acontece se um software desenvolvido no Brasil com sua framework cai na mão de um grupo de desenvolvimento de outro país?

aka não brasileiros.

  1. Não gostaria de programar usando ç e ã . mas é minha preferencia PESSOAL.

  2. Acredito que não é falha dela porque elas estão aí para atender o mercado. e o mercado não exige isso.

  3. Sempre prefilo legibilidade de código.

  4. Acredito que um dia um americano ou holandes precise mecher em um código que eu fiz, e vai ter bem mais dificuldades. prefiro programar em uma lingua universal.

Novamente reitero, PREFERENCIA PESSOAL.

abraços

Olha só,

Estou falando de um componente relacionado a coisas do Brasil.

Por exemplo, uma biblioteca voltada para assuntos bancários e de bancos brasileiros que, por sua vez, estão subordinados ou ligados à FEBRABAN (www.febraban.org.br). Provavelmente conterá coisas pertinentes somente ao Brasil como Boletos Bancários, CPFs, CNPJs, CEPs, Endereços…, etc. Então, aposto quem vai usar isso é Brasileiro. Se o desenvolvedor for estrangeiro, então irá de qualquer forma ter que saber qual a diferença de CPF para CNPJ. Ou não? Deveria escrever meu javadoc em inglês também?

Se no meu javadoc tem pessoa jurídica por que não escrever no código o acento (´) no í?

Agora convenhamos, uma biblioteca desse tipo vai ser usado massivamente por quem? Estrangeiros ou brasileiros?

Fica melhor,

getPessoaFísica ou getPessoaFisica

getInscrição ou getInscricao

setChequeCaução ou setChequeCaucao

?

Ou “getFisicPersson” sei lá o que em inglês :lol:

Lembrando que tudo isso vai para o javadoc também, que faz parte do conjuto do software, acho eu fica mais legível. Ou não? :?

Sei lá, mas em getPessoaFisica, o que menos me incomoda é a falta de acento.

De certa forma a inserção de caracteres especiais iria agravar o uso do código, muita gente ia perder tempo com erros de falta de acentos e coisa do tipo, não é muito útil, melhor colocar estes acentos apenas no javadoc.

cara… realmente nao acho uma boa ideia.
ja basta o cara ter que aprender java.
ter que aprender portugues ainda eh foda !

hahahaha
viu soh… nem quando nao estou programando nao coloco acentos… ainda mais qnd estou programando…

e se começarmos a programar com acento as IDEs terao que começar a vir com corretor ortografico. Só que quando programamos escrevemos palavras concatenadas, e aih, as ides vao tratar isso tambem? acho que seria soh mais um ponto pra gente reclamar delas neh…

e outra… quem tem teclado que nao tem o suporte a acentuacao pq nao precisa? vai ter que ficar mudando a configuracao na hora de programar? um saco isso em…

e quando tiver um desenvolvedor com linux com a codificacao bagunçada que bagunçar todas as variaves e nomes de metodos do projeto e tiver que ajeitar tudo na mao? vai ser uma trabalheira danada…

e ingles eh a lingua universal, enquanto que o portugues…

acho q javadoc eh aceitavel que esteja com acentuacao. mas nem isso acho necessario.

[]s

Concordo com peron

A um tempo eu programo com o NetBeans e Aptana (javascript) … o problema era usar acentos de um para outro mudava o charset e lá ia os caracteres estranhos … mesmo mudando para o mesmo chaset dava problema com o Aptana (que foi resolvido nas ultimas versoes), mais a idéia é … para web sempre uso ISO-8859-1 e assim faço com o meu código e documentação mas nunca uso caracteres especiais para não dar problema caso mude de charset :wink:

Ô “indivito” … falando em corretor ortográfico, por que será que o Eclipse agora vem com um? Certo que é pra inglês, mas isso deve ser importante.

Imagine se na sua empresa existissem pessoas de diferentes nacionalidades dando suporte em um sistema. Seria de bom agrado um corretor, até pra ajudar os caras e também não deixar o código menos legível, já que esses caras podem errar na escrita das palavras. Não só estrangeiros, nós mesmos também!!!
Seria bom também que corrigisse até as Strings. Mostrar mensagem de erro com erro é foda!

Já pegando um gancho com problemas na hora de usar o código em outro sistema operacional ou IDE, é importante que se mantenha um padrão na codificação dos caracteres.
Por exemplo, se tudo estiver em UTF-8 (código e IDE) nada vai se alterar.

Bom, é isso!

Valeu!