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

Assuntos Gerais
#1

Olá pessoal!

Bem, esse tópico tem como objetivo tentar esclarecer o porque da utilização da padrões para a criação de código fonte, seja em Java ou em qualquer outro tipo de linguagem, tanto de programação quanto de marcação.

Tenho visto ultimamente no GUJ, muita gente que não utiliza um padrão para escrever seus códigos, seja por desconhecer a existência ou por teimosia (aka rebeldia hehehe).

Ao meu ver, a utilização de um padrão é muito benéfica, pois além de deixar seu código mais limpo, ajuda os outros a entenderem o que você fez.

No Java, existe uma convenção para codificação que deve ser seguida preferencialmente. Não são regras difíceis… Então, porque não usar?

Existem algumas desculpas para não querer usar um padrão.
1 - Não acho que organizar meu código me ajuda.
2 - Eu GOSTO de fazer assim e pronto.
3 - Eu entendo o meu código e não me importo o que os outros pensam.

Atualmente venho estudando C++ e tenho visto que por não existir um padrão dito oficial, as vezes fica complicado você entender o que está sendo feito… Seja por abuso no uso de prefixos de um dado grupo de desenvolvedores ou por outros fatores.

Eu por exemplo, além das convenções do Java, eu adiciono algumas regras minhas, mas nada que deixe o código exótico :smiley:

Por exemplo:
Eu gosto de usar espaços sempre para facilitar a visualização de uma expressão.
Separo cada declaração em uma linha.
Tento não escrever linhas gigantescas, sempre quebrando-as em pontos que facilitem a visualização, etc.

Por exemplo, ao invés de fazer

[code]
int x, y, z;

x = (5+3-2*(4-6));

int[] x = new int[5];

for (int i = 0; i < 10; i++);[/code]

Eu faço:

[code]
int x;
int y;
int z;

x = ( 5 + 3 - 2 * ( 4 - 6 ) );

int[] x = new int[ 5 ];

for ( int i = 0; i < 10; i++ );[/code]

Enfim, sempre quando posso colocar espaços entre parênteses, eu coloco.

É uma tática para ajudar na visualização e não simplesmente porque eu acho bonitinho.

Esse papo pode ir longe… O que seria da química se não existisse um padrão? E da matemática então? Será que um padrão não é tão benéfico? Será que é mais cool ser rebelde e enxer o código de espaços para alinhar variáveis? Desenhar caixinhas em comentários?
Acho que muito tempo que é perdido enxendo o código de bizarrices podia ser usado para deixar o código limpo.

E ai, o que vocês acham?

Aguardo respostas!

#2

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

#3

[quote=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…[/quote]

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.

#4

[quote=davidbuzatto][quote=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…[/quote]

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.[/quote]

Sim, e eu não estou recriminando :wink:

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…

#5

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)

#6

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.

#7

[quote=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)[/quote]

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

#8

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…

#9

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:

#10

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

#11

Isso é verdade…

#12

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

#13

[quote=antonioni.rocha]
O que vejo de “return;” no final de métodos void não é brincadeira… :x [/quote]

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

#14

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… :slight_smile:

#15

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.

#16

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.

#17

[quote=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. [/quote]

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!

[quote=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.[/quote]

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.

#18

[quote=esb][quote=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. [/quote]

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!
[/quote]

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.

[quote=esb]
…

[quote=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.[/quote]

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.[/quote]

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.

#19

[quote=victorwss][quote=esb][quote=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. [/quote]

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!
[/quote]

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.

[quote=esb]
…

[quote=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.[/quote]

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.[/quote]

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.[/quote]

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.

#20

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.