Non standard source formatting often reduces readability
Closed this issue · 9 comments
Compare the following 2 screenshots:
Current formatting. Without counting parentheses (or using delimiter coloration) it's unclear how many arguments are being passed to sucle-mp:submit.
Formatted with slime. Indentation makes it clear that it has been called with 1 standard argument and 2 keyword arguments
There seem to be many cases resembling the above. If this is how you prefer to indent your code then feel free to ignore/close, but otherwise I'd be happy to tweak the formatting as I read through.
Thank you for taking the time to screenshot both scenarios! The first image definitely looks like the code is improperly formatted. However, the following is what appears in my editor:
My guess for the difference is that my emacs uses 8-character width tabs, and looking at this area, there are a lot of tabs. It might be a good idea for me to update the entire codebase to use spaces instead of tabs, as well as add a style-guide.
It would be incredibly helpful and greatly appreciated if you tweaked the formatting to make it correct, but it is in a lot of places so I wouldn't want you to make it hard on yourself. If you really want to help update the formatting, we should probably write it down in a style-guide.
Unrelated, how did you get the 'lambda' to look like a single-character symbol? That seems like a nice plugin.
I didn't notice, but you are 100% right; I'm using 4 character tabs. I ran a quick emacs script to convert each tab in the project to 8 spaces and everything looks perfectly fine, so there shouldn't be any need to tweak anything manually.
As far as the lambda goes, emacs has built in support for that feature with prettify symbols mode. I also have M-l bound to insert "lambda".
(setq prettify-symbols-alist
'(("lambda" . 955) ; Replace instances of the word lambda with λ
))
(global-prettify-symbols-mode 1)
I believe emacs is getting more robust ligature support in version 27 which might improve this.
I can submit a PR for the tab->space conversion if you want, or I could share the script I used.
I’ll close this issue; a new one could be made for tabs vs spaces.
regarding tab vs spaces the correct way is tabs for indentation and spaces for alignment so everybody can set their tab width how they want. I also think that emacs can autoformat code like that.
I'm not sure that works for lisp where according to common style each line is offset a on a space by space basis, with no concept of levels of indentation at all. Every form is either a top level form or an argument, and arguments are offset at (offset of the form they were called on) + (character length of the function being called) with few exceptions.
Yeah you are right - according to this website most projects use two spaces. But I think autoformatting should still be possible. Unfortunately I don't have the time to look into that.
Autoformatting is trivially done with or without tabs using emacs or any other lisp ide. The original issue only came up because in a codebase that does contain tab characters, an emacs configured with a tab-width of 8 and one configured with a width of 4 disagree on the output, since formatting is done to visually allign forms with the same depth in the abstract syntax tree.
@mohe2015 https://ukupat.github.io/tabs-or-spaces/ that pie chart is pretty stark, its a wonder how I didn't notice that before...
Also, here is the issue for formatting/editors #45