Let's start with the definition of legacy code. While there are many authors with different definitions, such as lack of trust in your application or your tests, code that is no longer supported, and so on. We like the one created by Michael Feathers the most:
"Legacy code is code without tests. The reason for this definition is that it is objective: either there are or there aren't tests."
– Michael Feathers
How do we detect legacy code? Although legacy code usually equates to bad code, Michael Feathers exposes some smells in his book, Working Effectively with Legacy Code, by Dorling Kindersley (India) Pvt. Ltd. (1993).
Code smell.
Smells are certain structures in the code that indicate violation of fundamental design principles and negatively impact design quality.
Code smells are usually not bugs—they are not technically incorrect and do not currently prevent the program from functioning. Instead, they indicate weaknesses in design that may be slowing down development or increasing the risk of bugs or failures in the future.
Source: http://en.wikipedia.org/wiki/Code_smell.
Smells are certain structures in the code that indicate violation of fundamental design principles and negatively impact design quality.
Code smells are usually not bugs—they are not technically incorrect and do not currently prevent the program from functioning. Instead, they indicate weaknesses in design that may be slowing down development or increasing the risk of bugs or failures in the future.
Source: http://en.wikipedia.org/wiki/Code_smell.
One of the common smells for legacy code is I can't test this code. It is accessing outside resources, introducing other side effects, using a new operator, and so on. In general, good design is easy to test. Let's see some legacy code.