{"id":22,"date":"2025-01-17T00:01:14","date_gmt":"2025-01-17T00:01:14","guid":{"rendered":"https:\/\/blogs.oregonstate.edu\/eades\/?p=22"},"modified":"2025-01-17T00:01:14","modified_gmt":"2025-01-17T00:01:14","slug":"clean-code-clean-workflow","status":"publish","type":"post","link":"https:\/\/blogs.oregonstate.edu\/eades\/2025\/01\/17\/clean-code-clean-workflow\/","title":{"rendered":"Clean Code, Clean Workflow"},"content":{"rendered":"\n<p>After reading through the first chapter of Robert Martin&#8217;s book, Clean Code: A Handbook of Agile Software Craftmanship, I came away with a few key takeaways that I would like to highlight which may prove useful to programmers, particularly those who strive to write code that is not only functional, but also <strong>maintainable<\/strong> and <strong>scalable<\/strong>. <\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Code degradation &#8211; A personal shortcoming<\/h4>\n\n\n\n<p>One area I seek to improve on as I continue in my programming journey is  what Martin calls &#8220;The Boy Scout Rule&#8221;. The Boy Scouts have a rule to &#8220;leave the campground cleaner than you found it&#8221;, and Martin applies this same rule to writing code. He argues that code needs to be kept clean over time and it is a common problem to see code begin to degrade overtime. <\/p>\n\n\n\n<p>In the past courses here at OSU I have had a couple of occasions where I had projects that lasted around the whole term, and I started off great, adhering to all the principles of code cleanliness that I knew of at the time. However, as the term progressed and deadlines loomed, my code began to get sloppier as I was resorting to quick fixes while ignoring the root causes of issues. <\/p>\n\n\n\n<p>My biggest problem area is the length of my functions. I will often continuous add to a single function rather than break it down into smaller, more manageable pieces. I found a small example of this in my coding project from my Software Engineering I class, here it is:<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"935\" height=\"764\" src=\"https:\/\/osu-wams-blogs-uploads.s3.amazonaws.com\/blogs.dir\/8151\/files\/2025\/01\/image.png\" alt=\"\" class=\"wp-image-23\" srcset=\"https:\/\/osu-wams-blogs-uploads.s3.amazonaws.com\/blogs.dir\/8151\/files\/2025\/01\/image.png 935w, https:\/\/osu-wams-blogs-uploads.s3.amazonaws.com\/blogs.dir\/8151\/files\/2025\/01\/image-300x245.png 300w, https:\/\/osu-wams-blogs-uploads.s3.amazonaws.com\/blogs.dir\/8151\/files\/2025\/01\/image-768x628.png 768w\" sizes=\"auto, (max-width: 935px) 100vw, 935px\" \/><\/figure>\n\n\n\n<p>This is a brief snippet of a damage calculator I was making for a video game I play. In an attempt to not clog this post with code, I omitted two other equip functions, armor and ring, which both had the same forms of error messages. Looking back, I could have made my code much cleaner by creating an equip_item function which was passed information via the equip_weapon, ability, etc. functions, which would save a lot of unnecessary repetition. <\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Moving Forward<\/h4>\n\n\n\n<p>Reflecting on my past code, and after reading about Martin&#8217;s Boy Scout Rule, I felt a &#8220;click&#8221; as I realized some of the shortcomings of my previous programming experiences. The idea of working to leave the code base cleaner than I found it makes a lot sense, and gives a visible goal to look towards as I am working on my code.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">References<\/h4>\n\n\n\n<p>Martin, Robert C. Clean Code: A Handbook of Agile Software Craftsmanship. 1st edition, Pearson, 2008.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>After reading through the first chapter of Robert Martin&#8217;s book, Clean Code: A Handbook of Agile Software Craftmanship, I came away with a few key takeaways that I would like to highlight which may prove useful to programmers, particularly those who strive to write code that is not only functional, but also maintainable and scalable. [&hellip;]<\/p>\n","protected":false},"author":14543,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-22","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/blogs.oregonstate.edu\/eades\/wp-json\/wp\/v2\/posts\/22","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.oregonstate.edu\/eades\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.oregonstate.edu\/eades\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/eades\/wp-json\/wp\/v2\/users\/14543"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/eades\/wp-json\/wp\/v2\/comments?post=22"}],"version-history":[{"count":2,"href":"https:\/\/blogs.oregonstate.edu\/eades\/wp-json\/wp\/v2\/posts\/22\/revisions"}],"predecessor-version":[{"id":25,"href":"https:\/\/blogs.oregonstate.edu\/eades\/wp-json\/wp\/v2\/posts\/22\/revisions\/25"}],"wp:attachment":[{"href":"https:\/\/blogs.oregonstate.edu\/eades\/wp-json\/wp\/v2\/media?parent=22"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/eades\/wp-json\/wp\/v2\/categories?post=22"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/eades\/wp-json\/wp\/v2\/tags?post=22"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}