No hay una diferencia significativa entre lo que hace que un buen programador en general y un buen programador OCaml en particular.
Debe tenerse en cuenta que la profesión de ingeniero de software tiene otros requisitos además de ser un buen programador, incluida la comunicación con el equipo y la comprensión del producto, pero no nos centremos en esto.
Las características esenciales de un buen programador o software bien escrito incluyen:
- ¿Por qué los costos son tan altos en el desarrollo de software?
- ¿Cuál es el área más grande en el desarrollo de software?
- ¿Las entrevistas de trabajo fallidas (desarrollador de software) afectan negativamente a su marca personal como candidato para las oportunidades futuras?
- Soy un desarrollador de software aspirante! ¿Cuáles son las cosas que te tomaron un tiempo en resolver pero que son fundamentales para el éxito de un programador?
- Como desarrollador de software, ¿es un problema si veo la programación como un trabajo más?
- Código legible consistente con las mejores prácticas y convenciones para el lenguaje.
- modularidad y componibilidad: en la medida de lo posible, cada unidad que implemente una característica particular (función, módulo, biblioteca) no debe enredarse con la implementación de otras características. Esto hace posible volver a implementar o descartar funciones o dependencias sin afectar el resto del programa.
- minimalismo: se puede lograr que el programa sea simple de mantener y construir al hacer elecciones inteligentes y no depender demasiado. Por ejemplo, uno puede elegir usar una gran biblioteca porque uno de sus módulos es particularmente útil, pero eso no significa que sea una buena idea depender aleatoriamente de otras partes de esa biblioteca cuando no es crítico.
Al mirar el código OCaml escrito por un programador experimentado de OCaml, generalmente desconfío de los siguientes signos:
- formato sucio, no estándar: líneas de más de 80 caracteres, identificadores que usan camelCase en lugar de minúsculas_y_colecciones, sangría incorrecta o muy inusual
- identificadores sin sentido utilizados con poca frecuencia pero lejos de donde se definieron, por ejemplo, x
- identificadores excesivamente largos utilizados solo localmente, por ejemplo, result_of_the_function
- identificadores o comentarios en un idioma que no sea inglés
- uso frecuente del estado mutable compartido (referencias, globales, cerraduras …) cuando no tiene un beneficio claro
- uso de estructuras de datos inmutables demasiado complicadas o lentas en las que una matriz simple, un búfer o referencia sería más clara y rápida
- El abuso de listas donde una tabla hash o un mapa sería apropiado
- La falta de comentarios básicos que expliquen de qué trata el programa / módulo / función y dónde encaja
- comentarios que parafrasean el código fuente
- código repetitivo repetitivo donde una solución genérica obvia sería mejor
- abstracción excesiva: parametrización de cosas que se instancian solo una vez y dividen una unidad lógica en múltiples fragmentos en lugar de aislar características no relacionadas (abuso de funciones y functores de orden superior)
- ausencia de pruebas automáticas
- falta de un comando para construir el proyecto de una sola vez