On December 20, 2014 at 11:14:14 AM, Colin Fleming (colin.mailingl...@gmail.com) wrote: Hi everyone,
There's been a bit of discussion recently on a couple of clojure-mode tickets that I thought were worth discussing here. The tickets are #265 and #266, and they later led to PR #96 on Bozhidar Batsov's Clojure Style Guide. The part of the discussion I wanted to raise starts here, where there's some discussion around the nature of the style guide itself. Bozhidar clearly sees himself as the steward of a community style guide, something he's done to great success with the Ruby style guide. However it seems that there is a significant part of the community that didn't see it that way, and had seen it more as his personal style guide that he happened to put out there. I'm interested in starting a discussion around this because I do think it's valuable to have some degree of community consensus around these issues, specifically so that tools can have consistent defaults. I do not agree with everything on the guide on a personal level, which is a clear indication this is not a reflection of my personal preferences. On the other hand every such document needs an editor (or a few editors), otherwise chaos is bound the ensue. When I work on open-source projects I follow the style guide pretty closely, but on personal projects I do whatever pleases me. Even if people/teams/etc don’t agree with everything in a style guide, there’s lots of value in maintaining a consistent code base (which is the same as having a style guide). Forking the existing community guide is one of the easiest ways to quickly set up an internal project/company style guide. I believe that having at least some level of community-wide adopted standards simplifies the lives of everyone involved, because we spent less time dwelling on details (e.g. code layout) and more time thinking about solving the problems at hand. I actually want to talk about the value of style of at either Clojure/West or EuroClojure. We’ll see if this will actually happen. That said, one of the defining features of lisps in general is that they permit essentially unlimited flexibility, and in my experience programmers in general really don't like being told what to do, especially around indentation. So, I'd like to ask the obvious initial question - do we as a community think that there is value in having a style guide like this? If so, to Marshall's point on the list, do we think it should try to mandate what people should be doing, or should it describe what they actually currently do in real code, even if that's the result of historical accidents? I feel that we should promote the “best” (meaning most robust/sensible practices over those that are historical accidents). What qualifies as a historical accident, however, is rarely clear-cut. I’d argue that the `cond` 1-space indentation was one such case, but few other examples come to mind. While I realise that people always have personal preferences regarding code style, we should keep in mind that we rarely work by ourselves on a particular project and someone will always have to put their personal preferences aside. When we started the Ruby style guide there was little consensus regarding anything in the Ruby world. Pretty much every project I encountered had a style of its own, which introduced a certain cognitive burden on the readers of its source code. 4 years later there’s widespread consensus on a lot of basic stuff and that’s clearly visible. Sure, there are many aspects on which there will never be a consensus (often for a good reason), but having some baseline definitely beats having none at all. After all - making choices is pretty hard, so the less we have to make the better. For what it's worth, from my point of view I definitely think that a guide like this is useful, and I've referred to Bozhidar's guide myself from time to time when trying to decide what to do for a particular feature in Cursive. However I do think that it needs more flexibility than it currently has - there are some things marked in there as "bad" that I'd like to see downgraded to "prefer the other way unless you have a good reason", which of course I always feel like I have. In particular, some of the reasoning behind the linked changes above I think needs to be more flexible - there are good use cases for customising indentation for some functions, for example. The use of the words “good” and “bad” is somewhat unfortunate I guess; lately we’ve also been using “acceptable” and “preferable” as well. The guide ends with something like “use common sense”. The rules are mostly prescriptive - if you know Clojure well enough and you feel you have to violate some of them you should probably do so. Of course, if we decide that we do want a guide like this then we can spend many happy years arguing about what should go in it, but first things first :-) Cheers, Colin -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
