Se acerca RuboCop 1.0

RuboCop es la herramienta de facto para analizar y formatear código en Ruby. Con miras de publicar la versión 1.0, Bozhidar Batsov -autor de Rubocop-, realizó una encuesta a la comunidad Ruby. RuboCop viene con un montón de valores por defecto, y la idea de la encuesta era medir lo que se viene usando para entender qué valores por defecto valía la pena cambiar basados en su uso y la frustración o satisfacción de la comunidad.

En los últimos años se había evitado cambiar valores por defecto en un esfuerzo por contener la fricción durante actualizaciones de RuboCop. Pero con la publicación de una versión 1.0, llega la oportunidad de revisar esos valores. Con 722 respuestas, un número que hasta el autor admite es bastante decepcionante dada la cantidad de usuarios de la herramienta, finalmente se publicaron los resultados y cómo afectaría a RuboCop 1.0.

Algunos de los resultados destacados:

Comillas simples vs comillas dobles en Strings literales

Personalmente uso comillas simples, y probablemente sea por costumbre de usar RuboCop y que me señala que tengo usar comillas simples cuando no estoy interpolando valores en un String. Hace unos años me acuerdo haber estudiado con Daniel Chains el tema respecto a la performance de simples contra dobles y vimos que no cambiaba nada. Pero como dice el autor del post original, lo único que importa es usar una o la otra de forma consistente. El resultado:

• Comillas simples – 58%
• Comillas dobles – 39%
• Otro (por ejemplo “que no les importa”) – 3%

Así que es algo que no va a cambiar por defecto, por más que sea uno de los temas en los cuales la comunidad parece ser más quejosa.

Longitud máxima de caracteres por línea

Acá estoy con la mayoría también. Si bien se puede configurar un Rubocop específico por proyecto, el valor por defecto de 80 caracteres me resultado demasiado corto.

• 120 caracteres – 48%
• 100 caracteres – 21%
• 80 caracteres – 18%
• Otro (ejemplo 150, sin límite) – 13%

A pesar de cambiar el valor por defecto de RuboCop para líneas más largas, se agregó una nota en la Ruby Style Guide de por qué sigue siendo buena idea mantener líneas cortas.

Comas finales en colecciones

# sin comas:
{ uno: 1, dos: 2 }
 
# con comas:
{ uno: 1, dos: 2, }

El valor por defecto de no exigir comas al final ganó en los resultados, por lo que se mantiene igual:

• No uso comas al final de la colección – 64%
• Uso comas al final sólo en colecciones multi-línea- 27%
• Uso comas al final en todos los casos- 1,5%
• Otro – 7,5%

and y or

“La pregunta si and y or son útiles o deberían ser evitados completamente ha cautivado por mucho tiempo a la comunidad Ruby”. Acá también estoy con la mayoría, los usuarios de RuboCop dijeron:

• No los uso para nada – 68%
• Los uso todo el tiempo – 4%
• Los uso para control de flujo (ejemplo do_something and return) – 29%

A pesar de los resultados, decidieron ser más permisivos y permitirlos para control de flujo, más que nada porque es un estilo bastante común en Ruby On Rails.

Doble Negación (!!)

Resultados:

• Solamente lo uso cuando necesito devolver un booleano – 53%
• No lo uso para nada – 39%
• Otro – 8%

Así que la doble negación va a estar permitida en el contexto de return.

Espacios dentro de los hash

# con espacios
{ hulk: "Bruce Banner" }
 
# sin espacios
{hulk: "Bruce Banner"}

En esta también sigo a la mayoría, 71% votaron que usan los espacios y 29% que no los usan.

Paréntesis para argumentos de métodos de Kernel (puts, system, exit)

# sin paréntesis
puts "Hola, mundo!"
exit -1
 
# con paréntesis
puts("Hola, mundo!")
exit(-1)

El 80% respondió que no usa paréntesis para estos métodos  y un 17% que sí usa paréntesis.

¿Encuentras los cops de métricas (como CyclomaticComplexity) útiles?

• Un poco útiles – 43%
• Muy útiles – 29%
• Inútiles – 19%
• Otro – 9%

Los autores lo tomaron como un área donde se puede mejorar.

Nivel general de felicidad con los valores por defecto de RuboCop

• Muy feliz – 15%
• Feliz – 47%
• OK – 23%
• No feliz – 8%
• Muy infeliz – 5%

Los resultados se ven como “no geniales, pero tampoco terribles”. Personalmente lo veo bastante bien, más de la mitad de los usuarios está al menos feliz. Con la versión 0.84 de RuboCop se hicieron cambios buscando mejorar estos resultados, y se van a venir más cambios

Feedback General

Al final de la encuesta había una sección abierta para más comentarios. Las respuestas resumidas:

• El valor de varios cops es subjetivo y estaría bueno que RuboCop tuviera algún preset con cops realmente esenciales (como cops para Linting y los que se corresponden con las convenciones e idiomas más fuertes).
• El valor de los cops de métricas es cuestionable. Hubo muchas sugerencias para relajar ciertos valores por defecto.
• Mucha gente parece odiar los frozen string literals.

El equipo planea trabajar en el primer punto y proveer un set más chico de cops esenciales, junto al actual set de cops por defecto en el futuro.

Una nota aparte de Bozhidar Batsov, cuando vio mucha gente quejarse de los cops de métricas, agregó una pregunta extra para saber si la gente sabía que pueden deshabilitar departamentos enteros de cops a través de .rubocop.yml. El 40% de los usuarios no lo sabía, y se puede hacer con:

Metrics:
  Enabled: true

También si no me equivoco, podemos empezar un archivo rubocop.yml deshabilitando TODOS los cops, de manera de ir definiendo de a uno aquellos que nos interesan en el proyecto.

El trabajo con esta encuesta y los cambios que ya vimos en RuboCop 0.84 muestran que el equipo de desarrollo está escuchando a la comunidad y ajustándose a las preferencias de la mayoría. La versión 1.0 está cerca, y avisan que es poco probable que haya más cambios de último momento, pero siempre existirá una versión 2.0 y 3.0.

RuboCop es una excelente herramienta y creo que gran parte de la negatividad que se le atribuye viene de no definir conenciones a nivel de un equipo o quedarse con las convenciones por defecto que no se adaptan necesariamente a las preferencias de un grupo de usuarios. Pero es bastante fácil de personalizar, y lo importante al final del día es ser consistente, más allá de si usamos ' o " para definir Strings.

Pueden leer más en RuboCop Defaults Survey Results.