I read code for the first time yesterday. Well, not exactly my first. I've contributed a bit to open source for the yearly hacktoberfest challenge. I also read code snippets whenever I need to solve a problem. This time, though, was the first time reading someone else's code to solve a specific problem - somehow this makes less sense, but well, let's continue.
How did this happen?
Yesterday, a friend of mine had a problem with a hamburger menu. A bug in her code made the hamburger menu disappear when clicked. I wanted to help because I felt this was one way to practice reading someone else's code. It was time to get to work.
The Bug Fixing Process
On to the repo. The first thing I had to do was fork the repo and clone it to my local machine. The initial plan was to use GitHub codespaces. I'd make the necessary changes in the browser, but it's a little buggy and wouldn't load up since it's still in beta. Git bash to the rescue and I cloned it. After that, I launched Sublime Text and off to debugging.
The fact of the matter is: It was a bit daunting. Yes, this was unchartered territory and I honestly didn't want to mess things up. I didn't want to mess things up but I knew there was a nasty bug to fix. The only way, as the axiom states, is to move forward.
Problem Solving Approach
The first thing was to deploy the project on my local machine. The devtools is one of the most useful tools, ever, no cap. It makes my life so much easier when it comes to debugging CSS. Kudos to every dev responsible for maintaining the devtools for every browser out there. I also had to open git Bash to track and commit the incremental changes I would be making along the way.
I looked through the HTML file and saw that an icon kit was being used - nice. I would have created the hamburger but why reinvent the wheel - that's something I need to think about on my next project. The markup looked really okay to me, oh but one thing, there were ID attributes used liberally. I was quite shocked because I never use IDs at all. I feel the specificity issues that could result from them is not something I would want to deal with. Apart from that, everything else seemed okay.
Now on to the CSS and JS
The first thing I had to do was track down the offending selectors. I think this is where I appreciate classnames that are easy to remember, semantic classnames I might say. After tracking down the offending selectors, and then try to add another rule. This approach works for hand in hand with the devtools. After adding a new CSS rule, I'd then refresh the page to see what changed, check the devtools and add different CSS rules. If anything worked right on the devtools, I'd then copy that rule and paste it in my CSS.
The problem was mainly from the JS event Listeners and the corresponding classnames that were being toggled. The order of the statements that are supposed to execute when the hamburger menu was clicked was disordered. I struggled with it a lot, partly because I kept trying different solutions, trying to see if one thing would fix it.
Note to future self: DO NOT DO THIS.
The better way is to read the code line by line and try to find the bug. If that doesn't work, comment it out and refactor. Refactoring the code saved me a ton of time. I fixed the bugs in the JS and CSS files and Bob's your uncle, everything worked. WOW! that was some hard work.
The most exciting part about this was using the devtools as well as git to add and then commit changes. I'd say: it was a refreshing experience and I look forward to doing more of this soon.
Thanks for reading.
I hope you have a nice day,
Kenny.