18 votos

Haskell módulo convenciones de nomenclatura

¿Cómo debo nombre de mi Haskell módulos de un programa, no una biblioteca, y organizarlos en una jerarquía?

Estoy haciendo un trazador de rayos llamado Luminosidad. Primero tenía estos módulos:

Vector Colour Intersect Trace Render Parse Export

Cada módulo fue bien en su propio, pero me pareció que carecía de organización.

Primero de todo lo que he puesto cada módulo bajo Luminosity, así por ejemplo Vector ahora era Luminosity.Vector (asumo que esta es la norma para un programa haskell?).

Entonces pensé, Vector y el Color son bastante independientes y pueden ser reutilizados, por lo que deben ser separados. Pero están en camino a la pequeña a separar en una biblioteca (125 y 42 líneas, respectivamente).

Dónde deben ir? Ya hay (en hackage) Data.Vector y Data.Colour, por lo que debo poner allí? O será que causa confusión (aunque yo la importación de los mismos agrupados con otros de mi local de las importaciones)? Si no lo hay, debería ser Luminosity.Data.Vector o Data.Luminosity.Vector? Estoy bastante seguro de que he visto, aunque tal vez sólo me ocurrió mirar en un proyecto con un no convencionales de la estructura.

También tengo una simple imagen TGA exportador (Export) que puede ser independiente de la Luminosidad. Aparece la ubicación correcta sería Codec.Image.TGA, pero de nuevo, debe Luminosity estar en alguna parte y si es así donde?

Finalmente he Parse que contiene JSON instancias para casi todo. ghc -Wall llama a estos huérfanos, pero creo que tiene mucho más sentido para mantener a todos juntos, ya que todos ellos son similares y la necesidad de la misma las funciones de comodidad. Text.JSON.Instances tendría sentido, salvo que este no es independiente, obviamente, y por lo que necesita para tener Luminosity en alguna parte.

Sería bueno si la Estructura de un Haskell proyecto o alguna otra wiki se explica esto.

12voto

Norman Ramsey Puntos 115730

A menos que su programa es realmente grande, no organiza los módulos en una jerarquía. ¿Por qué no? Porque aunque los equipos son buenos en la jerarquía, las personas no están. Las personas son buenas en nombres significativos. Si usted elegir buenos nombres se puede manejar fácilmente 150 módulos en un espacio de nombres llano.

Me sentí como [un espacio de nombres llano] carecían de organización.

La organización jerárquica no es un fin en sí mismo. Para justificar la división de los módulos en una jerarquía, usted necesita una razón. Buenas razones suelen tener que ver con ocultar información o reutilización. Cuando usted trae en ocultar información, están a medio camino a un diseño de la biblioteca, y cuando usted está hablando acerca de la reutilización, que son efectivamente la construcción de una biblioteca. Para transformar un gran programa en el "programa más pequeños de la biblioteca" es una buena estrategia para el software de la evolución, pero parece como si usted apenas está comenzando, y que su programa no está aún 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 la lectura de algunos de David Parnas del trabajo en líneas de producto y las familias del programa, y también Matthias Blume subestimado el papel Jerárquico de la Modularidad. Estos trabajos van a dar algunas ideas concretas acerca de cuando jerarquía comienza a servir a un propósito.

6voto

Dan Burton Puntos 26639

Primero de todo lo que he puesto cada módulo bajo Luminosity

Creo que este fue un buen movimiento. Se aclara a cualquier persona que está leyendo el código que estos módulos fueron hechos específicamente para la Luminosity del proyecto.

Si usted escribe un módulo con la intención de simular o mejorar una existente de la biblioteca, o de llenar un hueco donde usted cree que un particular genérico biblioteca no se encuentra, entonces en ese caso raro, colocar el prefijo y el nombre de forma genérica. Para un ejemplo de esto, ver cómo los tubos paquete de las exportaciones Control.Monad.Trans.Free, debido a que el autor era, por el motivo que sea, no está satisfecho con las implementaciones existentes de Libre mónadas.

Entonces pensé, Vector y el Color son bastante independientes y pueden ser reutilizados, por lo que deben ser separados. Pero están en camino a la pequeña a separar en una biblioteca (125 y 42 líneas, respectivamente). Dónde deben ir?

Si usted no hace una biblioteca independiente, entonces, probablemente, los dejan en Luminosity.Vector y Luminosity.Colour. Si se hacen las bibliotecas independientes, a continuación, tratar de correo electrónico de los destinatarios de esas bibliotecas y ver como otras personas piensan que las bibliotecas deben ser identificados y clasificados. O si no te dividir estos en las bibliotecas independientes es totalmente de usted y cuánto beneficio crees que estas bibliotecas pueden proporcionar para otras personas.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X