Why Naming Variables Can Distinguish a Good Programmer from a Bad One

2 points by chenster 7 months ago | 7 comments
  • toss1 7 months ago
    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?

    • JohnFen 7 months ago
      > 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.

    • brudgers 7 months ago
      After 25 minutes

      [Some thoughts]

      + If you believe you understand something complex after twenty-five minutes, your belief is probably unfounded.

      + A naming system can make sense to some people and no sense at all to others...for example, naming in Norwegian or applying an established naming convention.

      + Externally established budgets and deadlines and project briefs are what separates engineering from hobbies. In so far as programming is engineering, these establish what-is-good.

      • genezeta 7 months ago
        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.

        • chenster 7 months ago
          Good catch. The total discount should be divided by 100. I missed that. :) Fixed now.
          • genezeta 7 months ago
            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)