Java Ser profissional é sair abreviando tudo?

[sandrofabres]

Gente, me tirem uma dúvida: ser profissional em Java é sair abreviando tudo inutilizando outras coisas?
Por exemplo, se hoje ensinam fazer vetor assim:

String[] come = new String{"xuxu", "cebola", "nabo"};

metodoCozinhar(come);

 

Aí vem um bom diz que isso é feio e que o bonito e certo é fazer assim:

metodoCozinhar(
 new String{"xuxu", "cebola", "nabo"}
);

 

Se lhe ensinam que um objeto se faz assim:

ClasseCoisa objeto = new ClasseCoisa();

objeto.exists();

 

Aí vem outro bom lhe dizer que o correto é assim:

new ClasseCoisa

.exists();

 

Se você inocentemente faz isso:

if (coisaBoolean){
     return 10000;
}

 

Aí lhe mandam fazer que é mais bonito:

(coisaBoolean ? 10000 :  0)

 

Se temos um método que vai dentro de outro

jose(casado(nomeMulher()));

 

Os bom mandam fazer assim:

jose(casado
(
new nomeMulher(  // forma arregaçada
)
);

 

Afinal, eu não posso programar da forma que a linguagem permite, mas sim de forma abreviada e arregaçada como acham bonitinho?

 

Dá impressão que tudo aprendido está sempre errado.

[Staniack]

Tirando isto, que realmente é bem feio mas é normal fazer:

if (coisaBoolean){return 10000;}

 

Isto daqui também é bem zoado:

jose(casado 

( 

new nomeMulher(  // forma arregaçada 

) 

);

 

O resto para mim sempre foi opcional. Eu também tenho essa sensação de que tudo que nos ensinam é errado e feio de se fazer sendo que em alguns casos trata-se apenas de padrões de escrita opcionais de código. Na minha opinião, não acho acho errado não abreviar tudo. Inclusive, se você está programando em grupo e os outros membros não estão familiarizados com o Java, é até aconselhável você não abreviar todo código. Além do mais, para mim, bater o olho em um código não abreviado é muito mais didático. 

 

O perigo é quando você sente a necessidade de abreviar tudo e deixa o código ilegível. Aí sim é estressante. Não é interessante você encadear uma série de linhas de código abreviados.

 

Muitos vão dizer que abreviar acaba diminuindo as linhas de código e até mesmo maximizando a eficiência do mesmo, pois você estará diminuindo a quantidade de variáveis. Em alguns casos pode até ser verdade, mas não são todos os casos e é preciso pesar os contras também. 

[Denis Bopp]

Cada um programa como quiser, mas o que quer que faça, tenha em mente que deve ser legível para quem pegar seu código entenda o que está sendo feito. Existem algumas regrinhas que todos normalmente seguem, mas se você programa pra você, faça da forma que lhe convir!

adicionado 6 minutos depois

Em 26/07/2020 às 22:08, sandrofabres disse:

Se você inocentemente faz isso:

if (coisaBoolean){
     return 10000;
}

 

Aí lhe mandam fazer que é mais bonito:

(coisaBoolean ? 10000 :  0)

 

 

Algumas formas são mais elegantes, e diminuem a quantidade de código digitado, isto é tempo, e tempo é dinheiro, ou tempo com as crianças, ou como você quiser gastar, programar é um exercício de enxugar rotinas, fazer mais tarefas com menos código, mantendo a legibilidade e funcionalidade que o aplicativo necessita.

Na minha humilde opinião!

[Lucas LC]

Eu também sempre tive a impressão que estava aprendendo errado e os profissionais sempre vão usar códigos mais enxutos, porque levam menos tempo. Meu professor da faculdade sempre pega no pé a questão da "lógica de programação", saber as tarefas que o algoritmo vai fazer sem compilar, parece até sinistro, mas faz bastante sentido e quem é novato precisa passar por esse processo.

 

Por exemplo: 

 

Em 26/07/2020 às 22:08, sandrofabres disse:

ClasseCoisa objeto = new ClasseCoisa(); objeto.exists();

É bem mais fácil de enxergar que está declarando uma classe e está instanciando tudo na mesma linha. 

 

Em 26/07/2020 às 22:08, sandrofabres disse:

(coisaBoolean ? 10000 :  0)

Não é tão simples de entender, mas tem sua elegância. Porém, tornar seu código o mais legível possível pode fazer muita diferença para alguém que precisa mantê-lo no futuro.

[Denis Bopp]

16 horas atrás, Lucas LC disse:

Não é tão simples de entender, mas tem sua elegância. Porém, tornar seu código o mais legível possível pode fazer muita diferença para alguém que precisa mantê-lo no futuro.

Não esqueça a premissa básica! Sempre comente seu código, sempre, mesmo que seja para dizer o óbvio! Pode ser muito claro para você, mas para outra pessoa vai fazer grande diferença, ou mesmo para você daqui a cinco anos quando tiver de fazer uma manutenção no código!

[Armando Shimokawa]

Sobre a questão de ser "profissional", eu, como profissional (pelo menos 10 anos de Java) te digo:

Ser profissional é pensar em quem vai dar manutenção em seu código, mesmo que esse "quem" seja você do futuro.

Na minha visão isso é ser profissional. Daqui a 6 meses, no caso de ter algum bug, atualização ou mehoria no seu software, alguém vai ter que pegar, entender o que foi feito, analisar o que terá que ser mexido, e nessa hora um código claro e organizado faz muita diferença para mexer de forma rápida, eficiente e segura. É importante pensar que um código não é fazer funcionar, entregar e acabou. É pensar que, para o sucesso da empresa ou do próprio software, a capacidade de ele ser facilmente mexido vai fazer diferença com o passar do tempo, evitando o "Putz ninguém entende como aquilo como codificado, vamos ter que gastar um mega tempo pra fazer algo novo que faça o mesmo, e daí pra frente melhorá-lo". Isso é um gasto de tempo e $ que nenhuma empresa/dono de negócio quer.

Então ao invés de usar algo do tipo
 

int a = 45;
String h = "Sucesso"
public String metodo1(int g) {
	return "" + g;
}

é preferível um
 

int numeroDeMembros = 45.

String mensagemSucesso = "Sucesso"

public String alterarParaTexto(int numero) {
	return String.valueOf(numero);
}  

Isso apenas como exemplos bem simples. Mas ao meu ver é um dos conceitos mais importantes em alguém que quer se dizer "profissional".

[Marco Antonio Costa Silva]

Na real, você pode fazer do jeito que você quiser. Ninguém vai te obrigar a fazer diferente.

Mas existem alguns padrões que a comunidade adota na hora de desenvolver.

Por exemplo, se você não quiser criar getters nem setters para suas classes e deixar tudo publico, vai em frente. Mas se você precisar integrar essas classes em algum componente que adote os padrões básicos, não vai funcionar.

 

E tem o ponto mais importante: Quando você programa, você não escreve o código pra você, mas para os próximos que vão dar manutenção naquilo (que pode ser você mesmo daqui 4 anos). Se você escrever um bando de hieróglifos, nem mesmo você vai entender essa ***** daqui uns anos.

 

Código bom é código legível (para a maioria, não só pra você).

 

Obviamente, tem coisas que da pra otimizar do ponto de vista de performance, não só de "beleza", mas aí já é outra conversa.