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 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.
Yep. A lot of my refactoring is "why the hell did I name it that?"
It's not difficult since most IDE's and even VS Code implement a "Rename symbol" functionality that makes refactoring a snap.
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
clearBlanksthat does what it says, it clears blank squares in a contiguous region when you click on a blank. There's a function defined insideclearBlanksthat I had namedclearthat 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
clearBlanksfunction that actually does clear them. Soclearwas the wrong name for it.I renamed the recursive function
getAdjacentSquaresbecause that's what it actually does, it gets the squares adjacent to the ones passed in. It should probably be further renamedgetAdjacentBlankSquaresorgetSquaresToBeClearedBut 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,
getAdjacentSquareshad nothing to do with actually clearing the squares.