Código Limpo

Bom dia Trailblazers!!!

Hoje vamos conversar sobre um tema muito controverso no nosso mundo de desenvolvedores e desenvolvedoras.

Código Limpo!!!!!

 

Minha apresentação no Dreamforce´22 foi sobre isso, Code simple, Code right.

https://reg.salesforce.com/flow/plus/dreamforce22/sessioncatalog/page/Catalog/session/1656082526306001wjCE

 

Hoje passamos mais tempo lendo nosso código do que escrevendo ele.

Então não faz sentido que nosso código seja limpo, preciso e fácil de ler?

Vamos conversar como pegar um código escrito às pressas e aplicar as melhores práticas para refatorar-lo e limpá-lo.

Já escutei várias vezes a pergunta: Por que temos que arrumar ele se ele esta funcionando?

– Sim faz sentido em não se preocupar com algo que esta funcionando, porém hoje temos que ter certeza de que aquele código esteja entendivel por todos que forem ler ele. Quando digo todos, digo todos mesmo, pois não é mais um desenvolvedor ou desenvolvedora que vai ler ele. Hoje temos admins, consultores, analistas de negócio, arquitetos funcionais entre outros, que desejam verificar o que o códigos está fazendo ou pelo menos deveria.

 

Aqui segue as práticas recomendadas para escrever código limpo no Salesforce

– Fácil de entender por outros desenvolvedores: legível por outros desenvolvedores além daquele que o desenvolveu.

– Fácil de manter: menores chances de introdução acidental de bugs

– Modificado sem medo de quebrar nada: muitos desenvolvedores se orgulham de tornar o código compacto tentando fazer várias coisas em uma linha o que pode ser impressionante, mas torna o código muito mais difícil de ler e entender

 

Regras para escrever código limpo

– Mantenha seus métodos curtos

– Não se repita

– Os métodos devem fazer apenas uma coisa

– Nomes claros e reveladores de intenção

– Comente para esclarecer não para explicar

– Deixe tudo melhor do que você encontrou.

 

Padrões de software acordados

– Convenções de nomenclatura

– Recuo

– Espaço em branco

– Chaves  {} fechadas na mesma linha ou não

 

Responsabilidade

– Comprometer-se a manter o código limpo como uma equipe

– Reter revisões de código para impor padrões

 

Pensem sobre isso e reflitam o que você tem a ganhar praticando o código limpo e quais os benefícios que isso pode causar na sua carreira.

Compartilhem conosco suas idéias e opiniões sobre este tema, juntos vamos crescer e evoluir no universo de desenvolvimento Salesforce!!!

No próximo post iremos conversar sobre Convenção de nomenclaturas no Salesforce.

Até a próxima!!!

Formatação de código (Parte 2)

Bom dia Trailblazers!!!

 

Na última postagem falamos sobre formatação de códigos e recebi algumas mensagens perguntando sobre este tema mas voltado ao aplicativo VSCode.

Sim o VScode tem uma extensão chamada Prettier Extension que faz o papel de deixar tudo mais bonitinho.

O que afinal ele faz dentro do VSCode, em seus termos mais simples, ele remove todo o estilo do seu código e o reescreve da maneira que achar melhor. Podemos até configurá-lo para fazer isso toda vez que salvamos, o que é ótimo, pois nos permite escrever nosso código de maneira natural. Prettier então faz o trabalho braçal para torná-lo compatível com um padrão de estilo. Agora vamos dar uma olhada nas especificidades do que considera ser “bom”.

A maior parte da mágica do Prettier acontece quando o número de caracteres atinge um certo limite – ele tentará dividi-los em várias linhas para aumentar a legibilidade. São 80 caracteres por padrão, o que é uma volta aos velhos tempos de programação por terminais.

Antes

1.webp

Depois

 

2.webp

Prettier faz muito mais para ajudar a manter um estilo consistente:

* Adiciona ponto-e-vírgula

* Uso de cotação consistente

* Vírgulas finais consistentes

* Espaçamento consistente entre declaração de função/método e parâmetros

* Espaçamento consistente para recuo (geralmente quatro ou dois espaços/tabulações)

* Espaçamento consistente entre itens entre colchetes

 

Isso é um monte de coisas que ele faz, e esta nem é a lista completa.

No entanto, por melhor que seja o Prettier, os computadores são burros e precisam saber explicitamente o que fazer, enquanto nosso código está cheio de contexto e informações implícitas.

Embora o próprio Prettier faça um ótimo trabalho, se ajustarmos nosso próprio estilo de codificação apenas um pouquinho, podemos ajudar a levá-lo para o próximo nível.

Os auto-formatadores para nosso código são um excelente ponto de partida para uma maneira bem estilizada e intuitiva de entender as bases de código. No entanto, nós, desenvolvedores, podemos dar um passo além, desenvolvendo bons hábitos para usar em conjunto com nosso auto-formatador para melhorar ainda mais nossa intenção em nosso código. Estes são um pouco mais subjetivos, mas esperançosamente fáceis de entender e integrar em seu fluxo de trabalho.

Aqui seguem dois links para te ajudar com a instalação e configuração da extensão.

https://www.alphr.com/use-prettier-vs-code/#:~:text=Here’s%20how%20to%20configure%20the,Save%E2%80%9D%20when%20you%20are%20done

https://www.youtube.com/watch?v=Gmz27agvLYg

https://www.youtube.com/watch?v=cQqvoUxKIYQ

 

Agrupando Blocos Lógicos

Isso envolve o uso de quebras de linha para agrupar suas linhas de código em blocos de código menores e logicamente relacionados. Agora, o que queremos dizer quando dizemos logicamente agrupados? Isso pode ser bastante subjetivo e não há uma resposta correta aqui, mas considero isso como linhas de código que estão (aproximadamente) trabalhando na mesma coisa.

Digamos, por exemplo, que estamos definindo um grande número de campos em um registro de contato – poderíamos considerar todos os campos de endereço de correspondência como um bloco lógico. Isso também pode ser aplicado a variáveis ​​de instância, agrupando aquelas passíveis de serem trabalhadas em conjunto ou com tema semelhante.

 

Quebras de linha antes das declarações de fluxo de controle

Primeiro, vamos definir as instruções de fluxo de controle (qualquer um dos seguintes):

  • If/else statements
  • Switch statements
  • Do while loops
  • While loops
  • For loops
  • Break statements
  • Continue statements
  • Return statements
  • Throw statements
  • Try/Catch/Finally blocks

 

Todas as instruções acima são usadas para definir blocos de código condicionais ou para controlar o fluxo através deles. Uma vez que essas declarações têm um grande impacto sobre como nosso código se comporta, indicar claramente isso para uma leitura é fundamental para a legibilidade. Fazemos isso simplesmente introduzindo quebras de linha antes dessas declarações, no entanto, evitamos uma quebra de linha antes dessas declarações se elas forem a primeira linha de código dentro de seu bloco.

Apesar de sua aparente simplicidade, a formatação do código é um dos aspectos mais importantes de uma base de código. A falta de padronização pode levar rapidamente a um código difícil de manter e propenso a erros, simplesmente porque pode ser difícil para os desenvolvedores entender a intenção original ou simplesmente o que realmente está acontecendo em uma seção do código.

Os padrões de formatação de código ajudam a aliviar esses problemas, introduzindo políticas em toda a empresa sobre como nosso código deve ser. Isso nos ajuda a integrar novos desenvolvedores com mais eficiência e reduz as frustrações do desenvolvedor ao trabalhar em códigos mais antigos.

Já que “o que é melhor” pode ser uma questão altamente subjetiva (e quase certamente levará a divergências), adotar um formatador de código opinativo como o Prettier pode ser uma maneira rápida e indolor de implantar padronizações em qualquer número de desenvolvedores – tudo sem prejudicar as pessoas sentimentos sobre qual estilo é o melhor!

Espero que isso possa te ajudar muito na forma de trabalhar pensando no geral e não apenas em como você entende o código.

Bom aqui finalizamos nossos posts a respeito de formatação de códigos, qualquer dúvida não deixe de fazer suas perguntas e comentários a respeito destes artigos.

Até a próxima!!!

Formatação de código (Parte 1)

Bom dia Trailblazers!!!

Gostaríamos de cada vez ver este grupo crescer, então por isso, por favor compartilhem nas suas redes sociais este canal, tanto aqui da comunidade do Trailhead mas também da Trailblazer (link no final)  logo logo teremos muitas coisas novas e surpresas, como presentes para os participantes e vouchers para certificações, então se não entrou no grupo Trailblazer, entra já.

 

Hoje iremos conversar sobre formatação do código.

Porque devemos nos preocupar em formatar nosso código?

Primeira coisa que vem na nossa cabeça é para ficar mais bonito, hehehehe, também.

Porém o objetivo principal e mais correto é para facilitar a leitura e suas estruturações. Com isso você criará uma forma mais rápida de verificar seu código, para possíveis alterações, revisões, atualizações ou apenas para tirar dúvidas. E não somente suas porém o melhor de tudo para os outros.

Tenha em mente que qualidade gera lucros futuros.

 

* Indentation (recuo) – facilita a divisão do seu código implementando a separação por espaçamentos e alinhamentos.

 

* Spaces (espaços) – facilita a leitura também de uma forma clara.

Exemplo

Estão errados os primeiros exemplos? 

Não, porém qual dos dois exemplos de cada ponto tem uma leitura visual mais clara de blocos?

 

* Blank lines (linhas em branco) – colocação de linhas em branco aumentam a leitura finalizando seções de códigos que estão logicamente relacionados.

– 2 linhas em branco

Adicione duas linhas em branco entre as seções de um arquivo de origem. Sempre adicione entre a definição de classe e interface/wrapper classes no Salesforce.

– 1 linha em branco

Use uma linha em branco entre os métodos, entre a variável de nível de classe e o método. Use entre a seção lógica dentro de um método para melhorar a legibilidade.

 

São os pequenos detalhes que muitas vezes fazem a grande diferença e poupam muito tempo na verificação do código.

No próximo iremos falar de layouts.

 

Gostaria de convidar você a fazer parte dos nossos alertas de reuniões virtuais e presenciais, acesse  o link do Trailblazer Grupo , de um JOIN lá. Assim você receberá os alertas das futuras reuniões e encontro que faremos mensalmente.

 

Qualquer dúvida, sugestões, críticas e idéais, sinta livre para fazer aqui no nosso grupo.

Até a próxima!!!