Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

From the blog Comfy Blog by and used with permission of the author. All other rights reserved by the author.

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Throughout the semester, we talked about microservices here and there and went over them in several activities and look to continue working with them in the coming weeks. This blogpost will be dedicated to them and their architecture. I have chosen an article written by Alyssa Walker that takes what we have already seen in previous activities and takes them into a greater level of analysis than previously looked at and also includes information about SOA I had not known about. This I deemed good enough to write a blog post about.

In summary of what I have read from the article, microservices is a type of architecture pattern in which services are provided to other parts from applications. Alyssa goes into monolithic architecture and compares the two in detail with a focus on the cons of monolithic architecture and pros of microservices. Microservices have several advantages such as with the start of time and the allocation of resources in different sectors is much easier to manage than with monolithic. The separation of the services make it much easier to work on making changes to the program in cases of faults in which availability will be there unlike in monolithic. She also includes talking about service oriented architecture in general and how microservices are an implementation of SOA.

This article has taught me several things about the different kinds of architecture we have and some reasons for why we are using microservices instead of monolithic in our activities. Microservices also seem to be a relatively newish idea, coming to fruition somewhere in the 2000s, which makes sense as how the computing world changed quite rapidly during the past few decades and how docker is a tool used for microservices. The advantages are quite useful to us such as with team members as we are not exactly a large team working on this project in which a larger team would be needed for a monolithic style project. Also considering the nature of this project and how it is being helped developed by students, there are probably going to be numerous faults that need to be fixed in which microservices would benefit better due to its separated services. It also makes me wonder of the issues that would arise in our food pantry program if we were to use monolithic architecture instead. This information in general will help me understand our work down the line as we work on the LibreFoodPantry program eventually and in the future as we develop into our careers and work with microservices in other places.

Source: https://www.guru99.com/microservices-tutorial.html

From the blog CS@Worcester – kbcoding by kennybui986 and used with permission of the author. All other rights reserved by the author.