rafaels88 / software-development-guideline Goto Github PK

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