camelCase and Source Code Formatting
Perm url with updates: http://xahlee.org/UnixResource_dir/writ/camelCase_code_formatting.html
camelCase and Source Code Formatting
Xah Lee, 2010-05-18
Xah Lee wrote:
(in emacs) Sometimes you want to delete the file of the current buffer. How do you do it? Here's a simple command that does it.(defun delete-current-file () "Delete the file associated with the current buffer." (interactive) (let (currentFile) (setq currentFile (buffer-file-name)) (when (yes-or-no-p (concat "Delete file: " currentFile)) (kill-buffer (current-buffer)) (delete-file currentFile) (message (concat "Deleted file: " currentFile)) ) ) )
Thomas Munro wrote:
Why use CamelCase
I find that using camelCase is a good way to distinguish my own symbol names from built-in ones.
Especially because emacs's emacs-lisp-mode's syntax coloring is flawed in that it only color about 10 or so keywords, rather against its own conventions in syntax coloring.
I've wrote some details of this before, see: Emacs Lisp Mode Syntax Coloring Problem.
Why use SETQ if you don't have to? How about this:(let ((current-file (buffer-file-name))) ...
I find that the
(let ((var1 val1) (var2 val2) ...) body)
form is harder to read, especially when not all your vars have pre- computable values, e.g.
(let (var1 (var2 val2) var3 (var4 val4)...) (setq var1 ...) ... (setq var3 ...) ...)
where many of the values are themselves compound expressions with many nested parens.
I think it is a good recommendation that one should always use:
(let (var1 var2 var3...) (setq var1 ...) (setq var2 ...) ... body )
and only use the (var val) form if all the vars are just local constants.
Since you intend to delete the file AND kill the buffer, why not say so in your inline doc?
Yeah, probably better to say in in the inline doc. Originally i just deleted the file. But then realized it left a dangling buffer. So i added code to remove buffer...
Though, i don't think stating the fact about also removing buffer is necessarily a good thing. My point of view is that, if you go by emacs tradition and technicality, then yes it should mention that buffer is also removed. However, the emacs tradition here, involving the concept of buffer, a computer engineering-by-product (like floats, int, long), is a major problem. Also, in vast majority of software, or other things involving info presentation, it is more important to communicate to the user than being technically correct.
Also, it could use a space and a question mark (at least the way YES-OR-NO-P works on my system, maybe yours is different). I would have written:
(when (yes-or-no-p (format "Delete file %s and kill buffer? " current-file)) ...
you are probably right.
(kill-buffer (current-buffer)) (delete-file currentFile) (message (concat "Deleted file: " currentFile)) ) ) )
Arrgh! My eyes! How about:(kill-buffer (current-buffer)) (delete-file current-file) (message "Deleted file: %s" current-file))))
I might have formatted it the way you did, but just haven't done so.
I consider this trivial, and consider that the common advice and attention for code formatting has done major damage to the computing industry, from wasting programer's time to long-term damage in the growth and direction of computer languages. I've written several articles about this. The key concept is hard-coded formatting vs semantic formatting. The following articles discuss it from various aspects.
- The Harm of Hard-wrapping Lines
- Tabs versus Spaces in Source Code
- A Simple Lisp Code Formatter
- A Text Editor Feature: Extend Selection By Semantic Unit
- Fundamental Problems of Lisp
In two of the articles, “the Harm of Hard-wrapping Lines” and “Fundamental Problems of Lisp”, it discuss the long-term consequences of focusing on the hard-coded formatting.