I think that would be a great addition to the style guide. I agree that "expression" is clearer than "term", though I'm not too worried about it not covering (define(f x)3). We could add stronger language later on as we get a sense of how people react to the initial wording.
On Monday, January 20, 2020 at 10:13:40 PM UTC-8, johnbclements wrote: > > I’m grading code, and one of my students keeps leaving out spaces in weird > places: > > (cond > [(< x 3)(+ x 1)] > [else (f(g 9))]) > > I took a quick look in the style guide, and it doesn’t seem to have much > to say about this. Here’s what it has: > > 6.8 Spaces > > Don’t pollute your code with spaces at the end of lines. > > If you find yourself breaking long blocks of code with blank lines to aid > readability, consider refactoring your program to introduce auxiliary > functions so that you can shorten these long blocks of code. If nothing > else helps, consider using (potentially) empty comment lines. > > *** > > To this text, I would like to add: > > “Every pair of expressions on a line should have at least one space > between them, even if they’re separated by parens. > > Wrong: [(< x 3)(+ x 1)] > Right: [(< x 3) (+ x 1)] > > Wrong: (f(g 3)) > Right: (f (g 3)) > > > Can anyone think of exceptions to this? One possible nit: since the rule > refers to “expressions”, it perhaps wouldn’t rule out (define(f x)3) . You > could say “term”, but I think it would be less clear. > > John > > > > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/aa025605-784b-4339-b8b3-b29f05800f45%40googlegroups.com.
