Re: Lisp/Scheme Style Guide

On Tue, 31 Aug 2010 15:41:13 -0700
Greg <greg <at> kinostudios.com> wrote:

> On Aug 31, 2010, at 2:35 PM, fin wrote:
> 
> >> The concept of the One-Style-To-Rule-Them-All is just childish.
> > 
> > Have you read "Style is Substance"?
> > http://www.artima.com/weblogs/viewpost.jsp?thread=74230
> 
> No, I hadn't, thanks for the link.
> 
> I tried to read the whole thing but stopped after reading what he considered to be "logic".
> 
> Premise #2 and #4 were introduced as facts yet consisted of 100% subjective opinion, that is, I think in
fact quite questionable.
> 
> I can rip them apart if you'd like:

Except you didn't. At best, you ripped apart a straw man based.

> Premise 2: There is not now, nor will there ever be, a programming style whose benefit is significantly
greater than any of the common styles.
> 
> All you have to do is take one look at the blood that has been spilled over this topic to see how untrue this
statement is.
> 
> People get very passionate about their preferred style, and if you ask them to write in another style they
will complain and cringe and claim that some such or other capability of theirs is being hampered.

Um, read the explanation: he's talking about productivity and code
quality. He didn't say people didn't care about styles, or weren't
passionate about styles. Which means you haven't addressed his issues,
just your straw man.

> He is making an objective claim about something that is totally, completely, subjective.

Productivity and code quality are totally, completely, subjective? So
all the many, many words written about things agile development,
quality engineering, productivity measures, software lifecycles, and
so on - are basically meaningless, because they're trying to improve
things that are totally, completely subjective?

> Premise 4: For any non-trivial project, a common coding style is a good thing.
> 
> Relevant quote: "having several folks hacking on the same code with conflicting coding styles
introduces more pain than any single style imposes on any single person."

I'm willing to grant that one on slightly less solid ground. He's
assuming that 1) the project chose a reasonable style, as opposed to
one designed to obfuscate code, and 2) that the people involved are
likewise not outliers, and can deal with any reasonable coding style.

But granted that, his statement pretty much stands as is.

> Here he introduces the concept of "conflicting coding styles" without explaining what the hell that is. I
have seen many projects that have different code style interspersed throughout, yet how they were
conflicting is beyond me. This is yet another area where he confuses subjectivity with objectivity.
Whether or not a code style is in so-called "conflict" with another is a completely subjective phenomenon
that depends on the observer.
> 
> In fact I regularly use different code styles within my own code, and they are in no way in conflict, in fact,
to me they very much appear to work together in harmony. Some scenarios lend themselves to one style, while
others lend themselves to a different one.

> My ability to not complain and adapt to understanding their style has not hurt but helped me as a programmer.
> 

OK, maybe you're one of the outliers, and don't have any problems with
reasonable (or even unreasonable) styles. Yeah, I can see how that
would help you.

I also regularly work on such projects myself, and changing styles in
mid-stream is similar to changing languages in mid-stream: I have to
reset how my mind parses things. That projects *have* style guides
indicate that others also have this problem. Just like Ken said -
adopting any single reasonable style causes me (and probably most
people) a lot less grief than letting me use my (or them use their)
preferred style but having to switch styles between files, or worse
yet, functions.

> Either you:
> 
> 1) Mandate code style to be a part of the language's syntax.
> 
> or you:
> 
> 2) Grow up and learn to accept the reality that some people think differently from you.

And the reason for the posting: you missed a VERY common third
alternative. Or at least, it's commonly suggested, though I don't know
that any project has actually implemented it:

3) Have your scm format code to canonical form when it's checked in.

     <mike
-- 
Mike Meyer <mwm <at> mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

--

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure <at> googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+unsubscribe <at> googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en