loading...

re: 4 practices for better code VIEW POST

FULL DISCUSSION
 

Hi Klaudia,

Great post. But I do want to address one point:

"Basically, if you see your function does something that can be potentially extracted and put into a separate function, you should do it."

While in general I agree, I do want to make a counter-point, and one I think far too few developers pay attention to. Serendipitously, it aligns with another point you made:

"Be careful what you name your variables and functions, classes, files, basically anything and everything."

The counter-point is this: If you subdivide a function into two or more functions you now need to come up with good names for the additional functions, and that can often be difficult.

After 25+ years programming I've come to believe that the best names:

  1. Follow objective naming conventions that anyone who follows correctly would use the same names,

  2. That are repeatable by which I mean that that I or someone else would use the same name in the future if we needed to do the same thing again.

If you follow those two rules in your team's codebase you will end up with much more cohesive code. But that also argues for restraint in creating new symbol names, unless you really need to, and ideally when you have an objective set of rules that apply for the naming.

#jmtcw

-Mike

code of conduct - report abuse