There are two types of code—good code and bad code. The syntax of both types of code may be correct when compiled and running the code can give the expected results. However, bad code leads to serious issues when it comes to extending or even making little changes to the code, due to the way it was written.
When programmers write code using unprofessional approaches and styles, this often results in bad code. Also, the use of unreadable coding styles or formats as well as not properly and effectively testing code are all precursors to bad code. Code can be written poorly when programmers sacrifice professionalism in order to meet approaching deadlines and project milestones.
I have come across a few software projects that rapidly become legacy software projects that are abandoned because of incessant production bugs and the inability to incorporate change requests from users easily. This is because these software applications were deployed into production with a severe accumulation of technical debts through bad code written by software developers as a result of making poor design and development decisions and using programming styles known to cause future maintenance problems.
Source code elements—methods, classes, comments, and other artifacts—should be easy to read, understand, debug, refactor, and extend if required by another developer other than the original developer; otherwise, bad code has already been written.
You know you have bad code when, extending or adding new features, you break the existing working features. This can also happen when there are portions of code that cannot be decoded or any changes to them will bring the system to a halt. Another reason for bad code is usually because of nonadherence to object-oriented and Don't Repeat Yourself (DRY) principles or wrong use of the principles.