Comments (8)
Well, those macros are definitely not something particularly important, so no argument from me. The value they add is on the side of less typing, not clearer code. :-)
Might be good to use softer language for less important guidelines (such as https://guide.clojure.style/#when-not) - e.g. "Prefer" instead of "Use" or something along those lines.
from clojure-style-guide.
I don't think I've ever heard anyone advocate for this so I wouldn't say it was "widely-agreed" .
Looking at our 140k lines of Clojure, I see just 4 occurrences of (if (not= ..) ..)
and 3 of (if-not (= .. ..)
; I see 39 (when (not= ..) ..)
vs 48 (when-not (= ..) ..)
-- we have nearly 300 when-not
uses altogether.
I think there's an intention preference here around when
vs when-not
-- when
says "I want you to do these things when (this condition) is truthy" and when-not
says "I want you to do these things, except when (this condition) is truthy". I think that intention overrides what is in the condition expression itself.
I'm against adding it to the style guide but I'm not exactly in favor of it either.
from clojure-style-guide.
I agree with @seancorfield here, I wouldn't say I've seen strong consensus either way in the community. I can certainly see an argument for picking one approach in a company's internal style rules, but I'd be more hesitant about adding it to this style guide.
from clojure-style-guide.
Perhaps the suggestion should be simply to be consistent in the usage of such macros.
from clojure-style-guide.
FWIW, I don't really agree with the existing if-not
and when-not
guidelines -- I think they're already over-proscriptive (because of the "intention preference" I mentioned above).
Given the presence already of the guideline to use (not= ..)
instead of (not (= ..))
I can see a consistency argument in favor of adding the guidance @camsaul suggests but I don't agree with it in principle, just as I don't agree with the existing guidelines around these macros 😄
In other words, I don't feel strongly one way or the other -- it would just be another part of the style guide that I'd choose to ignore.
from clojure-style-guide.
On a more meta topic - I think that if-not
generally reads poorly and the negative branch should naturally be else
branch.
(if-not something
foo
bar)
;; same as above, but without the redundant negation
(if something
bar
foo)
That has nothing to do with Clojure, though. And I really think that unless
would have been a better name than when-not
, but that ship has sailed. 😄
from clojure-style-guide.
I think if-not
is more readable when the first branch is much shorter in length than the other branch.
Example:
(if-not something
foo
(let [...]
line-of-code
line-of-code
line-of-code
line-of-code
line-of-code
line-of-code
line-of-code
line-of-code
line-of-code
line-of-code
line-of-code
bar))
as opposed to
(if something
(let [...]
line-of-code
line-of-code
line-of-code
line-of-code
line-of-code
line-of-code
line-of-code
line-of-code
line-of-code
line-of-code
line-of-code
bar)
foo)
the difference is with if-not
we get one of the branches out of the way immediately and you can proceed to read the other branch without having to keep the fact that an else
branch is pending in mind for ten or twenty lines. It makes for less cognitive load
from clojure-style-guide.
Coming back to this nearly a year later: it seems like there's no further input and no clear consensus on the suggested guidelines (although I'm reading "leaning no" overall), so I propose we close this.
from clojure-style-guide.
Related Issues (20)
- Use keys of different length in let & map alignment example HOT 1
- Consider adding :no-doc under common metadata HOT 2
- Consider talking about defprotocol and deftype a bit more? HOT 2
- Multimethod Dispatch Val Placement advice impractical with docstring or attr-map HOT 2
- Clarify `if` indentation HOT 3
- Improve title HOT 2
- Consider updating/removing suggestions about complement, partial and comp HOT 6
- x, y - numbers -- only if x and y appear together? HOT 1
- Add section about Yoda conditions HOT 1
- No guidance on function arguments naming? HOT 1
- Add note about putting then and else forms on separate lines in `if` HOT 3
- cond-> and cond->> :always test expression HOT 6
- Idiomatic namespace alias for clojure.spec.alpha should be `s` instead of `spec` HOT 5
- Clarify `ns` form rules HOT 3
- The link to "The Joy of Clojure" is dead. HOT 4
- The link to "Clojure Programming" is dead HOT 1
- Italian translation HOT 1
- Threading macro alignment of first argument on it's own line HOT 2
- Test naming inconsist with function naming. HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from clojure-style-guide.