{"id":21,"date":"2024-01-12T02:27:46","date_gmt":"2024-01-12T02:27:46","guid":{"rendered":"https:\/\/blogs.oregonstate.edu\/philipseniorproject\/?p=21"},"modified":"2024-01-12T02:27:46","modified_gmt":"2024-01-12T02:27:46","slug":"clean-code-and-code-smells","status":"publish","type":"post","link":"https:\/\/blogs.oregonstate.edu\/philipseniorproject\/2024\/01\/12\/clean-code-and-code-smells\/","title":{"rendered":"Clean Code and Code Smells"},"content":{"rendered":"\n<h3 class=\"wp-block-heading\">What I Want to Do More<\/h3>\n\n\n\n<p>In the chapter <em>Bad Code Smells <\/em>from the book Refactoring: Improving the Design of Existing Code, Martin Fowler recommends that if you feel the need to comment a block of code, you should just write a new method instead. Following this heuristic helps to make code cleaner as long methods often do too much, and cause us to duplicate messy code. My creating shorter methods, they become more readable and more reusable. As Bjorne Stroustrup suggests, &#8220;you want to make it hard for bugs to hide&#8221;. Shorter methods also help to improve readability as each method does what it\u2019s name suggests, and can even improve developer efficiency. If the name is good enough, the developer won&#8217;t have to spend time looking at the method definition.\u00a0<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Example of Long Methods<\/h4>\n\n\n\n<p>In this example function definition <em>generateTestEmailLargeAsync<\/em> below, the function generates a new email to test the email messaging service.\u00a0<\/p>\n\n\n\n<p>Three obvious partitions in the code split the logic between creating the message, sending the message, and processing the response.\u00a0In order to make these splits clear, we have to comment our code accordingly.<\/p>\n\n\n<div class=\"wp-block-syntaxhighlighter-code \"><pre class=\"brush: jscript; title: ; notranslate\" title=\"\">\nasync function generateTestEmailLargeAsync() {\n  \/\/ create the message\n  const message = &quot;This is a message to Email&quot;;\n  const recipients = &quot;test@oregonstate.edu&quot;;\n  const email = new Email(message, recipients);\n\n\n  \/\/ send the message\n  const emailClient = new EmailClient();\n  const response = await emailClient.SendEmailAsync(email);\n\n\n  \/\/ process the response\n  if (response.Code == 200) {\n    return &quot;Success!&quot;\n  }\n  else {\n    return &quot;There was an issue sending the email.&quot;\n  }\n}\n<\/pre><\/div>\n\n\n<p>If we follow the heuristic mentioned in the previous section, then we would want to split this code into smaller methods. Each section will have it&#8217;s own method, with it&#8217;s own responsibilities which will help to clarify what each section of code does without having to comment it.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Example of Short Methods<\/h4>\n\n\n\n<p>This method <em>generateTestEmailLittleAsync <\/em>instead uses smaller methods to perform the same function as the previous long method. However, the function is made clearer by putting the other logic into their own smaller, discrete methods. <\/p>\n\n\n<div class=\"wp-block-syntaxhighlighter-code \"><pre class=\"brush: jscript; title: ; notranslate\" title=\"\">\nasync function generateTestEmailLittleAsync() {\n  const email = createEmail();\n  const response = await sendEmailAsync(email);\n  return processReponse(response);\n}\n\n\nfunction createEmail() {\n  const message = &quot;This is a message to Email&quot;;\n  const recipients = &quot;test@oregonstate.edu&quot;;\n  const email = new Email(message, recipients);\n  return email;\n}\n\n\nasync function sendEmailAsync(email: Email) {\n  const emailClient = new EmailClient();\n  const response = await emailClient.SendEmailAsync(email);\n  return response;\n}\n\n\nfunction processReponse(response: EmailResponse) {\n  if (response.Code == 200) {\n    return &quot;Success!&quot;\n  }\n  else {\n    return &quot;There was an issue sending the email.&quot;\n  }\n}\n\n<\/pre><\/div>\n\n\n<h3 class=\"wp-block-heading\">What I Want to Avoid<\/h3>\n\n\n\n<p>In line with the last section, one thing I want to avoid in future development work is creating duplicate code. Creating smaller methods helps to reduce the chances of having duplicate code because these components become easily reusable. For example, when dealing with large code bases with many methods and classes, as new development work is done, classes and methods need to be continuously refactored to keep the code clean. This process has to be done as soon as possible as it can get away from a developer very quickly if they assume they will make time for it later. As I learned in Chapter 1: <em>Clean Code<\/em> in the book Clean Code by Robert Martin, when it comes to development work &#8220;Later equals Never&#8221;. So, this is where the method of extracting and unifying becomes helpful.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Example of Duplicated Code<\/h4>\n\n\n\n<p>In the example below, there is a section of duplicated code that is shared between the methods <em>generateReport <\/em>and <em>processRequest<\/em>. Most of the time, I feel that duplicated code is not as obvious as this, and can actually be spread far across a code base. Meaning, it won&#8217;t show up in the same file of code. <\/p>\n\n\n<div class=\"wp-block-syntaxhighlighter-code \"><pre class=\"brush: jscript; title: ; notranslate\" title=\"\">\nasync function generateReport(data: ReportData, recipients: string) {\n  const reportFile = &quot;test.xlsx&quot;;\n  const processedReport = GenerateReport(data);\n  const reportBytes = processedReport.ToBytes();\n\n  \/\/ Duplicate code below\n  const email = createEmail(reportBytes);\n  const response = await sendEmailAsync(email, recipients);\n  return processReponse(response);\n}\n\nasync function processRequest(message: string, recipients: string) {\n  messageBytes = message.toBytes();\n\n  \/\/ Duplicate code below\n  const email = createEmail();\n  const response = await sendEmailAsync(email, recipients);\n  return processReponse(response);\n}\n<\/pre><\/div>\n\n\n<h4 class=\"wp-block-heading\">Example of Extracted Code<\/h4>\n\n\n\n<p>To reduce code duplication, you can perform an extraction of the shared code and create a shared function. <\/p>\n\n\n<div class=\"wp-block-syntaxhighlighter-code \"><pre class=\"brush: jscript; title: ; notranslate\" title=\"\">\nasync function generateReport(data: ReportData, recipients: string) {\n  const reportFile = &quot;test.xlsx&quot;;\n  const processedReport = GenerateReport(data);\n  const reportBytes = processedReport.ToBytes();\n\n  return generateEmailAsync(messageBytes);\n}\n\nasync function processRequest(message: string, recipients: string) {\n  messageBytes = message.toBytes();\n\n  return generateEmailAsync(messageBytes);\n}\n\nasync function generateEmailAsync(message: bytes&#x5B;], recipients: string) {\n  const email = createEmail();\n  const response = await sendEmailAsync(email, recipients);\n  return processReponse(response);\n}\n<\/pre><\/div>\n\n\n<p>Now, both functions can use the same code to generate an email. <\/p>\n","protected":false},"excerpt":{"rendered":"<p>What I Want to Do More In the chapter Bad Code Smells from the book Refactoring: Improving the Design of Existing Code, Martin Fowler recommends that if you feel the need to comment a block of code, you should just write a new method instead. Following this heuristic helps to make code cleaner as long [&hellip;]<\/p>\n","protected":false},"author":13724,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-21","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/blogs.oregonstate.edu\/philipseniorproject\/wp-json\/wp\/v2\/posts\/21","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.oregonstate.edu\/philipseniorproject\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.oregonstate.edu\/philipseniorproject\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/philipseniorproject\/wp-json\/wp\/v2\/users\/13724"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/philipseniorproject\/wp-json\/wp\/v2\/comments?post=21"}],"version-history":[{"count":5,"href":"https:\/\/blogs.oregonstate.edu\/philipseniorproject\/wp-json\/wp\/v2\/posts\/21\/revisions"}],"predecessor-version":[{"id":26,"href":"https:\/\/blogs.oregonstate.edu\/philipseniorproject\/wp-json\/wp\/v2\/posts\/21\/revisions\/26"}],"wp:attachment":[{"href":"https:\/\/blogs.oregonstate.edu\/philipseniorproject\/wp-json\/wp\/v2\/media?parent=21"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/philipseniorproject\/wp-json\/wp\/v2\/categories?post=21"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/philipseniorproject\/wp-json\/wp\/v2\/tags?post=21"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}