[racket] Racket style guide (was Re: Argument order conventions (was: Variable naming conventions))

Matthias Felleisen wrote at 09/22/2011 12:14 PM:
> Personally, I'd love to see even more of a separation between the header (data + provide) and the implementation. Perhaps I read too much Modula 2 code, perhaps I liked units too much. 
>   

Modula-2 made me a better software engineer using C around 20 years ago, 
in a surprisingly good community college course.  However, thank 
goodness I never had to do real work in Modula-2.  We implemented a 
spreadsheet program as a team project, with a rule that we weren't 
allowed to see other people's Modula-2 implementation files.  It was an 
educational experience, in team dynamics as much as anything else.  But 
we were not at all fond of klunky and annoying Modula-2 setup (perhaps 
somewhat like people who used an impoverished Scheme implementation for 
annoying problem sets in college decided they disliked Scheme).  We 
would've been much happier with Turbo Pascal, and I wonder whether 
whether we could have learned just as well using TP units and some 
conventions to discipline us about interface vs. implementation.  Based 
on industry experience immediately after that, working in C on large 
high-end workstation software and fancy embedded systems tools, I'd say 
that the Modula-2 experience taught one very useful discipline that few 
of the C developers at the time seemed to have a good grasp of.

I wonder whether anyone using Racket for a course with a large team 
project has tried forbidding team members from looking at each other's 
implementations -- let them work only from module interface docs or 
something like Racket's "sig"s -- and how that worked out.  It might be 
harder to do nowadays, due to many students having preconceived ideas of 
how team projects work, based on all the public open source projects, 
the popularized codification of Agile cowboy methodologies, and on 
post-dotcom title inflation-- students might not believe you if you say 
"this is how *software engineering* is done."

-- 
http://www.neilvandyke.org/