Good code vs Bad code

The Difference Between Good and Bad Code

The difference between good and bad code is in two main aspects: style and intent. The word "style" is not here in its traditional sense, as in fashion, but as a style of programming that can be bad, normal, and beautiful. However, the main thing here is not elegance, but readability. Good code requires minimal effort on the part of the reader to understand the author's intent. On the machine side, good code requires fewer resources and less time to process a task than bad code. In good code, each part individually is of high quality and also fits together perfectly and works flawlessly. In the case of bad code, the individual parts are of poor quality, and they are merged, which does not make sense, which leads to the fact that it works roughly and does not last long.

In this article, we will have a look at qualities of good and bad code, besides, below you can find some examples of them.

Qualities of good code:

• Easy to understand.

• Good code is well organized. Data and operations in classes fit together. There are no extraneous dependencies between the classes.

• Allows for implicit byproducts such as safety, compile-time, small operations, number of calls, etc.

• Works within a reasonable time frame.

• Comments explain why something is being done, not what is being done. Comments should be minimal.

• Uses meaningful naming conventions for all objects.

• The code should be well tested. Tests serve as an executable code specification and examples of its use.

The qualities of bad code:

• Bad code looks like something that was written in a hurry, without giving any meaning.

• No documentation.

• Unnecessary use of loop and jump operators.

• It takes more time and resources to complete than usual.

• Poor coding standard and style.

• Complex and challenging.

• Poorly tested and fails quietly.

 

Good Code vs Bad Code

Bad code will damage your bank with its technical debt, taking most of it from there. And there will come a point when someone reads your bad code and hardly understands it. You are now stuck with developing, debugging, refactoring, and modifying your code. All of this could have been avoided if you had simply decided to write better code.

In addition to development, recruiters are looking for good coders during interviews to select from a variety of the best. In their opinion, many can write code to solve the problem. While we have already discussed what measures should be taken to write error-free code during an interview. We look more broadly at how easy it is to tell good code from bad code.

 

Bad Code Examples

It is a myth that when checking for bad code, someone convinces us to change our code, even if what we wrote is correct. Person-suggested changes will lead to errors. However, such situations are extremely rare - they are the result of a mistake or ignorance of the problem, and most often they happen to beginners who are relatively easy to explain why their comment was grossly mistaken.

The greatest risk we face when reviewing code is in haste or when we are tired. It is then that we do not notice mistakes that we would otherwise have noticed right away.

Unfortunately, the most overlooked bugs in code are not minor damage that is easy to fix, but in most cases;

• bugs related to violation of the generally accepted architecture,

• errors in the logic of our application.

 

Good Code Examples

Code review creates an excellent environment for sharing programming language knowledge that is the result of experience.

How do you know if you are writing good code, you may ask?

When you need to go back and add/change a function, is it difficult? Are you constantly breaking existing functionality when you make changes? If the answer to the above question is yes, then you probably have a bad general code. It's a little tricky to judge code until you need to react to changes.

Clear code benefits are obvious. It allows:

• any employee to comprehend an unfamiliar project;

• developers can easily make small changes;

• relatively fast restructuring of the project to meet the new requirements of the customer;

• safely introduce new technologies to keep things working.

All you need to do is look at good code to understand its basic principles. In other words, if only an advanced or ingenious developer can get an idea of what you have written, you can hardly call such code good. If any junior can easily understand the code, that's really excellent.

 

Code Architecture and Style

The architecture and design of the source file is something that can show whether the developer is efficient and proficient at writing code, even if you don't even read the actual code. The appearance of the code is the first characteristic of good code. Correct indentation and no extra backtracking allow the reader to understand where the code starts and ends. Well-structured code is good code.

 

Comments and Read Me

We're not talking about blockers, but about comments that are badly needed. Good code has commented on functions and classes that are either too complex or too long to be understood simply by reading them. In addition, your code will be edited or used by other developers sometime in the future. The two of you rarely have the same writing styles and conventions. Therefore, a short, self-explanatory comment becomes important.

If your code needs to be reviewed by someone who isn't too knowledgeable about it, that's what happens in large organizations and open-source software. You should use Read Me as an introductory start. Read Me files are the first file that an external user checks or looks for before opening the code in order to understand what you have achieved. It can contain information about your code, your approach, and the metrics used. See also the naming conventions and packages you used, licensing, versions, and author information.

 

Code Smells

Smelly code means there is a bigger problem in your code. It could be structure, functionality, or just the bulkiness of your file. Duplicate codes, one of the simplest code smells is duplicate blocks or lines that appear in the source file. They create extra lines of code, decrease efficiency, and increase your technical debt.

Another reason they are called code smells is that they are easy to see and therefore clearly distinguish between good and bad code. God class, shotgun surgery, will rejection are some of the code smells. You can find out more about all types of odors in the "Everything you need to know about code smells" section.

 

Principles

Think of a book on advanced programming you had in college, grab it and go over everything you have on hand. Yes, good programmers have their own coding principles. It is easier to identify code written in principles because they follow some trail that you can identify.

If you see code that is open for extension and closed for change, it means that the developer was using the open/closed principle. The open/closed principle is important when releasing a code library. If you see a function or class doing only one job, or focusing on one function, that means that the coder has followed the principle of single responsibility. This makes your code efficient and straightforward. Bad codes are written randomly and may not conform to principles. But if they do, they will not be consistent throughout the code.

 

Packages

A developer who writes everything from scratch is great only when you need to demonstrate your capabilities, but not when you are actually building a product. There are a huge number of libraries on the Internet for most languages, created by reputable computer scientists and mathematicians. Their libraries or packages are free to use most of the time and can be easily retrieved, read, and even modified if you need to change something about it.

The best part is that they are highly effective, trustworthy, and researched. Their use saves time, reduces the number of lines of code, which, in turn, reduces the number of errors that can be made. So next time you're looking for a good one, look for any packages it might have and you'll recognize them. These encoders are smart, practical, and know that time is valuable.