It never hurts to read through your code one more time. But how you read through it is fairly important too. I have gotten used to the mentality of "make sure it works then optimize later", which is fairly ok for the most part. But sometimes, I will write a piece of code that works, tell myself I will optimize it later, then start working on something else entirely and I forget to optimize my code. Which would leave me having to try and explain why I did not do a rather obvious optimization.
So for the past couple weeks, I have decided to commit my code, but not push until I have re-checked my work. How does this look like? Well, say I am implementing feature A today. I will write the tests, and try to make them pass. Once the tests are passing, I will commit and walk away from my code( By walk away I mean literally not even look at anything remotely associated with the codebase.) I'll watch a youtube video or go outside for a well deserved break. The goal here is to make sure that when you go back to your code, you have a fresh pair of eyes on the issue. A hack I was taught by @jeremyf , is to just walk through a door way. No idea why it works, but it does.
Coming back I will ask myself, "What does this line/block do? Is it critical?" for each line or block of code I had previously written. This helps me remove those pesky bits of dead code or random logs. Similarly, I will go through the tests and start thinking about the random edge cases. If it is a UI issue, I will ask myself, "is this the best look for the system?" "Can it perhaps be made to look better than this?", and other questions pertaining to UX.
Making sure your code works correctly seems like a pretty obvious thing to do, but it's always good to remind yourself the goals that you are striving for in your code. Makes for much better and well thought out code.
Top comments (1)