What we need

We can certainly agree that the following list of concerns are universal. Our code should be:

• Modular: The functionality of your program should be pided into independent modules, each of which contains what it needs to perform one aspect of the program functionality. Changes in a module or function shouldn't affect the rest of the code.
• Understandable: a reader of your program should be able to discern its components, their functions, and understand their relationships without undue effort. This is highly correlated with maintainability: your code will have to be maintained at some time in the future, to change or add some new functionality.
• Testable: unit tests try out small parts of your program, verifying their behavior with independence of the rest of the code. Your programming style should favor writing code that simplifies the job of writing unit tests. Also, unit tests are like documentation, insofar that they can help readers understand what the code is supposed to do.
• Extensible: it's a fact that your program will someday require maintenance, possibly to add new functionality. Those changes should impact only minimally (if at all) the structure and data flow of the original code. Small changes shouldn't imply large, serious refactorings of your code.
• Reusable: code reuse has the goal of saving resources, time, money, and reducing redundancy, by taking advantage of previously written code. There are some characteristics that help this goal, such as modularity (which we already mentioned), plus high cohesion (all the pieces in a module do belong together), low coupling (modules are independent of each other), separation of concerns (the parts of a program should overlap in functionality as little as possible), and information hiding (internal changes in a module shouldn't affect the rest of the system).