Inline code in the docs - the correct way

[bachmeier]

On Monday, 5 February 2018 at 15:27:56 UTC, H. S. Teoh wrote:
> On Mon, Feb 05, 2018 at 09:50:38AM -0500, Steven Schveighoffer 
> via Digitalmars-d wrote:
>> On 2/5/18 1:27 AM, H. S. Teoh wrote:
>> > On Sun, Feb 04, 2018 at 02:34:31PM -0500, Steven 
>> > Schveighoffer via Digitalmars-d wrote: [...]
>> > > I don't have a hard time with braces. It tends to be worse 
>> > > with parentheses.  Generally these are indented properly, 
>> > > and not }}}}} all on one line.
>> > 
>> > Wait till you see Lisp code. :-P
>> 
>> I still have nightmares from my scheme class in college... 
>> Literally the professor would be up at the whiteboard 
>> scribbling a scheme function, and at the end, he would draw a 
>> whole bunch of closing parentheses in a row, reciting the 
>> opening parentheses for each one "car, cdr, ..."
>> 
>> I also have seen people's code who DID put all their closing 
>> braces on one line. It was... awful.
> [...]
>
> Apparently it's a prevailing style for Lisp and Lisp dialects 
> like Scheme.  Random example (this is in Guile, a Scheme 
> dialect, quoted from open source code):
>
> 	(define (match-predicate obj alist)
> 	  (if (null? alist)
> 	      "Unknown type"
> 	      (if (apply (caar alist) obj)
> 		  (cdar alist)
> 		  (match-predicate obj (cdr alist)))))
>
> The only way I can keep my sanity while editing this sort of 
> code is vim's jump-to-match feature.
>
>
> T

It's common in Scheme/Racket to use square brackets for nested 
terms:

(let ([x (random 4)]
       [o (random 4)])
   (cond
     [(> x o) "X wins"]
     [(> o x) "O wins"]
     [else "cat's game"]))

I find code written like your example (which is unfortunately 
quite common) to be no different from poorly-written Perl code. 
Properly indented and square bracketed Scheme code is easy to 
read.

One of the nice things about D IMO is that you have to work 
harder to write ugly code. Atrocities like chaining a bunch of 
function calls together don't look bad in D.