{"id":20,"date":"2025-01-17T02:57:31","date_gmt":"2025-01-17T02:57:31","guid":{"rendered":"https:\/\/blogs.oregonstate.edu\/crashtocash\/?p=20"},"modified":"2025-01-17T03:06:31","modified_gmt":"2025-01-17T03:06:31","slug":"it-doesnt-have-to-be-a-bug-to-smell","status":"publish","type":"post","link":"https:\/\/blogs.oregonstate.edu\/crashtocash\/2025\/01\/17\/it-doesnt-have-to-be-a-bug-to-smell\/","title":{"rendered":"It doesn’t have to be a bug to smell."},"content":{"rendered":"\n
\n

\u201cIndeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. …[Therefore,] making it easy to read makes it easier to write.\u201d
\u2015 Robert C. Martin, <\/strong>Clean Code: A Handbook of Agile Software Craftsmanship<\/a><\/p>\n<\/blockquote>\n\n\n\n

Writing software is often a monumental undertaking. In any large project, you could have a codebase with tens of thousands of lines of code\u2014or even more! As the codebase grows, so does the challenge of maintaining it. Without proper structure and clarity, reading the code can quickly turn into a nightmare. Have you ever seen a function named something like “HandleData()” that has a docstring that reads “Handles the data passed as an argument” and is 300 lines long? Were you the one to write it…you were weren’t you? What data are we handling? What does “handling” entail? Why are you like this?<\/strong><\/p>\n\n\n\n

Lessons Learned<\/h2>\n\n\n\n

Listen, I know you’re telling everyone you read Clean Code<\/em> by Robert Martin, so am I. However, we both know it was in audio book format in the background at 10% volume as you rewatched The Office<\/em> or whatever other degenerate stuff you get up to. So let me give you the lowest hanging fruit:<\/p>\n\n\n\n

Short Single Purpose Functions<\/h3>\n\n\n\n

Listen it isn’t like I don’t believe in you, I do! However, writing short function that do one<\/strong> thing can make up for a lot of other bad practices. For example, lets look at an example of terrible code that is improved drastically with this one tip. For example: <\/p>\n\n\n\n

def stuff():\n    a = 10\n    b = 20\n    c = a + b\n\n    # Do things\n    print(c)\n\n    # Do other things\n    d = thing(c)\n    print(d)\n\ndef thing(e):\n    return e * 2  # Double it\n<\/code><\/pre>\n\n\n\n
That hurt to write. Look<\/strong> at it! However, imagine you are exploring this terrible code, you can just jump to the definition of the “thing()” function and see within seconds what it does. No docstring needed. Imagine if every function in the code is like this, it almost makes it bearable.<\/p>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
I know what you are thinking, “It is already over? Did this guy just monologued for two paragraphs, give one tip, then quit?” Listen, you aren’t going to learn about clean coding in one blog post. However, if you want to get started here is a summary of Clean Code<\/em>, don’t ask me how I know about it.<\/p>\n\n\n\n
Clean Code Summary<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
\u201cIndeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. …[Therefore,] making it easy to read makes it easier to write.\u201d\u2015 Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship Writing software is often a […]<\/p>\n","protected":false},"author":14517,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-20","post","type-post","status-publish","format-standard","hentry","category-uncategorized","missing-thumbnail"],"_links":{"self":[{"href":"https:\/\/blogs.oregonstate.edu\/crashtocash\/wp-json\/wp\/v2\/posts\/20","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.oregonstate.edu\/crashtocash\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.oregonstate.edu\/crashtocash\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/crashtocash\/wp-json\/wp\/v2\/users\/14517"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/crashtocash\/wp-json\/wp\/v2\/comments?post=20"}],"version-history":[{"count":2,"href":"https:\/\/blogs.oregonstate.edu\/crashtocash\/wp-json\/wp\/v2\/posts\/20\/revisions"}],"predecessor-version":[{"id":23,"href":"https:\/\/blogs.oregonstate.edu\/crashtocash\/wp-json\/wp\/v2\/posts\/20\/revisions\/23"}],"wp:attachment":[{"href":"https:\/\/blogs.oregonstate.edu\/crashtocash\/wp-json\/wp\/v2\/media?parent=20"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/crashtocash\/wp-json\/wp\/v2\/categories?post=20"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/crashtocash\/wp-json\/wp\/v2\/tags?post=20"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}