Free Press

Bem-vindos ao maravilhoso mundo do desenvolvimento de software. Prepare-se para uma emocionante e emocionante jornada cheia de código, regras e mais código. E eu mencionei que existem regras? Se você é alguém que está familiarizado com codificação, então o conceito de padrões de codificação não é novidade para você. Você pode ser um forte defensor dessas diretrizes ou um lutador pela liberdade que acredita que o código é uma forma de expressão. Seja qual for o caso, não faz mal olhar para algumas das melhores práticas quando se trata de escrever um bom pedaço de código.
Vale a pena mencionar que embora existam padrões de codificação – eles existem em muitas variações e muitas vezes são meramente diretrizes que não têm de ser seguidas. A menos que você queira escrever um bom código, então provavelmente você deve se ater a algum tipo de padrão.

Escrever comentários e documentação

Talvez uma das primeiras coisas que você aprende como um desenvolvedor é comentar seu código. No início pode parecer uma perda de tempo, seguindo a mentalidade de ‘Se eles também são desenvolvedores – eles podem entendê-lo’. Embora seja verdade em parte do tempo, comentar seu código e fornecer documentação apropriada guiará os outros desenvolvedores através do algoritmo e da lógica que você implementou. Mas não se deixe levar e comente cada linha de código! Código óbvio deve ser deixado como está.

Código legível mas eficiente

Códigos legíveis são fáceis de seguir, mas utilizam espaço e tempo ideais. Ao escrever o código você pode muitas vezes querer escrevê-lo no menor número de linhas possível. Talvez você possa escrever um método ou função inteira em uma linha, mas isso só o torna mais difícil de ler e entender.

Utilizar métodos de ajuda

É uma boa prática manter o código conciso e sucinto. Um método só deve implementar o que precisa de fazer. Se uma parte da sua implementação faz algo mais, coloque-o em um método separado e chame isso dentro do seu método.

Se for evitável, NÃO codifique em código duro!

As únicas coisas que devem ser codificadas em código duro são constantes. É isso.

Escreva casos de teste. Não se esqueça dos casos de limite: 0s, strings/listas vazias, nulos, etc.

Assim você sabe o que o seu método faz, o que é preciso e o que deve retornar. Você saberá quando ele deve funcionar ou quando ele deve falhar. Uma função deve sempre ser baseada em casos de teste; não testes em funções.

Código legível mas eficiente. Em conformidade com os padrões de codificação do seu projeto atual

“PRÁTICAS PESSOAIS DISCIPLINADAS PODEM REDUZIR TAXAS DE INTRODUÇÃO DE DEFEITO ATÉ 75 PERCENTES”

Todos os projetos/empresas têm seus próprios padrões de codificação. Alguns podem preferir um estilo ao invés do outro quando se trata de convenções de nomenclatura, estrutura de arquivos e espaçamento.
Existem IDEs onde você pode definir o estilo preferido, que irá auto-corrigir você quando salvar. É mais fácil de ler e, portanto, entender quando todos os arquivos dos projetos usam o mesmo estilo, convenção de nomenclatura, espaçamento, etc.

Utilize o menu suspenso da sua IDE

Não tanto um padrão, mas uma boa prática, estes são muito úteis e irão ajudá-lo a cometer menos erros de codificação.

Por exemplo:
Se você quiser renomear uma variável ou um método, basta usar a opção “refactor” do seu IDE e ele irá alterar todas as chamadas para esse método/nome variável. Você não precisa alterá-las uma a uma, o que tornará seu código propenso a erro/falha.
Se quiser criar métodos getter/setter de todas as suas variáveis privadas, basta utilizar “create getter/setter” e o IDE criará automaticamente os métodos para você.

APIs são úteis

“PROJETOS DE SOFTWARE ATUALIZADOS GANHADOS DE 40 A 50 PERCENTES DO SEU ESFORÇO SOBRE REWORK AVOIDABLE”

Antes de implementar um método, certifique-se de que eles não estão disponíveis para você usar. Você não precisa codificar se você pode simplesmente importar a funcionalidade. Isto torna a vida de um desenvolvedor super fácil.
O famoso ditado é “Não reinvente a roda” e permanece verdadeiro em muitos casos. Entretanto, você deve sempre considerar as implicações de importar uma biblioteca, especialmente se ela for de terceiros. Além de possíveis problemas de licenciamento, você pode estar apenas inchando a sua base de código. Se tudo o que você precisa é de um método que converta temperaturas, você não precisa importar uma biblioteca que faça isso e uma centena de outras coisas.

Pair programming/code review

“PEER REVIEWS CATCH 60 PERCENT OF THE DEFECTS”

Estas são muito úteis quando se trata de refactoring your code. Outros podem ver uma melhor implementação para otimizar seu código ou apenas tornar seu código mais elegante. Também garante que os desenvolvedores adiram aos padrões e o trabalho é duplamente verificado. Além de tudo isso, é uma maneira maravilhosa para os desenvolvedores aprenderem uns com os outros.

VOLTAR E SALVAR O SEU TRABALHO DO TENO

Bastante dito. Bateria morta, apagão, falha de software, incêndio, desastre nuclear – tudo isso pode resultar em perda de dados. Certificar-se de salvar freqüentemente e fazer backup do seu código em algum tipo de sistema de controle de versão é uma maneira simples de garantir que seu código permaneça seguro.

Padrão de codificação e melhores práticas é um tópico enorme – um tópico que pode continuar por muitas páginas. Na verdade, se você alguma vez quiser ler sobre padrões de codificação Java, a Oracle tem exatamente isso. A aplicação desses padrões e práticas também varia de acordo com a aplicação – se você está trabalhando em um grande projeto corporativo ou ajudando seu irmãozinho com o dever de casa. Baseado em muitos fatores, cabe a você, em última instância, certificar-se de que o código que você desenvolve é bom código.

Disclaimer: Quaisquer opiniões ou opiniões apresentadas neste post do blog são exclusivamente do autor e não representam necessariamente as da Aversan Inc.