even - Convenciones de nomenclatura del módulo Haskell
haskell return string (2)
¿Cómo debo nombrar mis módulos Haskell para un programa, no una biblioteca , y organizarlos en una jerarquía ?
Estoy haciendo un trazador de rayos llamado Luminosidad. Primero tuve estos módulos:
Vector Colour Intersect Trace Render Parse Export
Cada módulo estaba bien solo, pero sentí que esto carecía de organización.
Primero, coloqué todos los módulos en Luminosity , entonces, por ejemplo, Vector era ahora Luminosity.Vector (¿Supongo que esto es estándar para un programa de haskell?).
Entonces pensé: Vector y Color son independientes y podrían reutilizarse, por lo que deberían separarse. Pero son demasiado pequeños para convertirse en bibliotecas.
¿A dónde deberían ir? Ya hay (en hackage) un Data.Vector y un Data.Colour , ¿así que debería ponerlos allí? ¿O eso causará confusión (incluso si los importe agrupados con mis otras importaciones locales)? Si no está allí, ¿debería ser Luminosity.Data.Vector o Data.Luminosity.Vector ? Estoy bastante seguro de que he visto los dos usados, aunque tal vez me haya quedado mirando un proyecto utilizando una estructura no convencional.
También tengo un simple exportador de imágenes TGA ( Export ) que puede ser independiente de Luminosity. Parece que la ubicación correcta sería Codec.Image.TGA , pero de nuevo, ¿debería estar Luminosity en algún lugar y, de ser así, dónde?
Sería bueno si la Estructura de un proyecto de Haskell o algún otro wiki explicara esto.
En primer lugar pongo todos los módulos bajo
Luminosity
Creo que este fue un buen movimiento. Aclara a cualquiera que esté leyendo el código que estos módulos se crearon específicamente para el proyecto Luminosity .
Si escribe un módulo con la intención de simular o mejorar una biblioteca existente, o de llenar un espacio en el que cree que falta una biblioteca genérica en particular, en ese caso raro, elimine el prefijo y nómbrelo genéricamente. Para ver un ejemplo de esto, vea cómo el paquete de pipes exporta Control.Monad.Trans.Free , porque el autor, por cualquier motivo, no está satisfecho con las implementaciones existentes de las mónadas gratuitas.
Entonces pensé, Vector y Color son bastante independientes y podrían reutilizarse, por lo que deberían estar separados. Pero son demasiado pequeños para separarse en una biblioteca (125 y 42 líneas respectivamente). ¿A dónde deberían ir?
Si no crea una biblioteca separada, entonces probablemente los deje en Luminosity.Vector y Luminosity.Colour . Si crea bibliotecas separadas, intente enviar un correo electrónico a la audiencia objetivo de esas bibliotecas y vea cómo otras personas piensan que estas bibliotecas deben ser nombradas y categorizadas. El hecho de que los divida o no en bibliotecas separadas depende totalmente de usted y del beneficio que cree que estas bibliotecas separadas pueden proporcionar a otras personas.
A menos que su programa sea realmente grande, no organice los módulos en una jerarquía. Por qué no? Porque aunque las computadoras son buenas en la jerarquía, las personas no lo son. Las personas son buenas para los nombres significativos. Si elige buenos nombres, puede manejar fácilmente 150 módulos en un espacio de nombre plano.
Sentí que [un espacio de nombre plano] carecía de organización.
La organización jerárquica no es un fin en sí misma. Para justificar la división de módulos en una jerarquía, necesita una razón . Las buenas razones suelen tener que ver con la ocultación o reutilización de la información. Cuando trae información oculta, está a medio camino del diseño de una biblioteca y, cuando habla de reutilización, está construyendo una biblioteca de manera efectiva. Transformar un programa grande en "programa más pequeño más biblioteca" es una buena estrategia para la evolución del software, pero parece que recién estás comenzando, y tu programa aún no es lo suficientemente grande como para evolucionar de esa manera.
Estos problemas son en gran medida independientes del lenguaje de programación que está utilizando. Recomiendo leer algunos de los trabajos de David Parnas sobre líneas de productos y familias de programas, y también el papel poco apreciado de la modularidad jerárquica de Matthias Blume. Estas obras le darán algunas ideas más concretas acerca de cuándo la jerarquía comienza a cumplir un propósito.