Cómo elegir las mejores convenciones de código para usted y su equipo

Pon fin al debate interminable

- "¡Escuche, esas variables privadas deben ir tras las públicas!"

- "¡De ninguna manera! ¡Las variables públicas van antes que las privadas! "

- "Preguntémosle a Deb y déjela decidir"

- "Espera, ¿por qué estas constantes no están en caja de camello?"

? ‍♂? ‍♀

Levante la mano si se ha encontrado en este tipo de discusión antes. Ok, no lo plantees realmente, pero algo me dice que algunos de ustedes pueden haber participado en este escenario una o dos veces.

Como desarrollador durante la última década, me he encontrado en bastantes, algunos podrían decir demasiadas, discusiones sobre convenciones de código. Estas discusiones, por útiles que sean, a veces se deterioran hasta convertirse en interminables divagaciones filosóficas. Y luego comienzan a cambiar a temas que van desde la sangría hasta la estructura de carpetas.

Puede resultar doloroso.

Entonces, ¿cómo se decide realmente cuál es la mejor convención y, mejor aún, existen las mejores convenciones? Lo expondré aquí, para que pueda poner fin a esas divagaciones filosóficas, de una vez por todas.

Entonces, ¿por qué necesitamos convenciones?

Para determinar cuál es la mejor convención y si existe, primero debemos comprender por qué necesitamos convenciones.

Hay más de unas pocas razones, pero me centraré en la más importante: la legibilidad .

¿Y si decidiera cambiar a escribir solo en mayúsculas? COMO ESTO, QUE PUEDE PARECER EXTRAÑO. Lo notas inmediatamente y tu cerebro comienza a procesar lo que es diferente.

Tome este ejemplo simple y piense en la denominación o sangría de variables. Si cada vez que regresara al código y estuviera escrito de manera diferente, sería como si estuviera comenzando desde el punto de partida. Pero cuando se codifica con convenciones, su código es más fácil de entender y, por lo tanto, legible, incluso si se escribió hace meses.

Esto se vuelve aún más crucial cuando se trabaja en un equipo de desarrolladores, donde cada uno escribe su propio código con su convención preferida. La cantidad de tiempo que se dedica a comprender y revisar el código de los demás llevará ... bueno ... ya entiendes.

Para colaborar con otros desarrolladores de manera eficiente y cualitativa, debe tener una convención común.

"Los programas deben estar escritos para que las personas los lean y solo de manera incidental para que las máquinas los ejecuten". - Hal Abelson

Cómo elegir la mejor convención de código

Ya sea que haya comenzado a programar, o sea parte de un equipo de desarrollo de kickass, o si se haya convertido en un CTO, ¿cómo puede elegir sus convenciones de código?

Aquí está mi guía para elegir la mejor convención de código:

  1. Inspírate en los equipos de desarrollo que admiras: nada supera la experiencia, y algunas de las empresas más grandes e inteligentes publican sus pautas de codificación. Por ejemplo, Airbnb publicó sus guías de estilo javascript y ruby, y Google publicó sus propias guías de estilo Java y Python. Te gusten estas empresas o no, si sumas los años de experiencia que tiene cada uno de sus desarrolladores, se suman miles de millones. Intente aplicar algunas de las guías de estilo de estas empresas a su propio equipo.
  2. Crowdsource el conocimiento de sus compañeros: Tenemos la suerte de ser parte de una comunidad tan dinámica. De hecho, una de las mayores ventajas de ser desarrollador hoy es nuestra comunidad. Ya sea en Slack, Spectrum, Discord o cualquier plataforma de colaboración, siempre puede encontrar grupos expertos para publicar una pregunta sobre las convenciones de código y obtener respuestas de desarrolladores de todo el mundo al instante.
  3. Ignore las muestras de código. Sí, solo ignóralos. De vez en cuando me tropiezo con código que se copió / pegó de una respuesta en Stackoverflow, o algo similar. Lo que la gente olvida a veces es que las muestras de código que acaban de copiar probablemente se escribieron como respuesta a una pregunta técnica o como explicación para alguna biblioteca. En la mayoría de los casos, el escritor no quiso ni tuvo tiempo para lidiar con las convenciones del código.

Estos consejos deberían ayudarlo a comenzar y pueden sentar las bases para la introducción de convenciones de código para su equipo de desarrollo.

Y ahora un poco de filosofía.

¿Existen las "mejores" convenciones?

Eso depende de lo que signifique "mejor". Si Airbnb o Google usan una determinada convención, o si 10 directores de tecnología diferentes le dijeron que su convención es la mejor, ¿significa eso que es la mejor convención para usted?

Además, las convenciones están sujetas a cambios. ¿Puede algo que cambia con el tiempo alguna vez ser nombrado "mejor"?

Cuando comencé en Lemonade como el único desarrollador front-end, me resultó difícil leer el código que escribió el desarrollador anterior. Podría haber sido la mejor convención para él, pero no lo fue para mí. Así que reescribí cada fragmento de código en el que trabajé usando mis convenciones. Con el tiempo, más desarrolladores se unieron al equipo y nuestras convenciones evolucionaron.

Cada desarrollador provenía de una experiencia diversa, con diferentes estándares y convenciones. Para formalizar nuestras convenciones, utilizamos la guía de estilo javascript de Airbnb como punto de partida. Revisamos las convenciones en esa guía y cambiamos o eliminamos las que no estábamos de acuerdo, y adoptamos las que nos gustaban. Incluso adoptamos a los desarrolladores de convenciones traídos de su propia experiencia y los integramos en nuestra convención maestra.

El proceso de evaluar cada convención y decidir si deberíamos adoptarla, no solo mejoró la legibilidad de nuestro código sino que también mejoró nuestro trabajo en equipo. (¡Más sobre eso en una publicación futura!)

Aquí está la dura verdad: no existe una definición universal para las mejores convenciones, porque simplemente no existen.

A diferencia de lo que te enseñaron en la escuela, no siempre hay una respuesta correcta para cada pregunta. En este caso, puede haber muchos.

Los desarrolladores tienen diferentes formas de implementar cosas diferentes o incluso las mismas. Algunos de nosotros preferimos que todos los nombres de los miembros de la clase comiencen con un prefijo 'm_'. A algunos de nosotros nos gusta usar dos sangrías de espacio, algunos prefieren tabulaciones, algunos podrían decir que usar la palabra Utilsen el nombre de una clase es incorrecto. Caray, esta es una discusión interminable, pero todas estas preferencias vienen con un buen razonamiento.

Al final del día, todo se reduce a qué convención mejora la legibilidad de su código. Cuál le permite a su equipo comunicarse mejor, avanzar más rápido y con mayor eficiencia.

Recuerde, las convenciones de código son simplemente sugerencias. Sí, una vez que decida qué convención utilizar, debe cumplirla. Pero recuerde: no están tallados en piedra y están sujetos a cambios. Permítase experimentar con diferentes convenciones hasta encontrar la que mejor se adapte a usted y a su equipo.

Entonces, ¿cuáles son las mejores convenciones de código? ¡Fácil, el tuyo!