Please spark joy in moderation and don’t style police on “idioms” like this one. It is distracting from work.
if to imagine solution of absence is good for answer.
btw… your post here regarding the minimal toggling:
In order to toggle, depending on the editor, the form also has to be evaluated. So I tend to have this type of code close to where I’m editing.
(comment
(def ^:dynamic *flag* true)
(def ^:dynamic *flag* false))
the good thing about dynamic vars is that you can have something like this:
(comment
(restart)
(binding [*flag* false]
(restart)))
I feel like the entire context is missing. Who’s moderating what? Who’s policing?
5 Likes
It’s just a convention, one that many people find useful. You can do whatever you like in your code, the Clojure compiler is not going to care.
If you’re collaborating with others then having some uniformity can be helpful. Maybe talk to your coworkers about expectations, and about what level of feedback is appropriate?
1 Like
oh god. I legitimately thought this was a cryptic post.
when has a few good uses, especially with code that may have side-effects or can only be written in imperative style:
(when something
(prn "STUFF")
{:status "ok"})
;; instead of
(if something
(do (prn "STUFF")
{:status "ok"}))
and fallthrough checks
(when check1
(prn "STUFF"))
(when check2
(prn "STUFF"))
2 Likes
And who’s policing the police?
I agree with the general sentiment, I hate style police, and am not a fan of style enforcers unless they can automatically rewrite my code to meet the style.
Style is subjective, and actually doesn’t matter for the actual functioning of the program. Style can help others read your code a little, if they’re used to a certain style and you keep to that same style. This is where I think the community Clojure style guide is useful, in that, if you don’t have your own style yet, better to adopt the most common style that helps others be familiar with your style if they ever need to read code, and vice versa.
That said, when and if are not the same, there’s a semantic difference that eventually makes it when will be used more so for side-effects, and I think that also means more often when there isn’t an else branch. when has an implicit do, so you can do multiple things in it. Over time I feel that has pushed me to also just adopt using when when I don’t need an else branch, and if otherwise. So that style just naturally developed for me.
1 Like
Still kind of cryptic to me. I understand what it’s about, but the subject line seems to be a quotation to which the OP is objecting. From where?
Pretty sure they’re railing against this: The Clojure Style Guide when vs if
I remember that Phil (technomancy) had very strong feelings about this too and at one point committed a change to Leiningen that replaced all of the single-expression, non-side-effecting when expressions in the entire codebase with if expressions (with no else branch).
Personally, I’m in the camp that says if should always have two branches – and if you really want (if cond something nil) it’s clearer to write (when cond something) than (if cond something)
But some people (like Phil, and the OP) seem allergic to when used in this way.
7 Likes
Thanks much for clarifying that @seancorfield.
(In a style guide, I expect style recommendations. 
I don’t have to follow them. But if I knowingly violate common norms, I should have a reason.)
(fwiw, I have mixed feelings about a when for the purpose of returning nil on false. On one hand, it’s concise, and if it’s common, then I can trust others to understand. But (if ... nil) makes the return value explicit, so I have less worry about others’ understanding. (Note: “others” always includes me at a later time.))
If it’s possible to refactor everything out into functions and make the branches all one-liners, then if is definitely clean, but the majority of the time, I find that I have code like this:
(if (check)
(let [a 1
b 2]
.....
.....
{:status "ok"})
{:status "error"})
Even with rainbow parens, indentation to help with visually inspect code, it’s still confusing. So in these situations I prefer an explicit :else clause, along with the stronger indentation.
(cond (check)
(let [a 1
b 2]
.....
.....
{:status "ok"})
:else
{:status "error"})
Where code is still in flux, it also becomes easier to extend a new branch with the cond keyword.
1 Like
I read ““spark joy” as a pot shot at clj-kondo. Why OP doesn’t just edit their settings instead of leaving a cryptic message on a forum, is a bit beyond my understanding, though, so maybe I am wrong.
Sometime I want to explicitly return nil in the else branch for clarity. Suggestions to replace all such cases with when is similarly counter productive.
1 Like
Thanks for many replies.
I wish for the standardization influencers, like clj-kondo, to tone down their strictness by a significant portion.
There is simply no productive value in standardizing stuff like this, or even engaging in deep discussions about which choice is right. Context matters. LISP is stylistically flexible by design. If used responsibly, this enables higher expressivity. That potential has a lot of value and must be protected.
For instance, one poster here mentioned explicitly returning nil in an else branch. I also like to do that in complicated cases where it helps to make a point that it is intentional. A reader suspecting a forgotten else branch on a bughunt will first notice the explicit intent. If you think it makes sense, do stuff like this! Why would a “linter” know better?
Somebody wrote a document on Github and calls it “The Clojure Style Guide”, as if it was something official to adhere to. When I contributed an issue to rename it to something less deceiving, like “Unofficial Clojure Style Guide”, it was declined.
New people coming to the language are naturally looking for “the right way”. Then they fall for the standardization influencers and stop exploring alternatives. They get offended by code that is written differently. Or they decline a suggestion to improve readability with a hyperlink to “The Clojure Style Guide”: “Look, I did right. What do you want from me?”. Poison.
What is useful can become a negative if done excessively. I think the problem space for standardization and conventions has been exhausted over the past 10+ years. When you look at a Clojure library on Github these days, you can perfectly read it. It is mostly so because people care, not machines telling them what is right.
What would you consider necessary for the style guide to be official? Would you consider it to be more official if it was published by the language designers, or the community?
I think there is great value in having a baseline of style guidelines, especially for a lisp that otherwise can easily fragment into many different sub-dialects.
It is then easy to build your style choices on that, as needed. For example, you can pretty easily change the severity of clj-kondo warnings. But at least then you can be explicit in making these style choices.
However, in my opinion it is better to just make a decision about style, or use an existing style guide, and then keep to that, and focus your attention on the bigger problems of design.
2 Likes
I’d say your problem is with your coworkers or whoever those people are that have influence on your code.
I found the Clojure style guide and clj-kondo to be great resources when I started, and it helped me with learning the language. Clj-kondo is actually really good at not doing style policing, and keeping most style issues optional, and focusing more on things that are actual bugs or possible mistakes. As for the style guide, I think any standard would have the issue you’re saying, they have to be opinionated in nature, otherwise it wouldn’t be “style”. Personally I’m happy at least there’s only one popular style guide. I think it’s great for beginners as well, and when you don’t know better, following it and having consistency is a good thing in my opinion.
As for my own code bases, I do what I want, and similarly with my team we agree on what we want for our shared code bases. The style guide is a good starting point though, and can also serve as a nice tie breaker when there’s disagreement.
3 Likes
I still don’t understand how does this affects you? Isn’t your gripe another imaginary problem?
- Isn’t it great that 99% of the rules that you agree with has already been codified by a tool/persons/influencers?
- That you can then concentrate on the actual architecture/implementation with said beginners?
- Isn’t that a good thing for companies that want consistency?
- Isn’t it great that individuals outside of cognitect have significant contributions to the language?
Linters are just rules and are opt in, not opt out.
1 Like
when actually is a nice way to quickly convey that there is no <else>. I think it expresses the intent better. Not really purely a “style” thing.
2 Likes