There has been a few times I look back at my old repos on github and really understand the constant reminders from professors that clean code is important.
https://medium.com/gojekengineering/the-basics-of-writing-clean-code-39ed770b626d
Here’s an article I read about clean code basics. One that really sticks out that I still sometimes trip up on is
“Variables should be declared as close to their usage as possible.“
For this blog I went back and looked at some of my Algorithms class assignments. I didn’t include the directions, I didn’t include any comments, I didn’t name a couple variables correctly. I have zero idea what this is. I had to google TSP to find out it is a Travelling Salesmen Problem.
I then go on to use V and G multiple times in the code. This is something I should most likely avoid.
https://linearb.io/blog/what-is-a-code-smell
I linked above about code smells and what to do. What I want to follow from this is this…
“Ultimately, you want to decide whether it can and should be fixed or whether its smelliness is justified.”
For something like the variable names above that’s easy to catch and understand that you need to change it. But for something bigger, that’s where you have to stop and see if it should be something to be fixed. I have a full stack web app that I created this past summer, I have some endpoints that make a ton of SQL queries and it’s honestly a nested mess. Luckily it’s a personal project and not a part of a job. But these kind of habits can leak over to the professional world if I let them. So this is some technical debt that I need to go over and fix before I keep adding on to it.
This is a post for my /makepicks route that has a user make a pick, it goes through a bunch of checks to make sure that pick is allowed. As you can see it starts at line 222 and ends at 388. That. is. way. too. long. I should have functions built in that get called and not make this so bloated. Something I really need to take care of.
Leave a Reply