8

Currently I use:

(checkdoc)
(byte-compile-file (buffer-file-name))
(package-buffer-info)

to validate Elisp code. This takes me some stupid errors and it is easy to resolve them.

Code intending can be checked via C-x h C-M-\ C-x C-s M-x vc-diff if file under VCS.

What methods should I use to validate Elisp code for common errors?

gavenkoa
  • 3,352
  • 19
  • 36

1 Answers1

6

There are a couple of other options:

  • elint-defun, elint-file, and friends which are built-in to Emacs. elint mainly looks for undefined variables, misspellings, and wrong function calls. I found it of little use, since the byte compiler nowadays catches most (if not all) of these errors too. It's also painfully slow since it analyses all dependent libraries as well, and even worse, regularly chokes on macros. For instance, applying elint on code that makes heavy use of pcase delivers an awful lot of false positives.
  • flycheck-package provides some nice lints beyond the byte compiler and checkdoc. MELPA maintainers use it to check submitted packages as far as I know, and I myself use it in my packages to protect against formatting flaws in package headers.

Other than that, though, there's nothing on the linting table for Emacs Lisp. Particularly, we miss linters that catch for unidiomatic code, wrong API use, missing things, etc. For instance, there's nothing that tells you that you should replace references to ~/.emacs.d in your Elisp code with user-emacs-directory or even better locate-user-emacs-file, or warns about defcustoms with missing :type or :group, etc.