Naming things

[Morningstar88]

Now naming. In a small program it's not hard. But let's actually look at what a name is. It is how the world knows you. It is how you interface with the world. What functions need to be called, the names of these functions, their parameters, the classes you need to make, the APIs you need to design. All of that technically can be considered a part of naming.

Now here's the thing. When you start coding the hardest thing is figuring out the logic. But when you're a senior developer leading a large code base your problem is not those details. It is making the code of everyone work together. To do that in a scalable way that is not painful to everyone you have to make sure you're interfaces are correct. So a large software project is about naming. To take it further if you can give something a good name it means you already know what the code needs to do. I will write this function and it will call these five functions means you've broken the large problem into tractible pieces. You can't name without knowing the logic. Also if you want your code to be easy to understand, which it has to be for any large software because it will live for years, the names must make sense. And so that is the joke behind naming. That the hardest problem is creating interfaces, making your code easy to understand, and understanding how best to break down your problem.

[Morningstar88]

https://www.reddit.com/r/learnprogramming/comments/w5tpjk/why_do_people_say_the_hardest_part_about/

[Morningstar88]

This is a bit of an extreme example, but good naming is the difference between:

for x in y:

z = function1(x)

and

for row in table:

rowSum = sum(row)

[Morningstar88]

Logic and naming can also feed into each other. Many times I have struggled to name a function, only to realize that the uncertainty stemmed from an unwieldy function which was trying to do too much and would be better split into smaller parts.