5 ms·

Do we even parse all the variable name when reading code? I know I do at least sometimes, because I know how often I am renaming in anger, but a lot of times I

by usrusr 7y ago

Do we even parse all the variable name when reading code? I know I do at least sometimes, because I know how often I am renaming in anger, but a lot of times I just see the IDE default of (in java syntax) "Foo foo; Bar bar;" and I'm perfectly happy with it. The tokens have a certain length that helps keeping them apart visually and they are not outright deceptive. Real life class names can be long, but the IDE even helps chopping them down reasonably. Good enough naming can be tremendously easy, sloppy even, once you've learned which names don't pass that bar. Where naming does get hard, and where inconsistencies become painful, is when you have too many things that could have the same name.

gregmac 7y ago
The whole point of naming things nicely is to reduce cognitive load. I don't see any issue with `Foo foo` because in the right context it serves that purpose, but by contrast, `Foo foo; Foo foo2` is basically always awful and is a case where it should be something more descriptive, like `Foo old; Foo new`. In the wrong context `Foo foo` can be confusing though -- at best this leads to someone reading the code just spending more time, and at worst, it leads to someone modifying the code adding bugs. Just calling it something like `Foo currentUserFoo` is often enough to avoid this, and really doesn't take more than a couple extra seconds to write.
- loopz 7y ago
  Think of programming code as communication to your future self and colleagues. Then we need less rules mindset, and more empathic one.
  - notduncansmith 7y ago
    This is probably the best advice I’ve seen in this thread. Honestly, the pain of prototyping on bad code makes me try to write good code as early as I can in the process, to help my future self refine the code later (be it 10 minutes or 10 months “later”). I usually have a gut reaction to whether I like or dislike code, then try to identify why I have that feeling, and it’s usually based on how accurately code represents its own intent and purpose. When code does something besides what its name implies, I feel a tiny bit betrayed, and (if I have the time) I try to help it communicate better. This can be a module, a function, or even a variable.

by usrusr 7y ago

gregmac 7y ago

The whole point of naming things nicely is to reduce cognitive load. I don't see any issue with `Foo foo` because in the right context it serves that purpose, but by contrast, `Foo foo; Foo foo2` is basically always awful and is a case where it should be something more descriptive, like `Foo old; Foo new`. In the wrong context `Foo foo` can be confusing though -- at best this leads to someone reading the code just spending more time, and at worst, it leads to someone modifying the code adding bugs. Just calling it something like `Foo currentUserFoo` is often enough to avoid this, and really doesn't take more than a couple extra seconds to write.

loopz 7y ago
Think of programming code as communication to your future self and colleagues. Then we need less rules mindset, and more empathic one.
- notduncansmith 7y ago
  This is probably the best advice I’ve seen in this thread. Honestly, the pain of prototyping on bad code makes me try to write good code as early as I can in the process, to help my future self refine the code later (be it 10 minutes or 10 months “later”). I usually have a gut reaction to whether I like or dislike code, then try to identify why I have that feeling, and it’s usually based on how accurately code represents its own intent and purpose. When code does something besides what its name implies, I feel a tiny bit betrayed, and (if I have the time) I try to help it communicate better. This can be a module, a function, or even a variable.