-
Notifications
You must be signed in to change notification settings - Fork 279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suffixing names of boolean values with a question mark? #182
Comments
Let's ask around. I don't do it myself (mostly because I'm too used to Ruby where this is not support for variables, only for methods), but I've seen many people doing so. |
+1 for appending |
Another 👍 for |
I regularly use |
I usually do this in bindings (argument names, local bindings, etc) and var names that are intended as predicates, but not for configured values in EDN files or metadata. This seems to be consistent with how it's done in Clojure and ClojureScript. You have
Also note the boolean configuration options for the ClojureScript compiler have no question marks: http://cljs.github.io/api/compiler-options/ So maybe:
|
That's also what we do at Pitch |
I do it only occasionally, in cases where it is really important for that particular binding to stick out. I think that recommending that for all boolean variables would raise lots of confusion, since in clojure anything can be treated as logical true/false. Whether something is boolean or just a regular logical value is not that important in most cases. Another source of confusion would be that, since predicated are suffixed with |
Another consideration for the style guide:
There was a lot of debate when Rich introduced a question-marked predicate in 1.7-1.9 (I can't remember which release) that didn't return a boolean. Eventually he changed it. |
I always do this for fns, defs and keywords in maps for boolean values. |
I'm not that experienced at programming so I might be completely misunderstanding the question. If you are suffixing a boolean value with a question mark instead of a function that returns a boolean then that seems wrong to me as a function that returns a boolean is a question and so it makes sense to suffix it with a question mark whereas a boolean value is not a question but can be an answer to a question. |
While I'm strongly in favor of I'm on the fence for local symbol bindings but lean toward not using So my preference is |
I definitely tend towards "?" For functions, not values. I generally use that to indicate "return value should be used for it's truthiness" without strictly meaning "Boolean", since it seems like Boolean are second class citizens in Clojure (needed only for interop, since truthiness is conventionally indicated by nil in Clojure) |
[to qualify my comment: I do not have nearly as much experience with Clojure as the other commenters here so take this into context please & feel free to ignore] I do like the elegance of the naming convention to use the
(They might also work with Additional thought: mnemonically I read the I think it often causes more confusion than clarity to have similar but slightly different things seem the same. |
We suffix variables as well as keywords in maps with Personally I think it enhances readability. Let's say you have a function (defn create-session! [& {:keys [user-session?]}]
(if user-session?
#_(create user session...)
#_(create non-user session...))) It's pretty clear that (defn create-session! [& {:keys [user-session]}]
(if user-session
#_(create user session...)
#_(create non-user session...))) It's not immediately clear whether |
I do this on functions return boolean but not on boolean values 👀 |
Yes, I think it would be more appropriate to name it |
When writing Clojure, I often will add a ? suffix to any boolean let bindings or defs. There is a strong convention of doing this for functions that return booleans.
Is there similar consensus that names of boolean values should be suffixed with a question mark?
See #136 as a similar issue, as well as https://guide.clojure.style/#pred-with-question-mark.
The text was updated successfully, but these errors were encountered: