Pregunta sobre hábitos, no sobre sintaxis: ¿os ceñís siempre a la convención de nomenclatura estándar del lenguaje que usoéis, o tenéis alguna manía propia que arrastráis de proyecto en proyecto?

Las convenciones «oficiales» más conocidas: camelCase para variables y funciones en JavaScript, Java y C#; snake_case en Python y Ruby; PascalCase para clases en prácticamente todos los lenguajes orientados a objetos; SCREAMING_SNAKE_CASE para constantes.

Yo reconozco que tengo una manía: en cualquier lenguaje, prefijo las variables booleanas con es/tiene/puede (esActivo, tienePermiso, puedeEditar) aunque el lenguaje no lo pida, porque leído en voz alta el código se entiende mejor: «si es activo» en vez de «si activo».

¿Alguna manía similar que sigáis vosotros, aunque no esté en ninguna guía de estilo oficial?

Antonia G.

La mía: nunca abreviar términos del dominio de negocio, aunque el nombre quede largo. Prefiero fechaVencimientoContrato a fechaVtoCtr siempre, porque la abreviatura ahorra unos segundos al escribir pero cuesta bastante más tiempo de todos los que la leen después intentando descifrar qué significaba exactamente. El autocompletado del IDE hace que escribir el nombre largo no cueste prácticamente nada hoy, así que ya no hay ni excusa de "es que es mucho más rápido de teclear".

Otra manía que mantengo siempre: variables booleanas empiezan por is, has o puede/can según el idioma del proyecto (isActivo, hasPermiso), nunca un nombre "plano" ambiguo tipo activo a secas, que en una condición se lee peor (if (activo) no deja tan claro de un vistazo que es un booleano como if (isActivo)).

Y evito la notación húngara de toda la vida (prefijar el tipo en el nombre, strNombre, intEdad). Con el tipado que traen los IDEs modernos y el autocompletado, esa información ya está a un hover de distancia, meterla en el nombre solo lo alarga sin aportar nada que no tengas ya visible.

Carlos