Re: Clojure Style Guide

I get concerned whenever I see things like "rooted in lisp's DNA". Lisp is data, there is no formatting. If we want to argue tradition, we should stop ourselves and instead argue the points behind the tradition. It's not good enough to say "It's always been done this way..." We instead should say "

Re: Clojure Style Guide

On December 21, 2014 at 1:12:10 AM, Leon Grapenthin (grapenthinl...@gmail.com) wrote: Thanks for bringing this up here and linking to the issue I raised on GH. I wanted to start a discussion here as well but have not yet found time.  My concerns and worries are less about the style-guide in gene

Re: Clojure Style Guide

You can use `.dir-locals.el` to alter the clojure-mode indentation settings on a per-project basis. — Cheers,  Bozhidar On December 20, 2014 at 8:47:10 PM, Andy L (core.as...@gmail.com) wrote: Hi, I realized recently that cohesive pretty formatting LISP programs is a very difficult problem to

Re: Clojure Style Guide

On December 20, 2014 at 4:30:41 PM, Timothy Baldridge (tbaldri...@gmail.com) wrote: I recently browsed parts of that guide and was surprised how many bits I disagreed with. Especially around the "one space in these rare cases" bits. Not that that is a bad thing it's just my personal opinion that

Re: Clojure Style Guide

Yeah, shared (or at least as shared as possible) defaults would be awesome. I feel that the style guide might provide us with some insight about what those shared defaults should be. — Cheers,  Bozhidar On December 20, 2014 at 11:51:33 AM, Laurent PETIT (laurent.pe...@gmail.com) wrote: I agree

Re: Clojure Style Guide

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 B

Re: Clojure Style Guide

The only catch is that you should do this only for “relatively unique” names, as clojure-mode is not namespace aware. Otherwise you might get funky indentation in odd places. — Cheers,  Bozhidar On December 21, 2014 at 3:23:17 AM, Reid McKenzie (rmckenzi...@gmail.com) wrote: Protip: you already

Re: Clojure Style Guide

Protip: you already can. From my .emacs: (define-clojure-indent (defroutes 'defun) (GET 2) (POST 2) (PUT 2) (DELETE 2) (HEAD 2) (ANY 2) (context 2) (for-all 1) (such-that 1) (let-routes 1) (run-db 2) (defspec 'defun)) Reid On 12/20/14 16:28, John Jacobsen wrote: Great

Re: Clojure Style Guide

Thanks for bringing this up here and linking to the issue I raised on GH. I wanted to start a discussion here as well but have not yet found time. My concerns and worries are less about the style-guide in general and more about the indentation change regarding assoc introduced as default in cl

Re: Clojure Style Guide

Great to see this discussion on the mailing list, rather than just comments to PRs on GitHub. And a big thanks to Bozhidar for shepherding the current style guide. I came to Clojure from Python which has a strict standard (PEP-8) and a linting tool which enforces a standard -- it's been my exp

Re: Clojure Style Guide

On Saturday, December 20, 2014 12:53:41 PM UTC-5, Jonathan Irving wrote: > > It's not a docstring then, just the first expression in the body. > Leading to the interesting question: is the compiler smart enough to optimize it away? A string literal has no side effects so if its return value is u

Re: Clojure Style Guide

Hi, I realized recently that cohesive pretty formatting LISP programs is a very difficult problem to solve in the first place due to its homoiconicity. There could be some nice approximations but the devil is in the details. That all made me so grateful for what we have and I stopped complaining :

Re: Clojure Style Guide

That's true. I'm just saying I've accidentally done that before in single arity functions with no penalty. But if you count on cider or similar picking up docstrings from your own functions you'll want to do it the official way. --Ashton Sent from my iPhone > On Dec 20, 2014, at 10:53 AM, J I

Re: Clojure Style Guide

It's not a docstring then, just the first expression in the body. On Sat, Dec 20, 2014 at 12:05 PM, Ashton Kemerling < ashtonkemerl...@gmail.com> wrote: > > You can put the docstring after the args, but the tooling won't pick it > up. > > --Ashton > > Sent from my iPhone > > On Dec 20, 2014, at 10

Re: Clojure Style Guide

On Saturday, December 20, 2014 12:01:31 PM UTC-5, Eli Naeher wrote: > > Does anyone here know why in Clojure it was decided to move the docstring > from its traditional-in-Lisp location after the argument list? > In a nutshell, arity-overloading. -- You received this message because you are sub

Re: Clojure Style Guide

You can put the docstring after the args, but the tooling won't pick it up. --Ashton Sent from my iPhone > On Dec 20, 2014, at 10:01 AM, Eli Naeher wrote: > >> On Sat, Dec 20, 2014 at 8:30 AM, Timothy Baldridge >> wrote: >> >> And on a client project recently, it was decided (when I wasn'

Re: Clojure Style Guide

On Sat, Dec 20, 2014 at 8:30 AM, Timothy Baldridge wrote: > And on a client project recently, it was decided (when I wasn't around) > that the arguments to a function should always be on a newline: > > (defn foo > [x] > (+ x x)) > > Instead of: > > (defn foo [x] > (+ x x)) > Like you I pr

Re: Clojure Style Guide

Defaults only please. There are more pressing needs from dev tools than this sort of thing. Diversity is what makes us well... different. Our minds are not formatted the same either. What may look readable to someone may look like garbage to someone else, the context may also influence comprehe

Re: Clojure Style Guide

On Saturday, December 20, 2014 9:30:47 AM UTC-5, tbc++ wrote: > > I recently browsed parts of that guide and was surprised how many bits I > disagreed with. Especially around the "one space in these rare cases" bits. > Not that that is a bad thing it's just my personal opinion that everything >

Re: Clojure Style Guide

Sure, Tim, I also remember having disagreed with a fair amount of rules, and the very prescriptive style. The idea of just agreeing on same defaults for editors seems sufficient. Given sufficient lazy users like me, this one single rule of default values should be sufficient to help spread a comm

Re: Clojure Style Guide

I recently browsed parts of that guide and was surprised how many bits I disagreed with. Especially around the "one space in these rare cases" bits. Not that that is a bad thing it's just my personal opinion that everything should always use two space indentation. And on a client project recently,

Re: Clojure Style Guide

A way to hint indentation to the tooling would be nice. Perhaps a metadata on vars such as {:body-indent #{then-clause else-clause}} that could tell tools to indent an "if" this way: (if condition then-clause else-clause) instead of this way: (if condition then-clause else-clause)

Re: Clojure Style Guide

Let's start the list ! :-) 2014-12-20 10:57 GMT+01:00 Colin Fleming : > Yes, perhaps just agreeing on sane defaults is a more achievable goal. > Cursive currently does not indent everything exactly according to the guide > by default. I would also not like to see tools' ability to implement more

Re: Clojure Style Guide

Yes, perhaps just agreeing on sane defaults is a more achievable goal. Cursive currently does not indent everything exactly according to the guide by default. I would also not like to see tools' ability to implement more sophisticated formatting hampered by an overly restrictive guide either, since

Re: Clojure Style Guide

s/sale/same Le samedi 20 décembre 2014, Laurent PETIT a écrit : > I agree that if all tools could agree on sale out of the box defaults, > this would be very valuable to users and clojure in general. > > Maybe a less ambitious goal than getting the whole community agree on > standards could be t

Re: Clojure Style Guide

I agree that if all tools could agree on sale out of the box defaults, this would be very valuable to users and clojure in general. Maybe a less ambitious goal than getting the whole community agree on standards could be tool authors to agree on shared defaults. Which of course doesn't prevent the

Re: Clojure Style Guide

My view on this is very much along the line of discussions about whitespace. While I have opinions about these matters, for the most part I don't want to think about it--I have more pressing concerns. What's important to me is consistency within a code base. Just like with whitespace, I don'

Re: Clojure style

Thank you. My example was contrived as I was reading through the Clojure style guide (linked below). This kind of thing isn't specifically mentioned so I had the urge to try it and it works. That got me thinking that this would likely be bad style (hackish). I started Googling but did not find anyt

Re: Clojure style

Yes, I'd consider this bad style, for one, you don't get the arglists metadata showing the names of variables during a repl session. That metadata is on the var, and not the function itself. I'm not familiar with Math/pow's function signature off the top of my head. I would consider it only in t

Re: Clojure Style Guide

I agree - I thoroughly enjoyed this. On 30 March 2013 08:45, Alan Thompson wrote: > Hey - Just saw a nice article on this in (def newsletter) . It looks like > quite a good reference on the subject. > > https://github.com/bbatsov/clojure-style-guide

Re: Clojure Style Guide

Alan, Thanks for this. I've enjoy (and learn) a lot reading your clojure style guide! Great job. I think it deserve a link in clojure-docs.org I couldn't find anything similar on that page, wich I use a lot too. Regards, Erlis On Fri, Mar 29, 2013 at 3:45 PM, Alan Thompson wrote: > Hey - Just

Re: Clojure style question, mutable global data structures using Java?

BerlinBrown a écrit : > > On Jan 16, 12:47 pm, Christophe Grand wrote: > >> BerlinBrown a écrit : >> >> >>> Thanks all, this is what I ended up with: >>> For noobs like myself, I am using this code to monitor files and >>> refresh it when the file gets modified. I used 'ref' and 'agent'

Re: Clojure style question, mutable global data structures using Java?

On Fri, Jan 16, 2009 at 12:13 PM, BerlinBrown wrote: > > On Jan 16, 12:47 pm, Christophe Grand wrote: >> BerlinBrown a écrit : >> >> > Thanks all, this is what I ended up with: >> > For noobs like myself, I am using this code to monitor files and >> > refresh it when the file gets modified. I

Re: Clojure style question, mutable global data structures using Java?

On Jan 16, 12:47 pm, Christophe Grand wrote: > BerlinBrown a écrit : > > > Thanks all, this is what I ended up with: > > For noobs like myself, I am using this code to monitor files and > > refresh it when the file gets modified. I used 'ref' and 'agent'. > > > (def file-monitor-agent (agent

Re: Clojure style question, mutable global data structures using Java?

BerlinBrown a écrit : > Thanks all, this is what I ended up with: > For noobs like myself, I am using this code to monitor files and > refresh it when the file gets modified. I used 'ref' and 'agent'. > > (def file-monitor-agent (agent false)) > (def file-state (ref {:open-state false})) > (de

Re: Clojure style question, mutable global data structures using Java?

On Jan 16, 11:49 am, Christophe Grand wrote: > BerlinBrown a écrit : > > > On Jan 16, 11:10 am, BerlinBrown wrote: > > >> I am working on this GUI tool and want to keep 'global' data > >> structures in memory. For example, lets say I have a checkbox and > >> want to be able to keep and access

Re: Clojure style question, mutable global data structures using Java?

BerlinBrown a écrit : > > On Jan 16, 11:10 am, BerlinBrown wrote: > >> I am working on this GUI tool and want to keep 'global' data >> structures in memory. For example, lets say I have a checkbox and >> want to be able to keep and access the state of that checkbox at any >> time. Right now,

Re: Clojure style question, mutable global data structures using Java?

Hi Berlin, Probably ref, if the state must be coordinate with other state, or atom, if it is totally independent. But you might be able to avoid using mutable state at all. We would need a larger example to tell. Stuart > On Jan 16, 11:10 am, BerlinBrown wrote: >> I am working on this GUI

Re: Clojure style question, mutable global data structures using Java?

On Jan 16, 11:10 am, BerlinBrown wrote: > I am working on this GUI tool and want to keep 'global' data > structures in memory. For example, lets say I have a checkbox and > want to be able to keep and access the state of that checkbox at any > time. Right now, I am thinking the easiest thing