I didn't put it in the original, but I think a lot of the problem is that we give things names before we go as far as working out what they do. It's usually days or even weeks after I've written something that the right name becomes apparent - usually when I'm trying to talk about the code with someone else.
Yes - refactoring tools are your friend in this! 💯
I am a software development engineer in test for Infosys. My job is officially to write automated tests in Selenium Webdriver. I'm also a web developer as a hobbyest
I have a good example for this. I wrote a minesweeper game. I wrote a function called clearBlanks that does what it says, it clears blank squares in a contiguous region when you click on a blank. There's a function defined inside clearBlanks that I had named clear that was recursive. What it does is create an array of the squares adjacent to the ones passed in that need to be cleared.
It does not actually clear them. They get cleared after the recursion is complete and the array is returned back to the clearBlanks function that actually does clear them. So clear was the wrong name for it.
I renamed the recursive function getAdjacentSquares because that's what it actually does, it gets the squares adjacent to the ones passed in. It should probably be further renamed getAdjacentBlankSquares or getSquaresToBeCleared But then we start going down a rabbit hole of finding the perfect name.
The problem in naming is that often as we develop, what our functions do changes from what we initially intended. In this particular example, I rewrote this function (and crashed Chrome with stack overflow errors) several dozen times getting it to work and by the time it did work, getAdjacentSquares had nothing to do with actually clearing the squares.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I didn't put it in the original, but I think a lot of the problem is that we give things names before we go as far as working out what they do. It's usually days or even weeks after I've written something that the right name becomes apparent - usually when I'm trying to talk about the code with someone else.
Yes - refactoring tools are your friend in this! 💯
I have a good example for this. I wrote a minesweeper game. I wrote a function called
clearBlanks
that does what it says, it clears blank squares in a contiguous region when you click on a blank. There's a function defined insideclearBlanks
that I had namedclear
that was recursive. What it does is create an array of the squares adjacent to the ones passed in that need to be cleared.It does not actually clear them. They get cleared after the recursion is complete and the array is returned back to the
clearBlanks
function that actually does clear them. Soclear
was the wrong name for it.I renamed the recursive function
getAdjacentSquares
because that's what it actually does, it gets the squares adjacent to the ones passed in. It should probably be further renamedgetAdjacentBlankSquares
orgetSquaresToBeCleared
But then we start going down a rabbit hole of finding the perfect name.The problem in naming is that often as we develop, what our functions do changes from what we initially intended. In this particular example, I rewrote this function (and crashed Chrome with stack overflow errors) several dozen times getting it to work and by the time it did work,
getAdjacentSquares
had nothing to do with actually clearing the squares.