3 ms·

Regarding variable names strongly consider keeping the first variable name which comes to your head. It is simple, straightforward. I often see overly elaborat

Regarding variable names strongly consider keeping the first variable name which comes to your head. It is simple, straightforward. I often see overly elaborate variable names where I know the author took their time to come up with it ending up with an abstract variable name which makes far less sense. Another tip for novice programmers: don't do leet code or watch random videos which talk about loops and variable naming. Instead watch or read about people building things. Imo we tend to prescribe these things too late in people's journeys. It would make far more sense for someone to watch a tsoding video on building something with Haskell rather than watch beginner Haskell tutorials.

cratermoon 3y ago
> strongly consider keeping the first variable name which comes to your head Apparently the first and only thing that came to the minds of the developers on the last project I consulted on was "data", so we had variables named 'datablob', 'dataProvider', '<thing>Data'. So please, newbs, don't use the first thing the comes to mind, if your understanding of what you're building is limited.
- pavel_lishin 3y ago
  A former coworker loved using `hold` as a "temporary" variable, that would inevitably be passed around everywhere. Along with its cousins, `hold1` and `holdA`.
tmtvl 3y ago
> consider keeping the first variable name which comes to your head. It is simple, straightforward. That strongly differs from person to person, I am the kind of guy who immediately comes up with names like glass-hardness-at-temperature-in-centigrade-before-tempering before refactoring it to untempered-glass-hardness-at-centigrade. > Instead watch or read about people building things. Definitely watch/read those too, but there's nothing wrong with watching e.g. the MIT OpenCourseWare Structure and Interpretation of Computer Programs (SICP) videos.
lainga 3y ago
> the first variable name which comes to your head. I do this. I do it, but I will say it's not for everyone, including me. There have been a lot of "jimmy" and "pibbo" over the years. Keep the first name that doesn't embarrass you...
cableshaft 3y ago
The variable naming can be good advice once you get used to programming and have some experience at it, but I'm not sure I'd agree it's best for novice programmers. I've seen even seasoned programmers with garbage variable names, which I'm sure were their first instinct, that tell you nothing. One thing I see a lot of in particular that I wish I didn't are variables that are overly abbreviated to save the programmer some typing (which there is autocomplete, so typing shouldn't be a big deal), to the point where you don't know what it represents without sitting there and decoding the code. To make up an example that's similar to what I saw in a code review a month ago (I don't remember the exact example), what does "tpTr" stand for? Turns out it's the target position for the transition out animation, but I have no idea without chasing that variable around and seeing how it's manipulated. Just say what it does. Or you might see a lot of generic variables like 'data' or 'obj'. Like what type of data or object? Yeah for a tiny function you can probably get away with something like that, but anything larger and you should have something on there to help specify it a bit more. And yet I see this in code I review as well.
kypro 3y ago
> Regarding variable names strongly consider keeping the first variable name which comes to your head. It is simple, straightforward. Strongly disagree with this. Variable naming is so important if you want to write code others can understand. The first name I come up with tends to be overly verbose/specific or too general. Variables named "count" are a good example of a name that's too general requiring a developer new to the code to ask, what is being counted? While "userUniqueVisitCount" might be too verbose when given the context perhaps, "visitCount" would be fine. Just little things like that can really help a developer understand what's going on quickly. Code structure is super important too though... If you're making too many abstractions it generally forces your variables and methods to be abstract and meaningless too. Your names should hint at this when there is a problem. If you find you need to use extremely verbose names to explain what a variable or method is doing, you likely have something structurally wrong with your code.
- ilrwbwrkhv 3y ago
  I have gone back and forth on this many times in my career, but the word which comes to your head in the second or third attempt is usually the max depth you should search for. Chances are when you think of this again, the same word will come to your head making it easy to grep.
- mid-kid 3y ago
  Just "visits", unless you use that name for something else. I find code that relies excessively on catch-all terms to be very tacky.
- whstl 3y ago
  These things depend heavily on context. "count" is better and less redundant than "visitCount" when it is a field or method of a "Visits" or "VisitList" class, for example, and nothing else is being counted. Or as a variable: "count" is also good enough in a small function with a few lines, that only concerns itself with a single type of item being counted. If there are multiple things being counted in the same context, by all means specify them. I get the good intention, but in the end those guidelines get in the way of good code more than they really help. The "no methods bigger than N lines" for example (popular with some linters) cause more damage than improvements.
heisenbit 3y ago
A lot depends on the scope of the variable but if one is using a language with strong typing I'm leaning towards decide asap, got for a short one and refactor after. Human short term memory is limited and getting the logic right while also getting the naming right is often pushing it too far.
Shorel 3y ago
Naming is still a hard problem :)

cratermoon 3y ago

> strongly consider keeping the first variable name which comes to your head Apparently the first and only thing that came to the minds of the developers on the last project I consulted on was "data", so we had variables named 'datablob', 'dataProvider', '<thing>Data'. So please, newbs, don't use the first thing the comes to mind, if your understanding of what you're building is limited.

pavel_lishin 3y ago
A former coworker loved using `hold` as a "temporary" variable, that would inevitably be passed around everywhere. Along with its cousins, `hold1` and `holdA`.

tmtvl 3y ago

> consider keeping the first variable name which comes to your head. It is simple, straightforward. That strongly differs from person to person, I am the kind of guy who immediately comes up with names like glass-hardness-at-temperature-in-centigrade-before-tempering before refactoring it to untempered-glass-hardness-at-centigrade. > Instead watch or read about people building things. Definitely watch/read those too, but there's nothing wrong with watching e.g. the MIT OpenCourseWare Structure and Interpretation of Computer Programs (SICP) videos.

lainga 3y ago

> the first variable name which comes to your head. I do this. I do it, but I will say it's not for everyone, including me. There have been a lot of "jimmy" and "pibbo" over the years. Keep the first name that doesn't embarrass you...

cableshaft 3y ago

The variable naming can be good advice once you get used to programming and have some experience at it, but I'm not sure I'd agree it's best for novice programmers. I've seen even seasoned programmers with garbage variable names, which I'm sure were their first instinct, that tell you nothing. One thing I see a lot of in particular that I wish I didn't are variables that are overly abbreviated to save the programmer some typing (which there is autocomplete, so typing shouldn't be a big deal), to the point where you don't know what it represents without sitting there and decoding the code. To make up an example that's similar to what I saw in a code review a month ago (I don't remember the exact example), what does "tpTr" stand for? Turns out it's the target position for the transition out animation, but I have no idea without chasing that variable around and seeing how it's manipulated. Just say what it does. Or you might see a lot of generic variables like 'data' or 'obj'. Like what type of data or object? Yeah for a tiny function you can probably get away with something like that, but anything larger and you should have something on there to help specify it a bit more. And yet I see this in code I review as well.

kypro 3y ago

> Regarding variable names strongly consider keeping the first variable name which comes to your head. It is simple, straightforward. Strongly disagree with this. Variable naming is so important if you want to write code others can understand. The first name I come up with tends to be overly verbose/specific or too general. Variables named "count" are a good example of a name that's too general requiring a developer new to the code to ask, what is being counted? While "userUniqueVisitCount" might be too verbose when given the context perhaps, "visitCount" would be fine. Just little things like that can really help a developer understand what's going on quickly. Code structure is super important too though... If you're making too many abstractions it generally forces your variables and methods to be abstract and meaningless too. Your names should hint at this when there is a problem. If you find you need to use extremely verbose names to explain what a variable or method is doing, you likely have something structurally wrong with your code.

ilrwbwrkhv 3y ago
I have gone back and forth on this many times in my career, but the word which comes to your head in the second or third attempt is usually the max depth you should search for. Chances are when you think of this again, the same word will come to your head making it easy to grep.
mid-kid 3y ago
Just "visits", unless you use that name for something else. I find code that relies excessively on catch-all terms to be very tacky.
whstl 3y ago
These things depend heavily on context. "count" is better and less redundant than "visitCount" when it is a field or method of a "Visits" or "VisitList" class, for example, and nothing else is being counted. Or as a variable: "count" is also good enough in a small function with a few lines, that only concerns itself with a single type of item being counted. If there are multiple things being counted in the same context, by all means specify them. I get the good intention, but in the end those guidelines get in the way of good code more than they really help. The "no methods bigger than N lines" for example (popular with some linters) cause more damage than improvements.

heisenbit 3y ago

A lot depends on the scope of the variable but if one is using a language with strong typing I'm leaning towards decide asap, got for a short one and refactor after. Human short term memory is limited and getting the logic right while also getting the naming right is often pushing it too far.

Shorel 3y ago

Naming is still a hard problem :)