On Tue, 31 Aug 2010 15:41:13 -0700 Greg <g...@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 <m...@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@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
