This is a guideline based on principles and good practices from trusted sources of software development. As you will notice, some of these principles and practices may be applied on every programming paradigm despite some specific terms.
Do not hesitate to contribute!
Every piece of knowledge must have a single, unambiguous, and authoritative representation within a system.
Author: Andy Hunt and Dave Thomas
Reference: The Pragmatic Programmer book
Procedural code gets information then makes decisions. Object-oriented code tells objects to do things.
Author: Alec Sharp
Reference: Smalltalk by Example: The Developer's Guide
Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. Each unit should only talk to its friends; don't talk to strangers. Only talk to your immediate friends.
Author: Ian Holland
Reference: Assuring good style for object-oriented programs
A class should have only one reason to change.
Author: Robert C. Martin
Reference: SRP: The Single Responsibility Principle
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
Author: Bertrand Meyer
References: Object-Oriented Software Construction book, and The Open-Closed Principle
Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
Author: Barbara Liskov
Reference: Data Abstraction and Hierarchy, and The Liskov Substitution Principle
Abstract classes should not depend upon concrete classes; concrete classes should depend upon abstract classes.
Author: Robert C. Martin
Reference: The Dependency Inversion Principle
Clients should not be forced to depend upon interfaces that they do not use.
Author: Robert C. Martin
Reference: The Interface Segregation Principle
Duplication is far cheaper than the wrong abstraction; prefer duplication over the wrong abstraction.
Author: Sandi Metz
Reference: RailsConf 2014 - All the Little Things
Always implement things when you actually need them, never when you just foresee that you need them.
Author: Ronald E Jeffries
Reference: You're NOT gonna need it!
An object-oriented framework is "a (generative) architecture designed for maximum reuse, represented as a collective set of abstract and concrete classes; encapsulated potential behaviour for subclassed specializations." The major difference between an object-oriented framework and a class library is that the framework calls the application code. Normally the application code calls the class library. This inversion of control is sometimes named the Hollywood principle, "Do not call us, we call You".
Author: Michael Mattson
Reference: Object Oriented Frameworks: a survey on methodological issues and On Inversion of Control
Adding possibly redundant code "just in case" only contributes to the software's complexity - the single worst obstacle to software quality in general, and to reliability in particular. The result of such blind checking is simply to introduce more software, hence more sources of things that could go wrong at execution time, hence the need for more checks, and so on ad infinitum. Such blind and often redundant checking causes much of the complexity and unwieldiness that often characterizes software.
Author: Bertrand Meyer
Reference: Applying "Design by Contract"
Please, contribute!
Made by Rafael Soares with <3