> If you struggle to name something, it’s likely because you don’t fully understand it yet.
Nail struck squarely on the head. This is why naming things is is hard. The temptation and sometimes need to barrel through without real understanding in very strong.
My practice is to notice when I'm starting to struggle with naming things and take that as a signal that I don't quite have what I'm doing clear in my mind. I need to step back and take a few moments to reflect. It's saved me from future trouble more often than I can count.
It's not my intention to discard the whole article for this problem but...
calculateTotalPrice(100, [5, 10, 15]);
And so, a base price of 100 and applying discounts of 5, 10, and 15, produces a total price of... 3000. Odd kind of discount, innit?
I mean, either this is a bad example not well thought out, or the original function is doing something completely different and the supposedly good naming is actually a very bad one since it appears to make sense but doesn't. In either case not good.
- In one case you write (p/100) and in the other (totalDiscount/100). It wouldn't matter because the end result is the same mathematically, but the apparent meaning is different. But anyway...
- Now the calculated total price is 30, but it should be 70. totalPrice = basePrice * (1 - totalDiscount/100)
I hadn't thought of it in terms of evaluating programmers, but I can say the best definitely spend real effort on good naming conventions for their projects.
I was once at a conference where Bjarne Stroustrup was speaking, and after the talk he was answering questions for a handful of us from the crowd. I asked about something that had been bugging me for a while — that I was finding myself spending what seems like a lot of time developing naming schemes for projects, and was this a good use of time? His answer was an immediate "yes, this is something that is actually quite important". Since then, I stopped worrying myself about it, and enjoyed the times I had to look into existing code and could figure out something quickly, because I'd put in the effort up front.
In that context, the main insight of the article definitely makes sense. Not only does the coder being evaluated use good naming in one instance, but have they invested the time and effort to wrestle with the problems and developing useful ways of thinking about it?
> If you struggle to name something, it’s likely because you don’t fully understand it yet.
Nail struck squarely on the head. This is why naming things is is hard. The temptation and sometimes need to barrel through without real understanding in very strong.
My practice is to notice when I'm starting to struggle with naming things and take that as a signal that I don't quite have what I'm doing clear in my mind. I need to step back and take a few moments to reflect. It's saved me from future trouble more often than I can count.
alternative thinking - if you need to name something to understand it that is a smell…
https://degoes.net/articles/insufficiently-polymorphic
It's not my intention to discard the whole article for this problem but...
And so, a base price of 100 and applying discounts of 5, 10, and 15, produces a total price of... 3000. Odd kind of discount, innit?I mean, either this is a bad example not well thought out, or the original function is doing something completely different and the supposedly good naming is actually a very bad one since it appears to make sense but doesn't. In either case not good.
Good catch. The total discount should be divided by 100. I missed that. :) Fixed now.
Slow down :)
- In one case you write (p/100) and in the other (totalDiscount/100). It wouldn't matter because the end result is the same mathematically, but the apparent meaning is different. But anyway...
- Now the calculated total price is 30, but it should be 70. totalPrice = basePrice * (1 - totalDiscount/100)
I hadn't thought of it in terms of evaluating programmers, but I can say the best definitely spend real effort on good naming conventions for their projects.
I was once at a conference where Bjarne Stroustrup was speaking, and after the talk he was answering questions for a handful of us from the crowd. I asked about something that had been bugging me for a while — that I was finding myself spending what seems like a lot of time developing naming schemes for projects, and was this a good use of time? His answer was an immediate "yes, this is something that is actually quite important". Since then, I stopped worrying myself about it, and enjoyed the times I had to look into existing code and could figure out something quickly, because I'd put in the effort up front.
In that context, the main insight of the article definitely makes sense. Not only does the coder being evaluated use good naming in one instance, but have they invested the time and effort to wrestle with the problems and developing useful ways of thinking about it?