¿Es mejor documentar las funciones en el archivo de encabezado o en el archivo de origen?

77

En los idiomas que distinguen entre un archivo "fuente" y un "encabezado" (principalmente C y C ++), es mejor documentar las funciones en el archivo del encabezado:

(extraído de CCAN )

/**
 * time_now - return the current time
 *
 * Example:
 *  printf("Now is %lu seconds since epoch\n", (long)time_now().tv_sec);
 */
struct timeval time_now(void);

o en el archivo fuente?

(extraído de PostgreSQL)

/*
 * Convert a UTF-8 character to a Unicode code point.
 * This is a one-character version of pg_utf2wchar_with_len.
 *
 * No error checks here, c must point to a long-enough string.
 */
pg_wchar
utf8_to_unicode(const unsigned char *c)
{
...

Tenga en cuenta que algunas cosas se definen solo en el encabezado, como las funciones structs, macros y static inline . Solo estoy hablando de cosas que están declaradas en un archivo de encabezado y definidas en un archivo fuente.

Aquí hay algunos argumentos que se me ocurren. Me inclino por documentar en el archivo de origen, por lo que mis argumentos de "Pro-header" pueden ser un tanto débiles.

Pro-header:

  • El usuario no necesita el código fuente para ver la documentación.
    • La fuente puede ser inconveniente, o incluso imposible, de adquirir.
    • Esto mantiene la interfaz y la implementación aún más separadas.

Pro-source:

  • Hace que el encabezado sea mucho más corto, lo que brinda al lector una visión general del módulo en su conjunto.
  • Empareja la documentación de una función con su implementación, lo que facilita ver que una función hace lo que dice que hace.

Al responder, tenga cuidado con los argumentos basados en lo que pueden hacer las herramientas y los "IDE modernos". Ejemplos:

  • Pro-header: el plegado de código puede ayudar a hacer que los encabezados comentados sean más navegables ocultando los comentarios.
  • Pro-source: la función Find this global definition de cscope lo lleva al archivo de origen (donde la definición is) en lugar del archivo de encabezado (donde está la declaración )

No estoy diciendo que no hagas esos argumentos, pero ten en cuenta que no todos se sienten tan cómodos con las herramientas que usas como tú.

    
pregunta Joey Adams 15.06.2011 - 06:15

8 respuestas

90

Mi vista ...

  • Documente cómo usar la función en el archivo de encabezado, o más cerca de la declaración.

  • Documente cómo funciona la función (si no es evidente en el código) en el archivo fuente, o más exactamente, cerca de la definición.

Para la cosa de ojo de pájaro en el encabezado, no necesariamente necesitas la documentación que se cierra, puedes documentar grupos de declaraciones a la vez.

Hablando en términos generales, la persona que llama debe estar interesada en los errores y las excepciones (aunque solo sea así, para poder traducirlos a medida que se propagan a través de las capas de abstracción), por lo que estos deben documentarse cerca de las declaraciones relevantes.

    
respondido por el Steve314 15.06.2011 - 07:15
30

Si va a utilizar una herramienta como Doxygen (observe en el primer ejemplo, que realmente parece un comentario de Doxygen porque comienza con /** ) entonces realmente no importa: Doxygen revisará su encabezado y los archivos de origen y encontrará todos los comentarios para generar la documentación.

Sin embargo, estaría más inclinado a poner los comentarios de la documentación en los encabezados, donde están las declaraciones. Sus clientes tratarán con los encabezados para interactuar con su software, los encabezados son lo que incluirán en sus propios archivos de origen y es ahí donde buscarán primero cómo se ve su API.

Si observa la mayoría de las bibliotecas de Linux, por ejemplo, su sistema de administración de paquetes de Linux a menudo tiene un paquete que contiene solo los binarios de la biblioteca (para usuarios "normales" que tienen programas que necesitan la biblioteca) y usted tiene un "dev "paquete que contiene los encabezados de la biblioteca. El código fuente normalmente no se suministra directamente en un paquete. Sería realmente engorroso si tuviera que obtener el código fuente de una biblioteca en algún lugar para obtener la documentación de la API.

    
respondido por el Jesper 15.06.2011 - 09:26
10

Resolvimos este problema (hace aproximadamente 25 años) mediante la creación de un grupo de #defines (por ejemplo, público, privado, etc., que se resolvieron en < nada >) que se pudieron usar en el archivo de origen y fueron analizados por un Script awk (¡horrores!) para generar automáticamente los archivos .h. Esto significa que todos los comentarios se guardaron en la fuente y se copiaron (cuando fue apropiado) en el archivo .h generado. Sé que es bastante antigua, pero simplificó enormemente este tipo de documentación en línea.

    
respondido por el Peter Rowell 15.06.2011 - 06:31
5

En mi opinión (bastante limitada y parcial), soy una forma de pensar de código pro-fuente. Cuando hago bits y piezas en C ++, generalmente edito el archivo de encabezado una vez y nunca vuelvo a verlo.

Cuando coloco documentación en el archivo de origen, siempre la veo cuando edito o leo códigos. Supongo que es una cosa de costumbre.

Pero eso es solo yo ...

    
respondido por el MattyD 15.06.2011 - 06:21
5

Los comentarios no son documentación. La documentación para una función puede ser típicamente 2K de texto, posiblemente con diagramas; consulte, por ejemplo, la documentación de las funciones en el SDK de Windows. Incluso si su comentario-a-doc lo permite, usted hará que el código que contiene el comentario sea ilegible. Si desea producir documentación, utilice un procesador de textos.

    
respondido por el Neil Butterworth 15.06.2011 - 08:56
5

Suponiendo que este es el código dentro de un proyecto más grande (donde los desarrolladores se moverán entre la fuente y los encabezados a menudo) , y si este no es una biblioteca / software intermedio, donde otros pueden no tener acceso a la fuente, he encontrado que esto funciona mejor ...

  • Encabezados:
    Terseo 1-2 comentarios de línea, solo si son necesarios.
    A veces los comentarios sobre un grupo de funciones relacionadas también son útiles.
  • Fuente:
    Documentación en API directamente sobre la función (texto sin formato o doxygen, si lo prefiere) .
  • Mantenga los detalles de la implementación, solo relevantes para un desarrollador que modifique el código en el cuerpo de la función.

La razón principal de esto es mantener los comentarios cerca del código, he notado que los documentos en los encabezados tienden a desincronizarse con los cambios en el código con más frecuencia (por supuesto, no deberían hacerlo, pero Lo hicieron en nuestro proyecto al menos) . También los desarrolladores pueden agregar documentación en la parte superior de las funciones cuando hacen algún cambio, incluso si hay documentos de cabecera ... en otro lugar. Causando duplicaciones o información útil solo para estar en una de las cadenas de documentos.

Por supuesto, puedes elegir una convención y asegurarte de que todos los desarrolladores sigan, acabo de encontrar la convención por encima de la más natural-fit y causa menos problemas para mantener.

Por último, para proyectos grandes: hay una inclinación no para hacer pequeñas correcciones en un encabezado cuando se sabe que esto causará que posiblemente se vuelvan a compilar 100 o 1000 archivos cuando otros actualicen la versión control - ralentizando los errores de bisección también.

    
respondido por el ideasman42 12.10.2015 - 15:15
4

Si las partes interesadas de su código fuente (por ejemplo, una pequeña biblioteca) se compone de "usuarios" (compañeros desarrolladores que usarán la funcionalidad de su biblioteca sin involucrarse en su implementación) y "desarrolladores" (usted y otros desarrolladores que implementarán la biblioteca), luego coloque la "información de los usuarios" en el encabezado y la "nota de implementación" en la fuente.

Con respecto al deseo de no cambiar los archivos de encabezado más de lo que es absolutamente necesario, supongo que si su biblioteca no está "en un flujo de cambios loco", la "interfaz" y la "funcionalidad" no cambiarán mucho , y tampoco los comentarios del encabezado deben cambiar con demasiada frecuencia. Por otro lado, los comentarios del código fuente deberán mantenerse sincronizados ("nuevos") con el código fuente.

    
respondido por el rwong 15.06.2011 - 06:33
1

El punto central del uso de doxygen es que genere la documentación y la haga accesible en otro lugar. Ahora toda la documentación en los encabezados es simplemente basura, lo que hace que sea más difícil detectar rápidamente la declaración de función requerida, y tal vez sus sobrecargas. Un comentario de línea es el máximo que debería ir allí, pero incluso eso es una mala práctica. Porque si cambia la documentación en la fuente, vuelve a compilar esa fuente y la vuelve a vincular. Pero si coloca documentos en el encabezado, realmente no desea cambiar nada, ya que provocará una parte importante de la reconstrucción del proyecto.

    
respondido por el Slava 05.07.2017 - 11:25

Lea otras preguntas en las etiquetas