É fácil cair na armadilha de seguir convenções rígidas na programação, mas um exemplo recente de código JavaScript nos faz questionar essa prática. A flexibilidade, mesmo em situações simples, pode ser crucial para a compreensão e manutenção do código. Entender o código vai além de decorar regras; é sobre reconhecer as possibilidades e adaptar-se a diferentes estilos.
O código a seguir ilustra essa questão:
“`javascript
return new Promise((resolve, reject) => {
locations.fetch({
success: resolve,
error: reject,
});
});
“`
A familiaridade com as convenções em JavaScript nos faz esperar que os argumentos da callback para new Promise() sejam nomeados como resolve e reject. Mas será que essa rigidez é necessária?
Variações nas Convenções em JavaScript
É possível explorar diversas variações que, embora não alterem a funcionalidade do código, podem influenciar a forma como o interpretamos.
Mudando os Argumentos
Os argumentos da Promise são, essencialmente, funções que resolvem ou rejeitam a promessa. No entanto, seus nomes podem refletir seu propósito ou qualquer outra coisa que faça sentido no contexto. Veja um exemplo:
“`javascript
return new Promise((success, error) => {
locations.fetch({ success, error });
});
“`
A funcionalidade permanece intacta, já que o código ainda está dentro de new Promise(), indicando que resolve e rejeita. Apesar de não defender essa mudança, é importante reconhecer que esperar a convenção de resolve e reject pode levar a mal-entendidos em códigos perfeitamente válidos.
Essa flexibilidade pode ser útil em situações específicas, como quando os nomes success e error se alinham melhor com a lógica do restante do código. No entanto, é fundamental ponderar se a mudança aumenta ou diminui a clareza geral.
A escolha de nomes de argumentos mais descritivos pode ajudar novos membros da equipe a entender o código mais rapidamente, mas também pode confundir aqueles acostumados com a convenção padrão. O ideal é encontrar um equilíbrio que maximize a legibilidade sem sacrificar a familiaridade.
Manter a consistência dentro de um projeto é crucial. Se a equipe decidir adotar nomes de argumentos diferentes de resolve e reject, essa convenção deve ser seguida em todo o código para evitar confusão.
Funções Externas
Estamos tão habituados a ver uma arrow function dentro de new Promise() que podemos esquecer que essa não é a única opção.
“`javascript
const wrapFetch = (success, error) => {
locations.fetch({ success, error });
};
return new Promise(wrapFetch);
“`
Essa convenção é comum em event handlers, onde esperamos ver (e) => // … repetidamente.
Assim como a variação nos nomes dos argumentos, utilizar funções externas pode melhorar a organização e reutilização do código. Em vez de repetir a mesma lógica dentro de várias Promises, você pode encapsulá-la em uma função separada e simplesmente referenciá-la.
Essa abordagem também facilita a testagem unitária, já que a função externa pode ser testada isoladamente, sem a necessidade de criar uma Promise completa. Além disso, funções externas podem ser documentadas de forma mais clara, melhorando a manutenção do código.
É importante notar que, ao usar funções externas, a clareza do código pode ser afetada se o nome da função não refletir claramente seu propósito. Portanto, escolha nomes descritivos que indiquem que a função é usada para resolver ou rejeitar uma Promise.
O objetivo aqui não é defender uma mudança radical no estilo de codificação, mas sim reconhecer como é fácil ficar preso a convenções em JavaScript e perder a capacidade de interpretar o código de forma eficaz. Não precisamos ignorar as convenções, nem aceitar soluções “inteligentes” que economizam alguns caracteres, mas praticar testar os limites das convenções pode melhorar nossa capacidade de ler e manter o código.
Em vez de seguir cegamente as convenções, devemos encorajar uma cultura de questionamento e experimentação. Isso não significa ignorar as práticas estabelecidas, mas sim entender o porquê delas e estar aberto a alternativas que possam melhorar a clareza e a eficiência do código.
Ao desafiar as convenções, também é importante considerar o impacto sobre a equipe. Mudanças radicais no estilo de codificação podem gerar resistência e dificultar a colaboração. Portanto, qualquer alteração deve ser discutida e aprovada pelo time, garantindo que todos estejam alinhados com a nova abordagem.
A busca por um código mais legível e eficiente é um processo contínuo, e a flexibilidade para questionar e adaptar as convenções é uma ferramenta valiosa nesse processo.
Primeira: Este conteúdo foi auxiliado por Inteligência Artificial, mas escrito e revisado por um humano.
Segunda: Via dev.to