1. 11
  1. 11

    I work for an ecommerce company, and I can tell you terminology matters, when business process are complicated.

    Simple example : “price”. Possibilities :

    • The price we bought an item ?
    • The price we sell it ?
    • The manufacturer’s suggested retail price ?
    • The price we sell it, after promotions ?
    • The price a customer may buy it with some vouchers ?
    • The price a customer may buy it with the loyalty program’s special day activated ?

    Using actual business wording allows to evade so many bugs, it really damages the code quality to stick with what OP calls industry-standards name in the codebase, if the business have something that is both easier and more precise to use.

    1. 6

      Oh god this. Had that delightful experience for “cost”:

      • Cost to us the market maker?
      • Cost to the producer?
      • Cost to the buyer?
      • Actual cost, or the estimated cost, for any of the above?
      • Base cost or cost plus various markups, for any of the above?

      It was so bad.

      1. 2

        Most code bases I’ve seen in Germany are still 100% English, this usually makes total sense.

        A former employer of mine was writing software for a bank and it was a bit of an odd mixture of getX and calculateY with X and Y and so on being technical financial math terms, all in German - and it actually was the best possible solution. No one (not even the domain experts) would have known how to translate the stuff to English because it’s mostly terms no one has ever heard or uses in their daily life. The alternative would have been to also not use the “getX/setX/calculateX/doX” verbs, but it in the name of common practices that was decided against.