-
Notifications
You must be signed in to change notification settings - Fork 297
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
Open call for improving variable naming in Persistent #1156
Comments
I am strongly in favor of this. Expanding |
I think
|
welp, that does it 😂 |
Ok, I would propose we pin this issue, and I edit the top to be an open call for improving the naming of any code in Persistent. Separately, as people see confusing names, they can add specific issues to target a specific snippet of code. |
This issue is an open call to improve variable naming in Persistent. Persistent is littered with code that uses extremely short variable names, which makes the code much harder to read. Consider this issue an indication that you can open a PR to improve names anywhere in the codebase.
For the original issue about this, see below:
When I read the Persistent codebase, it's often challenging to figure out what is going on, and I attribute a lot of this to very short variable names. I took a few examples from the codebase:
This code is littered with tiny variable names. What is
mid
exactly?What is
n
here? And what isrest
—rest
could be therest
of anything. Is it worth saving a handful of characters to writeps
vspersistSettings
, which is extremely clear?What is
n
?nu
?In all these cases, you can figure it out, but imo it's way harder than it should be. Here's some code I've written in Persistent I find much easier to read (admittedly this is very biased b/c I wrote it):
I can totally imagine these functions being harder to read if they used names like
ues
instead ofunenabledExtensions
, orneV
instead ofneVersion
for example.I would propose that Persistent:
We could identify code snippets that could be improved, and open an issue for them and tag it as
Newcomer
to help migrate old code.I think using shorter names can be fine in some cases, like where:
a. The variable is polymorphic, e.g.
map :: (a -> b) -> [a] -> [b]
, so a long name likeelement
isn't really helping.b. There is a strong convention, e.g.
(x:xs)
c. The scope is very small, e.g.
extensionToPragma ext = "{-# LANGUAGE " <> show ext <> " #-}"
is short enough that I always have context for whatext
is, vs a 15 line function.But even these can be questionable, e.g. what is
c
here?I might be swimming against Haskell currents here—I started programming Objective-C which is known for extremely verbose names. Thoughts?
The text was updated successfully, but these errors were encountered: