Padrões para escrita de código. Usar ou não usar?

David,

Eu acho absolutamente necessário, porque senão vira a festa do caqui. Gosto muito de usar o checkstyle configurado com cores berrantes para indicar as violações.

Em relação aos seus exemplos, tudo bem, é um padrão seu, mas ele não segue totalmente o Code Conventions da Sun… Tem espaço sobrando ai no seu código.

http://java.sun.com/docs/codeconv/html/CodeConventions.doc7.html#475

Mas gosto é gosto, o importante é deixar o código padronizado, e não uma zona.

Valeu!
Eduardo

esb:

…
Em relação aos seus exemplos, tudo bem, é um padrão seu, mas ele não segue totalmente o Code Conventions da Sun… Tem espaço sobrando ai no seu código…

Eu sei, mas é o que eu falei, ajuda a ler e não é uma coisa absurda entendeu. Não é uma coisa que vai te fazer ficar olhando para tentar entender o porque tem um espaço a mais. Afinal, é um espaço entre a expressão e os parênteses :D.
Na verdade eu uso esse padrão de colocar espaços nesses locais por causa do livro dos Deitel. Foi com eles que comecei a aprender Java e que agora estou estudando C++ de verdade. Eu gosto do estilo, por isso.

davidbuzatto:

esb:

…
Em relação aos seus exemplos, tudo bem, é um padrão seu, mas ele não segue totalmente o Code Conventions da Sun… Tem espaço sobrando ai no seu código…

Eu sei, mas é o que eu falei, ajuda a ler e não é uma coisa absurda entendeu. Não é uma coisa que vai te fazer ficar olhando para tentar entender o porque tem um espaço a mais. Afinal, é um espaço entre a expressão e os parênteses :D.
Na verdade eu uso esse padrão de colocar espaços nesses locais por causa do livro dos Deitel. Foi com eles que comecei a aprender Java e que agora estou estudando C++ de verdade. Eu gosto do estilo, por isso.

Sim, e eu não estou recriminando

Aliás, não dá pra usar 100% o Code Conventions da Sun… não em 100% dos casos. Nem o Checkstyle com tudo ligado. Loucura!

Bem legal seu thread, vamos saber quantos adotam essa prática em seus projetos…

Eu acho que o estilo do código vai de programador para programador. Por mais que tentamos seguir certos padrões acabamos deixando nossa marca pessoal no código.
Em relação a espaços na minha opinião espaço demais atrapalha “juntar” os comandos…
Eu sou contra a códigos se espaço e quebras de linha (sair escrevendo tudo na mesma linha depois do “;”), assim fica muito complicado de analisar…

Mas como eu disse, isso é apenas minha opinião 8)

Usar um padrão, normalmente, o padrão da empresa.

Pelo menos é assim onde eu trabalho. A equipe de qualidade de software cria um documento para o padrão de código (não só para java, mas com bom senso de exceções como é o caso do Java, ou seja… o padrão para Java, segue quase a risca do documento de convenção de código oficial da sun) e todo mundo segue a RISCA.

Pra que seguir? Para obviamente outros entenderem.

KassiPretti:

Eu acho que o estilo do código vai de programador para programador. Por mais que tentamos seguir certos padrões acabamos deixando nossa marca pessoal no código.
Em relação a espaços na minha opinião espaço demais atrapalha “juntar” os comandos…
Eu sou contra a códigos se espaço e quebras de linha (sair escrevendo tudo na mesma linha depois do “;”), assim fica muito complicado de analisar…

Mas como eu disse, isso é apenas minha opinião 8)

Se tu pega uma empresa como a minha para trabalhar. se você fazer qualquer coisa ligado a padrão do seu jeitinho aguarda o feedback, certo que terá de refazer até aprender. bj

Iniciante no Java, mas programei em outras linguagens. Adorei ver que temos essas convenções de código no Java, facilia bastante, mas claro que seguir 100% fica difícil, mas acho valido tentar com certeza.

Estou com o Code Conventions sempre aberto pra ler e tirar dúvidas e ir me acostumando com as regrinhas, assim fica bem mais fácil ao meu ver.

Essas suas regras eu uso algumas (antes do Java usava em outras linguagens).

Apesar de ser iniciante, sempre se deve aprender do jeito correto, porque se pegar vicios fica foda de corrigir masi pra frente.

Sem mais…

Mas eu sei que numa empresa as coisas são diferentes…

No caso se vc fosse fazer um sistema por conta própria acaba acontecendo, mas manter o codigo bem organizado facilita a identificação de possiveis erros…

:roll:

Ver classes com nomes iniciados com letras minúsculas e atributos e métodos com nome iniciados com letras maiúsculas é triste.

Isso é verdade…

Passo por isso neste momento. Estou corrigindo vários erros de uma equipe que deixou um projeto de RH pela metade aqui na UFRN, correndo contra o tempo tentando entender essas monstruosidades.
O que vejo de “return;” no final de métodos void não é brincadeira… :x

antonioni.rocha:

O que vejo de “return;” no final de métodos void não é brincadeira… :x

:shock: :shock: :shock: :shock: :shock:

Eu axo q é útil de mais… e só ajuda na visualização e compreensão do cód…

Eu sempre perco um tempinho tirando espaços que sobram ou q faltam pra manter um padrão no meu cód…

Claro que também sempre conto com a ajuda do CTRL+SHIFT+F do eclipse…

Eu sou muito chato quanto a isso. Gosto de seguir sempre um mesmo padrão.
Porém, os meus códigos tem sim minha marca pessoal. Há algumas coisas que a padronização da Sun não cobre, fica em aberto, ou então que em alguns casos acaba mais atrapalhando do que ajudando. Daí nesse caso eu vou pelo bom senso.

Coisas como espaços entre operadores binários eu acho fundamental, mas depois dos unários eu odeio. Um espaço após o cast também acho essencial. Odeio "{" isolado, prefiro na mesma linha da declaração. Gosto de "} else {" e de "} catch (AlgumaException e) {". Laços for, while e do para mim sempre tem que ter o par de chaves. Quanto a aos ifs, para mim se não tiver chaves, o código tem que estar na mesma linha do if. Por exemplo:

if (a == b) x = true;

if (i > j) {
    s = false;
    break;
}

Nunca fui fã de quebrar linhas só porque elas ultrapassam os 80 caracteres (ainda mais em java, onde há identificadores grandes). Essa restrição veio da época do DOS e não consigo aceitar que haja gente que ainda a mantenha viva ainda só porque em um passado distante era necessário. Para mim quebras de linha devem ser em pontos onde elas são naturais, sem deixar as linhas nem muito longas mas sem quebrar as instruções em muitas linhas. Aqui na minha opinião a regra NÃO é clara e vale o bom senso.

Identação SEMPRE SEMPRE SEMPRE em quatro ESPAÇOS, nada de Tabs. Sou a favor de que o compilador gerasse um erro de compilação e parasse imediatamente ao encontrar um Tab porque eu simplesmente os odeio. Tabs são o tipo de coisa que dificilmente duas pessoas visualizam de forma igual.

Ah, vale ressaltar que no caso da certificação SCJD, a padronização do código conta muitos pontos. Qualquer coisa fora do padrão da Sun pode significar um ponto a menos, mesmo que você não concorde com isso.

victorwss:

Eu sou muito chato quanto a isso. Gosto de seguir sempre um mesmo padrão.
Porém, os meus códigos tem sim minha marca pessoal. Há algumas coisas que a padronização da Sun não cobre, fica em aberto, ou então que em alguns casos acaba mais atrapalhando do que ajudando. Daí nesse caso eu vou pelo bom senso.

Coisas como espaços entre operadores binários eu acho fundamental, mas depois dos unários eu odeio. Um espaço após o cast também acho essencial.

Todos estes casos são cobertos pela padronização da Sun, inclusive o espaço após o Cast. Fica claro que o que não está especificado lá não tem que ter espaço nem antes e nem depois!

victorwss:

Nunca fui fã de quebrar linhas só porque elas ultrapassam os 80 caracteres (ainda mais em java, onde há identificadores grandes). Essa restrição veio da época do DOS e não consigo aceitar que haja gente que ainda a mantenha viva ainda só porque em um passado distante era necessário. Para mim quebras de linha devem ser em pontos onde elas são naturais, sem deixar as linhas nem muito longas mas sem quebrar as instruções em muitas linhas. Aqui na minha opinião a regra NÃO é clara e vale o bom senso.

Eu acho que essa regra existe mais por conta da necessidade de impressão. Tudo bem que quase ninguém imprime código fonte (eu pelo menos não conheço ninguém que faça isso com freqüência). Mas se essa necessidade existir, e o código fonte tiver linhas com mais de 80 caracteres, a impressão vai ficar um lixo.

esb:

victorwss:

Eu sou muito chato quanto a isso. Gosto de seguir sempre um mesmo padrão.
Porém, os meus códigos tem sim minha marca pessoal. Há algumas coisas que a padronização da Sun não cobre, fica em aberto, ou então que em alguns casos acaba mais atrapalhando do que ajudando. Daí nesse caso eu vou pelo bom senso.

Coisas como espaços entre operadores binários eu acho fundamental, mas depois dos unários eu odeio. Um espaço após o cast também acho essencial.

Todos estes casos são cobertos pela padronização da Sun, inclusive o espaço após o Cast. Fica claro que o que não está especificado lá não tem que ter espaço nem antes e nem depois!

Bem, na verdade eu já estava um pouco que mudando de assunto. Não era minha intenção dar a entender que o segundo parágrafo era continuação do primeiro.

esb:

…

victorwss:

Nunca fui fã de quebrar linhas só porque elas ultrapassam os 80 caracteres (ainda mais em java, onde há identificadores grandes). Essa restrição veio da época do DOS e não consigo aceitar que haja gente que ainda a mantenha viva ainda só porque em um passado distante era necessário. Para mim quebras de linha devem ser em pontos onde elas são naturais, sem deixar as linhas nem muito longas mas sem quebrar as instruções em muitas linhas. Aqui na minha opinião a regra NÃO é clara e vale o bom senso.

Eu acho que essa regra existe mais por conta da necessidade de impressão. Tudo bem que quase ninguém imprime código fonte (eu pelo menos não conheço ninguém que faça isso com freqüência). Mas se essa necessidade existir, e o código fonte tiver linhas com mais de 80 caracteres, a impressão vai ficar um lixo.

Na verdade na minha opinião um código com quebras-de-linha forçadas em 80 colunas tal como um regime militar linha dura, já deixam o código um lixo por natureza, mesmo que ele siga a risca todas as outras regras.

E quanto a impressão, a menos que você esteja usando uma impressora pré-histórica ou tenha um grau de hipermetropia alto, basta diminuir um pouco o tamanho da fonte para caber pelo menos umas 130 colunas.

victorwss:

esb:

victorwss:

Eu sou muito chato quanto a isso. Gosto de seguir sempre um mesmo padrão.
Porém, os meus códigos tem sim minha marca pessoal. Há algumas coisas que a padronização da Sun não cobre, fica em aberto, ou então que em alguns casos acaba mais atrapalhando do que ajudando. Daí nesse caso eu vou pelo bom senso.

Coisas como espaços entre operadores binários eu acho fundamental, mas depois dos unários eu odeio. Um espaço após o cast também acho essencial.

Todos estes casos são cobertos pela padronização da Sun, inclusive o espaço após o Cast. Fica claro que o que não está especificado lá não tem que ter espaço nem antes e nem depois!

Bem, na verdade eu já estava um pouco que mudando de assunto. Não era minha intenção dar a entender que o segundo parágrafo era continuação do primeiro.

esb:

…

victorwss:

Nunca fui fã de quebrar linhas só porque elas ultrapassam os 80 caracteres (ainda mais em java, onde há identificadores grandes). Essa restrição veio da época do DOS e não consigo aceitar que haja gente que ainda a mantenha viva ainda só porque em um passado distante era necessário. Para mim quebras de linha devem ser em pontos onde elas são naturais, sem deixar as linhas nem muito longas mas sem quebrar as instruções em muitas linhas. Aqui na minha opinião a regra NÃO é clara e vale o bom senso.

Eu acho que essa regra existe mais por conta da necessidade de impressão. Tudo bem que quase ninguém imprime código fonte (eu pelo menos não conheço ninguém que faça isso com freqüência). Mas se essa necessidade existir, e o código fonte tiver linhas com mais de 80 caracteres, a impressão vai ficar um lixo.

Na verdade na minha opinião um código com quebras-de-linha forçadas em 80 colunas tal como um regime militar linha dura, já deixam o código um lixo por natureza, mesmo que ele siga a risca todas as outras regras.

E quanto a impressão, a menos que você esteja usando uma impressora pré-histórica ou tenha um grau de hipermetropia alto, basta diminuir um pouco o tamanho da fonte para caber pelo menos umas 130 colunas.

Dependendo no que for usado o código fonte, não é possível imprimir em 130 colunas, muito menos diminuir a fonte. Num trabalho acadêmico, por exemplo. Mas cada caso é um caso.

Contanto que exista um padrão não me importo em qual seja, o importante é todo mundo falar a mesma lingua.

Btw, eu gosto de usar o checkstyle e retirar alguns pontos como 80 caracteres por linha, mas curto coisas como magic number que deixa qualquer programador louco.

Mais cedo ou mais tarde ele vai ter q seguir os padroes… nao tem para onde correr… desenvolvedores nao tem problemas com o padrao de codigo mais programadores sempre tem. Acho assim o cara so sente a essencia do padrao qdo faz um sistema de verdade e funcional e bota a coisa para rodar… e precisa dar manutenção… ele nao vai sentir essa essencia com os exemplos do deitel.

http://www.ioccc.org

Quem já tentou participar deste concurso ou mexer nos códigos que tem lá, vai entender muito bem a importância destes padrões. :twisted:

LPJava:

Mais cedo ou mais tarde ele vai ter q seguir os padroes… nao tem para onde correr… desenvolvedores nao tem problemas com o padrao de codigo mais programadores sempre tem. Acho assim o cara so sente a essencia do padrao qdo faz um sistema de verdade e funcional e bota a coisa para rodar… e precisa dar manutenção… ele nao vai sentir essa essencia com os exemplos do deitel.

Não entendi…

Quanto as 80 colunas, o objetivo não é impressão e sim visualização em modo texto. Normalmente quando utilizados uma interface modo texto, temos 80 colunas. Sendo assim, mantendo o código em 80 colunas ele não fica quebrado ou sai da tela.

Você só sabe que 80 colunas são importantes quando só tem um terminal serial para dar manutenção em código em uma máquina Unix, usando vi ou emacs.

Achei legal esse tópico.
Padrão de escrita é muito importante para todos que desenvolvem, deixa o código mais “entendível” e assim “livra a cara” do desenvolvedor que realizar uma possível manutenção. Por mais que alguns façam de uma forma e outros o façam de outra, devemos seguis, pelo menos, um mínimo de padrão, seja adotado por empresas ou por órgãos competentes (sem ressentimentos com as empresas, ok?).

Espero que tenha exposto minha opinião de forma correta.

Abração galera.

crpablo:

Claro que também sempre conto com a ajuda do CTRL+SHIFT+F do eclipse… :)

Na verdade vc pode até configurar o projeto para que o Eclipse aplique o formatador toda vez que o arquivo for salvo. É o cúmulo da preguiça

Passo por isso neste momento. Estou corrigindo vários erros de uma equipe que deixou um projeto de RH pela metade aqui na UFRN, correndo contra o tempo tentando entender essas monstruosidades.
O que vejo de “return;” no final de métodos void não é brincadeira… :x

No final é fogo hein? Se fosse no meio eu poderia até chutar que são métodos recursivos!