¿Con o Sin Llaves?

13 de octubre de 2019 • 2 min de lectura

Hay un debate acalorado sobre las declaraciones simples y si deberían tener llaves o no.

En C++, C#, Java y Javascript una declaración de una sola línea sin llaves es válida, algunos aprovechan esta característica, mientras que otros no.

Por Ejemplo

if(ifTrue) 
  MowTheLawn();

for(var index; index > 10; index++)
  ChopWood();

foreach(var dollar in money)
  BuyLollipop();

while(untilTheEnd)
  Read();

Argumentos en Contra de las Llaves en Una Sola Línea

El argumento en contra de las llaves es que es una sintaxis más concisa, son menos caracteres que escribir, y es sintaxis válida. ¿Por qué no aprovecharla?

Argumentos a Favor de las Llaves en Una Sola Línea

El argumento a favor de las llaves es la consistencia, menos errores y más natural para analizar mentalmente.

En un artículo escrito por Jon Abrams titulado Single-line ‘if’ statements, Jon explica cómo un defecto en la implementación TLS de Apple fue introducido como resultado de una declaración if de una sola línea sin llaves. Jon continúa diciendo que aunque omitir las llaves en declaraciones de una sola línea es más conciso, prevenir defectos es más importante que la concisión.

Jon propone un compromiso, permitir declaraciones de una sola línea si están verdaderamente en una sola línea:

if(ifTrue) MowTheLawn();

Hago eco de los pensamientos de Jon, omitir las llaves en líneas simples no vale la pena por el beneficio que ofrece. Obliga al ingeniero de software a considerar dos variaciones de sintaxis válida. Puede que no parezca tan malo, pero es agotador tomar esta determinación cada vez que te encuentras con una declaración if. El efecto siguiente es que el ingeniero ahorra algunas pulsaciones de teclas y pasa la carga a futuros lectores para que analicen su código.

Para los Ingenieros de Software de C#, Microsoft ha tomado partido en sus convenciones de codificación, que requieren llaves.

Cuando usamos llaves en todos los casos independientemente del número de líneas, lo que está en el alcance y lo que está fuera del alcance es muy claro. Esto hace que el código sea menos propenso a errores y más consistente, aunque algunos podrían argumentar este punto, encuentro que es más fácil de leer.