Hacker News Reader

Comment by samsquire | Hacker News Reader

Clean code is code you and others can understand and everybody seems to have a different idea of that.

Sentence long variable names I don't like, they slow me down when thinking about or remembering what to do I'm not sure you can remember the names without Intellisense/IntelliJ autocomplete.

I don't think I would enjoy working on this codebase.

View on HN

The recommendation I read back in the 90's in Code Complete that has served me well ever since was that variable name length should be roughly proportional to the variable span. "Variable span" being the distance between where the variable is first defined and its last use. Generally that means that a temp variable inside a short function can be a single letter since you can see the full context of its entire lifecycle right there and it's unlikely to be confusing; indeed, a short variable name in that case will often be much easier to read and work with than a longer one. OTOH, a global or exported variable that might be accessed in different files from where it is defined or used across thousands of lines really needs to be descriptive enough that anyone encountering it should know what it's for without having to backtrack to where it was defined. A variable name that's a few words long might be entirely appropriate for that. A corollary is that a large variable span is often an indicator of a bad design. So if you find that you need really long variable names to make your code easy to understand, you might want to step back and see if you could set up some better or different boundaries.

I've found this to be a much better rule of thumb than "always use long variable names" or "always use short variable names".

Thank you. I'd read CC ... 15+ years ago, but couldn't remember this specific step (but I know I've internalized it). I had criticism from folks a couple years back because I used "x" and "i" as variable names in loop counting - for (x=0; x<limit; x++) - that sort of thing. I had folks block my PR because "don't use short variables - that's unprofessional". These were loops inside a test file, and, at that time (8 months after launch), I was committing the first test to the project. It was blocked while I had to think of something better, like for(loop=0; loop<limit; loop++) - which was deemed "acceptable".

This concept from CC was at the back of my mind, but couldn't articulate it, or even remember where I'd first read about it, but it's been something I've worked at adopting and growing over the years. 6 line loops - x/i/j/k/etc are all valid and usable. In some ways, it's actually more helpful to me, because the longer names indicate something concrete/real, and the single letter names indicate local/throwaway values.

For Java and Python for each loops I often use "current" or a singular name for the thing being iterated. If it's a nested loop then I use "other".

For C and JavaScript I use single letter indexes ijkl or "current".

I think it's a personal preference. I don't think there is a wrong way or a right way. Your team needs to agree though. I would be annoyed if I implemented a deep feature and the PR was blocked due to something as inane and useless as this.

I don't mind "i", but if there's an inner loop with "j" as well, you are BEGGING for confusion.

I got down to "k" too. What about "x" and "y"? One important consideration of nested loops is row major access pattern rather than column major pattern, so access array[i][j] rather than array[j][i] due to the data locality of each. You shall get a performance boost by accessing them in that order.

I worked on parallelizing nested loops across OS threads and load balancing between outer loops for different progressions through the loop. I also wrote some code to reverse the loop direction to avoid a cache miss when the indexes go back to 0.

https://github.com/samsquire/multiversion-concurrency-contro...

`x` and `y` are also problematic, though slightly less so. The biggest issue I have is that they're similar in appearance. `abc` is much better, because they're clearly different from each other, if you're married to single-letter values.

`i` and `j` are usually indicative an index for something, and indicating what you're indexing makes the code clearer to read and easier to maintain. `idxUsers`, `idxPosts`, for example. `x` and `y` are a bit trickier because they're very frequently the canonical positional co-ordinates, and renaming them can actually make it _harder_ to read, so (like all things in naming) is a real judgment call, but frequently can be replaced with `col` and `row`, which, to me reads _much_ clearer, especially when using row-major access pattern: `array[row][col]`.

Often "i" and "j" would appear when the code is the implementation of some math formula which would idiomatically use "i" and "j" when written 'properly' on paper or LaTeX.

Sounds like your colleagues are cargo-culting rather than arguing from experience or knowledge.

My standard solution for this is to name the loop counter for the things being counted. So your example would be:

    for (horse=0;horse<n_horses;horse++) {
    }

    for (horse in horses) {
    }

or equivalent depending on whatever language you use.

Kudos to Code Complete, specially l the tips regarding "safe" C code and parameter validation, based on Microsoft learnings in failure to do so.

One anecdote I remember from the book, is how for a while Excel allowed for dual colored cells based on a parsing error due to trying to be too clever.

I like this, I adopted this intuitively over time. But man do I loathe single variable names. My brain starts to shut down when there’s more than one of those anywhere. I write a lot of GLSL and that crowd loves working in wingings.

The point is to always name your variables / methods / classes as exactly what they do (not how they do it, but what they achieve). If this name looks ridiculous, like `doXAndYAndZAndSideEffect`, then your code is likely poorly factored. I've found it works very well for helping to find good separation of concerns.

I think I get frustrated here because "Clean Code" is talking about a very specific style of coding popularized by Robert Martin in the book with the same name. It is not a synonym for Good Code.

Longer variable names are certainly a facet of Clean Code. It's in chapter 2, and Chapter 1 is an introduction.

That said, I strongly suggest Arlo Belshee's series https://www.digdeeproots.com/articles/naming-as-a-process/ - this gets to the heart of how to have both descriptive and not-sentence-long.

Naming things is hard. Often when names are very long, they could be shortened, because they are in a function, which already narrows down the context and makes a shorter name still understandable. Very long names can also sometimes be a code smell, if they are relating to a lot of global state, which is not narrowed down in context by where it is defined.

Sometimes however, it is really difficult to come up with a shorter name. I think it is definitely a skill, that takes practice and never is really perfected.

I think the names in the article were pretty decent, but here is good article about common errors that result in unnecessarily long names:

https://journal.stuffwithstuff.com/2016/06/16/long-names-are...

Reply on news.ycombinator.com