{"id":32,"date":"2023-01-27T07:47:19","date_gmt":"2023-01-27T07:47:19","guid":{"rendered":"https:\/\/blogs.oregonstate.edu\/brahmrifino\/?p=32"},"modified":"2023-01-27T07:47:19","modified_gmt":"2023-01-27T07:47:19","slug":"winter-blog-1","status":"publish","type":"post","link":"https:\/\/blogs.oregonstate.edu\/brahmrifino\/2023\/01\/27\/winter-blog-1\/","title":{"rendered":"Winter – Blog 1"},"content":{"rendered":"\n

Clean Code<\/strong><\/p>\n\n\n\n

I would like to start keeping functions more easier to read, better commented, and shorter. I can think of many times where I have these long functions that are written out, that eventually do what they are supposed to, but are long and sometimes hard to read. We can see in this example below of a function that loads data from a url.\u00a0<\/span><\/p><\/p>\n\n\n\n

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

Splitting up this function into smaller one and done tasks is a great way to increase readability and maintainability of said code. Looking at the beginning of the load_data function we could start by splitting up the download and unzip actions of the function.<\/p>\n\n\n\n

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

Seen below we now have the download action of load_data() into its own single task function.<\/span><\/p>\n\n\n\n

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

We could continue on with splitting load_data() into functions into smaller single task functions but you get the idea right? In the end, splitting up large functions like this example is an easy thing to do, and something that I will definitely start practicing!<\/p>\n\n\n\n

DATA DUMps<\/strong><\/p>\n\n\n\n

One of the code smell examples was data clumping. Data clumping appears to be a common mistake, I sure know I do this! Clumping is when there are multiple method calls that access the same set of parameters or when related data is grouped together. An example of this code smell can be seen below.<\/p>\n\n\n\n

<\/p>\n\n\n\n

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

Here we have an example of an object that represents a booking aspect of a hotel. There are two different time parameters that are needed for the complete booking time. Splitting these two parameters away from the booking class and into a class of their own would make the code easier to read and maintain.<\/p>\n\n\n\n

<\/p>\n\n\n\n

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

Creating this new class for the time frame gives us a new entity that interacts with the booking class. The below \u201cpolished\u201d example definitely provides us with a cleaner and more readable section of code!<\/p>\n\n\n\n

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

I can already think of times that I\u2019ve had overcrowded clumps of data throughout my code. So much that when trying to troubleshoot or read through my code becomes a tedious and confusing process. So remembering what I have learned today I hope this helps me to write cleaner, more readable, and less clumpy code.<\/p>\n\n\n\n

Good luck out there!<\/p>\n\n\n\n

Brahm<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n

Sources – <\/p>\n\n\n\n

https:\/\/www.pluralsight.com\/blog\/software-development\/10-steps-to-clean-code<\/a><\/p>\n\n\n\n

\nhttps:\/\/apiumhub.com\/tech-blog-barcelona\/code-smells\/\n<\/div><\/figure>\n\n\n\n

https:\/\/www.servicenow.com\/community\/developer-articles\/code-smells-refactoring-data-clump<\/a><\/p>\n\n\n\n

s-including-parameter-lists\/ta-p\/2320891<\/a><\/p>\n\n\n\n

\n
Clean Code Principles: Be a Better Programmer<\/a><\/blockquote>