Code or developers without quality and with smell are called different terms, such as Bloaters, Object-Orientation Abusers, Dispensable Couplers, etc. Developers who think about providing the best quality of code, always try to avoid these terms from their codes and make the critical statement "Are You a Google Developer?" true.
Below are famous code smelling words among IT professionals or developers.
- Object-Orientation Abusers
This is a word for those developers who do not know the principles of Object Oriented Paradigm very well. They spoil the code during the development or maintenance of the application, by using poor OOPS concepts.
- Bloaters
Bloaters make classes, functions, or methods very long. They dump all the code logic into one place and make it very difficult to maintain. They violate the SOLID principle "Open for Extension and Close for Modification".
- Dispensable
Some developers put useless codes in a program. It makes the class file very dirty. This type of activity or developer is called Dispensable.
- Couplers
Couplers are very famous for tight coupling in the code. They never use Dependency Injection concept. They make the code very difficult to change or enhance. They make those developers' lives hell, who maintain or enhance the tightly coupled codes.
- Socratic Managers
Socratic Managers focus on oppositional discussion in which the defense of one point of view is pitted against another.
Socratic Managers focus on delivery, by making code quality worse, full of performance issues, and always saying "Everyone can write code that is understood by a machine." But, the developers like Google developers always follow GOF's statement mentioned below.
"Everyone can write code that is understood by a machine, but not all can write code that is understood by a human being".
Gerry Weinber writes the following statement in his book, "The Psychology of Computer Programming".
"Egoless programming is all about how to help people accept criticism of their code as distinct from criticism of themselves."
Code Smell
Code Smell is a term in which computer programming code creates a problem. Martin Fowler, the writer of the famous book "Refactoring: Improving the Design of Existing Code ", always talks about code smell and says, "A code smell is a surface indication that usually corresponds to a deeper problem in the system". Code smell might not be a bug but it is a violation of basic principles of code design and it slows down the development speed. It increases the risks of bugs or failure.
Different Types of Code Smell
Code smells have basically three major categories.
- Application Level Code Smells
- Method Level Code Smells
- Design Level Code Smells
Application-Level Code Smells
This type of code smell rotates around the application. It makes the whole application code stink. Given below are some cases of Application-Level Code Smell.
- Duplicate codes existing in the application.
- Use of very complicated design pattern in place of a simple one. This type of code smell is called "Contrived Complexity".
Class-Level Code Smells
Below are some common Class-Level Code Smells.
- Making Class very large by writing more and more codes. This case is also called "God Object".
- Class using too many branches and loops. This case is called "Cyclomatic Complexity".
- Huge dependency of a class to another class. This is called "Feature Envy".
- Refused Bequest
Overriden method of a class does not give respect to the base class virtual method. It is my favorite Class-Level Code Smell.
Method-Level Code Smells
Given below are some common Method-Level Code Smells.
- Very long Method
- Too many parameters
- Poor naming convention
Design-Level Code Smell
If the developer is not aware of basics or fundamental principles of OOPS or designing, then design-level code smell occurs. Given below are some Design-Level Code Smells.
- Not aware of SOLID Principle.
- Confusion between the concept of Abstraction and Encapsulation.
- Duplicate Abstraction.
- Not aware of proper modularization.
Lack of Analysis
Most developers are not aware of analysis of code, or they do not spend some time on the analysis of code. Analysis tells the developers to find the below points.
- On what inputs is the algorithm taking less time or performing very well?
- On what inputs is the algorithm taking huge time?
- Which algorithm is taking more space?
Below are the different types of Analysis.
- Worst Case Analysis Input on which an algorithm is taking a huge amount of time or running extremely slowly
- Best Case Analysis Input on which an algorithm is taking less time.
- Average Case Analysis Lower Bound <= Average Time <= Upper Bound.
Algorithm should not run in N Square mode or should not take N or more than N Space. In this case, the code is considered as bad code. If you see Google's interview questions on Careercup.com, then you will find that Google always focuses on the Time and Space complexity of algorithms.
Also, always try to write Unit tests. It increases the code coverage and code quality.
Conclusion
Hence, always take the critical statement "Are You a Google Developer?" in a positive way. Always focus on Code Smell issues, Time & Space Complexity, and keep the basic design principles in mind. People who criticize the ability of developers can never understand the power of a Google developer.
Thus, make it a practice to write such types of code that can be understood by human beings along with machines.