8 ms·

I'd questing even saving any time, let alone 5%. I guess the supposed time would be typing and thinking of a good name? Maybe you save a bit of time during ver

I'd questing even saving any time, let alone 5%. I guess the supposed time would be typing and thinking of a good name? Maybe you save a bit of time during very initial prototyping, when you're just trying to create the exact algorithm for something (eg working with a dozen or so lines of code). As soon as it's actually used, even if in a "proof-of-concept" prototype, you'll easily spend double that time on cognitive overhead (eg, the next day/week, trying to remember what that variable is) or just in typing out comments. If other people are ever looking at or using the code, it's easily 10x the work you're creating. Another way of saying this: once your code exists for more than a couple hours, it should have good (not necessarily perfect) variable/function/token names. I agree on the ide vs text editor comment, and add: another nice thing about using a good ide is you can rename the declaration and let the ide update everything else.

samatman 7y ago
Agreed, this is just one of those moments where I learn that other people have a very different workflow from mine. I can't write an algorithm without coming up with decently descriptive names for the components. Of course, sometimes I come up with better ones later, but the entire idea of using placeholders is deeply foreign to how I think. Which isn't to say I don't use single-letter variables, `d` is a perfectly cromulent way to spell delta although `Δ` is better if it's allowed. It's uncommon, and when I do, they're no more likely to change than any other name.
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.

samatman 7y ago

Agreed, this is just one of those moments where I learn that other people have a very different workflow from mine. I can't write an algorithm without coming up with decently descriptive names for the components. Of course, sometimes I come up with better ones later, but the entire idea of using placeholders is deeply foreign to how I think. Which isn't to say I don't use single-letter variables, `d` is a perfectly cromulent way to spell delta although `Δ` is better if it's allowed. It's uncommon, and when I do, they're no more likely to change than any other name.

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.