Convención de comentarios de Lisp


¿Cuál es la convención Lisp sobre cuántos puntos y coma usar para diferentes tipos de comentarios (y cuál debe ser el nivel de sangría para varios números de puntos y coma)?

Además, ¿hay alguna convención sobre cuándo usar comentarios con punto y coma y cuándo usar #|multiline comments|# (asumiendo que existen y existen en múltiples implementaciones)?

Author: nbro, 2011-06-16

4 answers

En Common Lisp:

;;;; At the top of source files

;;; Comments at the beginning of the line

(defun test (a &optional b)
  ;; Commends indented along with code
  (do-something a)                      ; Comments indented at column 40, or the last
  (do-something-else b))                ; column + 1 space if line exceeds 38 columns

Nota: Emacs no fontifica #| |# muy bien, pero como Rainer sugiere en los comentarios, intente usar #|| ||# en su lugar.

Yo diría que no hay reglas para usar esta, pero creo que es más rápido para comentar grandes cantidades de código, o para insertar alguna descripción larga donde los puntos y comas solo se interponen en el camino de la edición, como enormes listados BNF o similares.

Hay un buen truco para desactivar el código que es prefijar una expresión con #+(or):

(defun test (a &optional b)
  #+(or)
  (do-something a)
  (do-something-else b))

Nota: #+nil generalmente funciona también, a menos que tenga una característica nil o :nil. La ventaja de #+(or) es que puede editarlo fácilmente comentándolo o cambiándolo a #+(and), o incluir realmente un conjunto de características sobre las que realmente desea que se lea esa expresión.

SLIME ayuda aquí al fontificar el formulario (do-something a) como un comentario cuando se tiene un Lisp en ejecución.

Aparte de la particular sintaxis de comentarios y trucos de Common Lisp, como #| |# y #+(or) o las más comúnmente vistas #+nil, creo que las reglas de punto y coma también se adoptan ampliamente en otros lisps.


Aquí hay un extracto de la especificación , observe cómo la práctica actual ha divergido con respecto al punto y coma único:

2.4.4.2 Notas sobre el estilo para Punto y coma

Algunos editores de texto hacen suposiciones sobre la sangría deseada basándose en el número de puntos y comas que comienzan un comentario. Las siguientes convenciones de estilo son comunes, aunque de ninguna manera universales.

2.4.4.2.1 Uso de un punto y coma

Los comentarios que comienzan con un solo punto y coma están todos alineados a la misma columna a la derecha (a veces llamada "columna de comentarios"). El texto de tal comentario se aplica generalmente sólo a la línea en la que aparece. De vez en cuando dos o tres contienen una sola oración juntos; esto se indica a veces por sangría todos menos la primera con un espacio adicional (después de la coma).

2.4.4.2.2 Uso del punto y coma doble

Los comentarios que comienzan con un punto y coma doble están alineados al mismo nivel de sangría que una forma estaría en la misma posición en el código. El texto de tal comentario generalmente describe el estado del programa en el punto donde se produce el comentario, el código que sigue al comentario, o ambos.

2.4.4.2.3 Uso del punto y coma triple

Los comentarios que comienzan con un punto y coma triple son todos alineados al margen izquierdo. Por lo general, se utilizan antes de una definición o conjunto de definiciones, en lugar de dentro de una definición.

2.4.4.2.4 Uso del punto y coma Cuádruple

Los comentarios que comienzan con un punto y coma cuádruple están todos alineados al margen izquierdo, y generalmente contienen solo un fragmento de texto corto que sirve como título para el código que sigue, y podría usarse en el encabezado o pie de página de un programa que prepara el código para su presentación como una copia impresa documento.

2.4.4.2.5 Ejemplos de estilo para Punto y coma

;;;; Math Utilities

;;; FIB computes the the Fibonacci function in the traditional
;;; recursive way.

(defun fib (n)
  (check-type n integer)
  ;; At this point we're sure we have an integer argument.
  ;; Now we can get down to some serious computation.
  (cond ((< n 0)
         ;; Hey, this is just supposed to be a simple example.
         ;; Did you really expect me to handle the general case?
         (error "FIB got ~D as an argument." n))
        ((< n 2) n)             ;fib[0]=0 and fib[1]=1
        ;; The cheap cases didn't work.
        ;; Nothing more to do but recurse.
        (t (+ (fib (- n 1))     ;The traditional formula
              (fib (- n 2)))))) ; is fib[n-1]+fib[n-2].
 60
Author: acelent,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-05-25 10:56:00

Los comentarios multilínea #| |# a menudo se usan para comentar grandes cantidades de código Lisp o código de ejemplo. Dado que algunas implementaciones de Emacs parecen tener problemas para analizarlas, algunas están usando # / / / / # en su lugar.

Para el uso de punto y coma ver el ejemplo de comentario en el libro Common Lisp the Language (página 348), 1984, Digital Press, por Guy L. Steele Jr.:

;;;; COMMENT-EXAMPLE function. 
;;; This function is useless except to demonstrate comments. 
;;; (Actually, this example is much too cluttered with them.) 

(defun comment-example (x y)      ;X is anything; Y is an a-list. 
  (cond ((listp x) x)             ;If X is a list, use that. 
        ;; X is now not a list.  There are two other cases. 
        ((symbolp x) 
        ;; Look up a symbol in the a-list. 
        (cdr (assoc x y)))        ;Remember, (cdr nil) is nil. 
        ;; Do this when all else fails: 
        (t (cons x                ;Add x to a default list. 
                 '((lisp t)       ;LISP is okay. 
                   (fortran nil)  ;FORTRAN is not. 
                   (pl/i -500)    ;Note that you can put comments in 
                   (ada .001)     ; "data" as well as in "programs". 
                   ;; COBOL?? 
                   (teco -1.0e9))))))

En este ejemplo, los comentarios pueden comenzar con uno a cuatro puntos y coma.

  • Punto y coma simple todos los comentarios están alineados a la misma columna a la derecha; por lo general, cada comentario se refiere solo al código al que está al lado. Ocasionalmente un comentario es lo suficientemente largo como para ocupar dos o tres líneas; en este caso, es convencional sangrar las líneas continuas del comentario un espacio (después del punto y coma).

  • Los comentarios de punto y coma doble están alineados con el nivel de sangría del código. Un espacio convencionalmente sigue los dos puntos y coma. Tales comentarios suelen describir el estado de la programa en ese punto o la sección de código que sigue al comentario.

  • Los comentarios de punto y coma triple están alineados con el margen izquierdo. Por lo general, documentan programas enteros o bloques de código grandes.

  • Los comentarios de punto y coma cuádruple suelen indicar títulos de programas enteros o bloques de código grandes.

 28
Author: Rainer Joswig,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-09-03 11:39:36

La referencia estándar para el estilo Common Lisp, incluyendo las convenciones de comentarios, es el Tutorial de Peter Norvig y Kent Pitman sobre un Buen Estilo de Programación Lisp.

 8
Author: Peter S. Housel,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-06-16 01:06:26

En lugar de describirlo aquí, echa un vistazo a esta página. Está hablando de Emacs Lisp, pero la convención es la misma en todos los lisp (y esquemas).

 6
Author: Eli Barzilay,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-06-15 23:11:12