Difference between Good and Bad code
Difference between Good and Bad code
Either coder writes good codes or really bad ones; both of those are correct and do not make a difference until they are compiled and run. Anything further than that bad code will take a plunge into your bank with its technical debt, taking a big chunk out of there. And there would be some point time when someone reads your bad code and barely understands it. Now you are stuck developing, debugging, refactoring and modifying your code. All this could have been avoided if you could have just chosen to write better code.
Apart from development, recruiters look for good coders during the interview so that they choose the best out of the lot. As far as they are concerned, many can write code to solve a problem. But only a few can write it exceptionally well. While we have already discussed what measures you should take to write bug-free code at interviews. We take a wider view of how one can easily differentiate between good and bad codes.
Code Architecture and Style
The architecture and design of a source file is something that can show if a developer is efficient and skilled in code writing without you even reading the actual code. The way code looks is the first characteristic of a good code. Proper indentations and no extra returns make it easier for a person reading to understand where the code starts and ends. A properly structured code is good code.
Comments and Read Me
We are not talking about blockers but comments which are highly required. Good codes have comments to functions and classes that are either too complex or too long to understand by just reading it. Also, your code will sometime in the future be edited or used by some other developers. It is highly rare that both of you have the same writing styles and conventions. Hence a brief self-explanatory comment becomes important.
If your code is to be reviewed by someone who isn’t too aware of it, something that happens in big organizations and in public software. It’s important you use Read Me as an introductory start. Read Me files are the first file that a reviewer or external user looks for before opening to code to understand what you have achieved. It may contain what your code is about, what your approach was and what are the metrics involved. Also, naming conventions and packages that you have used, licensing, versions and detail about the author.
Code Smells
The smelly code does not actually smell but means that your code has a deeper problem. This could be structural, functionality or just bulkiness of your file. Duplicate codes, one of the simpler code smells, are repetitive blocks or lines that appear in a source file. They add up to extra lines of code, decrease efficiency and increase your technical debt.
Another reason they are called code smells is because they are easy to see and hence clearly differentiate between good and bad code. God class, shotgun surgery, and refused bequest are some of the code smells. You can check more about all types of smells at “Everything you need to know about code smells.”
Principles
Remember the advanced programming book you had in your college, take that out and go through all that’s available. Yes, good coders have their principles set on how they write code. Identifying code written on principles is easier as they follow some footprints that you can tell.
If you see a code that’s open to extension and closed to modification, it means that the developer used the open/closed principle. The open/closed principle is important when releasing a library of code. If you see that a function or class if doing only one job or focuses on one functionality, it means the coder followed the Single Responsibility Principle. It makes your code efficient and also understandable. Bad codes are randomly written and may not follow principles. But if they do, they are not consistent throughout the code.
Packages
A developer who writes everything from scratch is great, only if you need to show off your capabilities but not when you are actually building a product. There is a vast ocean of libraries for most languages on the internet, which are created by credible computer scientists and mathematicians. These libraries or packages are free to use most time and can be easily obtained, read and even altered if you need to shift something in it.
The best part of it is that they are highly efficient, trustworthy and researched. Using them saves time and decreases code lines which in turn decreases the errors one can make. So next time you look for a good one, look for any packages it may have, and you may recognize. Such coders are smart and practical and know that time is valuable.
Increase your code quality by getting accurate code review reports. Sign Up on our Automated Code Review Tool now for Free!
Liked what you read? Subscribe and get fresh updates.
P.S. Don’t forget to share this post
