For our blog post this week, we were asked to find and read a couple of articles on code smells and clean code. I chose one based on code smells and how to refactor appropriately, and the other article was a summary of action items in the book “Clean Code,” by Robert C. Martin.
Firstly, I will say that there is not a lot that I didn’t already know about maintaining good coding hygiene. I think most of us have had enough experience with code now that we can identify good code from bad code. It is simply a case of applying it in our own works. There are several good rules that I already follow, and I would like to start with those.
No one writes a perfect essay on the first try. The most important thing is to get all of your ideas, thoughts, and points written down. You can’t edit what you don’t have! Applying this to coding, I want to encourage us to just start. Scratch out your algorithm on paper and really think through how it works. Run through all of the possible solutions and branches, then test it out. Once you have a good idea of your goal, it’s easy to put it into practice!
Don’t perfect every sentence as you go. As you transfer the algorithm to code, it is very tempting to refactor as you go. I encourage you to just keep going and get it all written out. Don’t worry about using the most efficient kinds of code, just stick with what works. A ternary operation may be more efficient, but if you’ve got skills writing if/else statements, then use that. Just get it working. Then, feel free to test it! If the code does exactly what you want, then, great! You’ve got your first working version. Now, you may gently go through your code and refactor it. Go replace that ternary operation 😉
No one edits their paper once and perfects it. Refactoring is a process, or as some might like to call it, a journey. There is no “right way” to write your code. There are definitely good and bad coding practices and standards, just like there are rules to the structure of an essay. It’s important to stick to those. Follow those as you refactor. Next, I’d encourage you to refactor your code one chunk at a time and then test it. If it still works appropriately, then you are doing great!
Practice doesn’t make for perfect essays the first time, but it does help us to improve next time. Don’t ever expect yourself to follow all of the rules and regulations the first time you write out your code. Even seasoned architects and engineers have to refactor their code. However, don’t lose heart! The practice that you get while refactoring will lead to breakthroughs. Eventually, you’ll find yourself in a place where as you are coding, you say to yourself, “I remember refactoring a bit of code just like this. I’ll use that now!” and suddenly, your code is already one step closer in the refactoring process.
There were a few tips and tricks from the articles that I read that I would love to share with you. I am going to strive to be following these as I code and refactor, myself.
Firstly, I want to implement more testing. If I force myself to sit down and come up with all of the edge cases and possibilities to test, I can really give my code the run through. However, I am often in such a hurry to improve my code that I forget to test all of my cases. I make sure that the bare minimum works and then I move on. I really want to get better at creating testing suites when I implement my algorithm. I believe that if we understand what we want our code to do and write tests to confirm that it is doing that, we will write better code as a result. Plus, as we refactor, it can save us time by not having to enter every case by hand.
The other skill that I want to improve is my commenting. I tend to over-comment my code. If I have to explain what every single line is doing, then my variables and functions are not descriptive enough and I’m not allowing my code to speak for itself. Rather, I need to improve my function headers and explain the purpose of each function up there. One of the articles mentioned that we should include a warning of consequences in our comments and I find that to be very valuable. I am also going to begin implementing that into my code, as well.
There are also a few things that I struggle with doing and am going to work towards eliminating out of my repertoire of bad habits.
The first of these is not cleaning up my comments. It can be a good practice to comment out code while you refactor and test. You need to preserve a working function! For bigger, expansive projects, this is where version control is an excellent thing. However, for those writing smaller projects, commenting out is helpful! Just don’t be like me and forget to come back and delete it.
Repeat after me: I don’t need to hoard my code; I’m not going to need it again.
Another brutal habit that I want to shake is having my functions do too much. Functions, with perhaps the exception of the main line, should only do one thing. They should have one purpose. While refactoring, we may even find a way to modularize the code so that the function can be used for many purposes. We might not catch that at all if our function bites off more than it should chew!
With that, I hope that I have inspired you to come at your next project with a refreshed, encouraged mindset. Don’t try to follow all of the rules at once, you’ll disappoint yourself — we’re human. Don’t try to write it perfectly on the first coding session. However, always do your best. Don’t be a lazy coder. Remember that some progress is better than no progress at all.
Finally, be proud of your code. It’s your creation and it’s beautiful.
Now go write your name at the top of your code for me 😉
The two articles referenced are:
• Summary of ‘Clean code’ by Robert C. Martin
• Understanding code smells and how refactoring can help
Leave a Reply