{"id":29,"date":"2023-01-27T02:34:54","date_gmt":"2023-01-27T02:34:54","guid":{"rendered":"https:\/\/blogs.oregonstate.edu\/patss\/?p=29"},"modified":"2023-01-27T02:34:54","modified_gmt":"2023-01-27T02:34:54","slug":"clean-code-code-smells","status":"publish","type":"post","link":"https:\/\/blogs.oregonstate.edu\/patss\/2023\/01\/27\/clean-code-code-smells\/","title":{"rendered":"Clean Code & Code Smells"},"content":{"rendered":"\n

Clean Code<\/h3>\n\n\n\n

\u201cClean code always looks like it was written by someone who cares.\u201d\u00a0<\/p>Robert C. Martin,\u00a0<\/strong>Clean Code: A Handbook of Agile Software Craftsmanship<\/a><\/cite><\/blockquote><\/figure>\n\n\n\n

Have you ever looked at your code after a while? Or have you ever looked at someone’s code and thought you could have done it better and more efficiently? Or did you ever received a feedback on your code? If answer to any of this questions is ‘yes’, then you know that writing good and clean code is not an easy task, and requires a lot of practice.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

As a part of this assignment, I read an article on freeCodeCamp “Clean Code Explained – A practical Introduction to Clean Coding for Beginners.<\/a>” My first thought was that I probably won’t learn much from the article since it has ‘beginners’ in its title. Reading the beginning of the article was confirming my beliefs – I would never use a letter for a variable name! How dare you are even accusing me of such thing!? This is literally the first rule of the clean code – use a descriptive name for variables:<\/p>\n\n\n\n

int w = 12; \/\/ bad\nint width = 12; \/\/ good<\/code><\/pre>\n\n\n\n
I believe meaningful and defining names of variables are a necessity for a clean code. Misleading names, noise words (the, info, data, variable, object, etc.), and unpronounceable names will make your code harder to read and understand. At the end of the day, code is meant to be read by humans. Just like Martin Flower said, “Any fool can write\u00a0<\/strong>code that a computer can understand. Good programmers write code that humans can understand.”\u00a0<\/p>\n\n\n\n
Examples of “horrible” variable names:<\/h5>\n\n\n\n
Disinformation:\npeopleList = []; \/\/ bad\npeople = [] \/\/ good\n\nUnpronounceable Names:\n\/\/ Bad\nconst yyyy = new Date(\"2021-03-25\");\nyyyy.getFullYear();\n\/\/ Good\nconst year = new Date();\nyear.getFullYear();<\/code><\/pre>\n\n\n\n
I will be honest and admit that the end of the article perfectly described why my code is not as clean as I would like it to be. One thing that I struggle with a lot is keeping my code consistent. My most used programming languages are C#, Python, and JavaScript. This term, on top of it I am learning Dart  for CS 492 – Mobile Software Development. Switching from one convention to another is not an easy task, and very often I tend to ignore it just to achieve the results. However, I am confident that knowing why your code is bad, and clearly seeing the problem is already a step to writing better and cleaner code.<\/p>\n\n\n\n
Code Smells<\/h3>\n\n\n\n
For this part of the assignment, I found the article “Everything You Need To Know About Code Smells<\/a>” on codegrip.tech. I knew right away that this will be a great article because I saw this:<\/p>\n\n\n
\n
\"\"
Isn’t it funny? <\/figcaption><\/figure>\n<\/div>\n\n\n
Between clean code and code smells, the second topic is an entirely different beast to discuss. Code smells are not bugs or errors in your code. Code smells are “violations<\/strong>\u00a0of the\u00a0fundamentals of developing software<\/strong>.” The article states that code smells are different for each project and developer, and I couldn’t agree more – projects have requirements that must be met, and each developer has their own way of writing code.\u00a0<\/p>\n\n\n\n
I will admit that my code often smells more than I would want it. Very often I have duplicate code (even though I put a lot of effort in keeping it D<\/strong>on’tR<\/strong>epeatY<\/strong>ourself). My most common smells are long methods. For some reason, I always struggle to break tasks into subtasks, which would help me in splitting a large method into smaller methods.<\/p>\n\n\n\n
Additionally, the article gives different ways how to get rid of code smell. I think one of the main takeaways for me was refactoring. Refactoring is the process of rewriting code and changing software in a way that will not change the program’s behaviors. And apparently, refactoring is something that I lack. After writing my code, I rarely go back and review it or think about ways to improve it, especially when it comes to school projects. The fast pace environment does not give you a lot of time for that. However, I should definitely consider investing time in refactoring my personal and portfolio projects to make sure that code smell won’t embarrass me in front of my GitHub visitors.<\/p>\n\n\n\n
Conclusion<\/h3>\n\n\n\n
To finish my post, I want to say that it is not easy to write clean and “good” smelling code. I believe that it is something that comes with a lot of experience and requires a lot of determination to improve your code. However, I strongly believe that everyone who writes code must learn about good code practices and learn about code smells. Being able to sport bad practices and code smells in your code is already progress! Remember – practice makes perfect.<\/p>\n","protected":false},"excerpt":{"rendered":"
Clean Code \u201cClean code always looks like it was written by someone who cares.\u201d\u00a0 Robert C. Martin,\u00a0Clean Code: A Handbook of Agile Software Craftsmanship Have you ever looked at your code after a while? Or have you ever looked at someone’s code and thought you could have done it better and more efficiently? Or did […]<\/p>\n","protected":false},"author":12980,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-29","post","type-post","status-publish","format-standard","hentry","category-uncategorized","missing-thumbnail"],"_links":{"self":[{"href":"https:\/\/blogs.oregonstate.edu\/patss\/wp-json\/wp\/v2\/posts\/29","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.oregonstate.edu\/patss\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.oregonstate.edu\/patss\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/patss\/wp-json\/wp\/v2\/users\/12980"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/patss\/wp-json\/wp\/v2\/comments?post=29"}],"version-history":[{"count":1,"href":"https:\/\/blogs.oregonstate.edu\/patss\/wp-json\/wp\/v2\/posts\/29\/revisions"}],"predecessor-version":[{"id":32,"href":"https:\/\/blogs.oregonstate.edu\/patss\/wp-json\/wp\/v2\/posts\/29\/revisions\/32"}],"wp:attachment":[{"href":"https:\/\/blogs.oregonstate.edu\/patss\/wp-json\/wp\/v2\/media?parent=29"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/patss\/wp-json\/wp\/v2\/categories?post=29"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/patss\/wp-json\/wp\/v2\/tags?post=29"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}