The (second) first post

As a developer, it is important to write clean and readable code that is easy to maintain and understand. However, as projects grow and evolve, it can be easy for code to become cluttered and difficult to navigate. This is where code smells come in. Code smells are indicators that something may be wrong with the code, such as poor design or lack of organization.

One example of a code smell is the use of magic numbers. Magic numbers are numerical values that are used in the code without any explanation of their meaning. It can be difficult to understand the purpose of a magic number, and it can also make the code less readable. A better practice would be to use constants or variables to store these values and give them a meaningful name.

example of “magic numbers”
cleaned up

Another example of a code smell is duplicated code. Duplicated code is when the same code is repeated multiple times throughout a project. Not only is this a sign of poor organization, but it also makes it harder to maintain the code. When a change needs to be made, it must be made in multiple places, increasing the chance of introducing bugs. To avoid this, it is better to refactor the code and extract common functionality into a separate function or method.

On the other hand, writing clean code is all about making sure your code is easy to understand, maintain and change. To write clean code, it is important to follow a consistent coding style, to use meaningful variable and function names, and to organize your code in a logical way.

A good example of clean code is the Single Responsibility Principle (SRP). SRP states that a class should have one and only one reason to change. This means that a class should have a single, well-defined responsibility. This makes it easy to understand the purpose of a class and also makes it easier to change or extend the class in the future.

Another example of clean code is the separation of concerns. Separation of concerns means that different parts of the code should be responsible for different things. For example, the code for handling user input should be separate from the code for displaying output. This makes it easier to understand the code and also makes it easier to change or extend the code in the future.

Martin Fowler said “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” As a student, I would definitely say I got into the bad habit of not writing super clean code, especially for smaller assignments. Working on this capstone project has definitely influenced the code I’ve been writing for other classes for the better.