Skip to content

iamrichardjones/programming-principles

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

17 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Programming Principles

Every programmer benefits from understanding programming principles and patterns. This overview is a reference for myself, and I've just put it here. Maybe it is of help to you during design, discussion, or review. Please note that it's far from complete, and that you often need to make trade-offs between conflicting principles.

The list was inspired by The Principles of Good Programming. I felt that the list closely, but not completely matches what I would personally put into something similar. Additionally, I wanted a bit more reasoning, details, and links to further resources. Let me know if you have any feedback or suggestions for improvement.

Contents

Generic

Inter-Module/Class

Module/Class

KISS

Most systems work best if they are kept simple rather than made complex.

Why

  • Less code takes less time to write, has less bugs, and is easier to modify.
  • Simplicity is the ultimate sophistication.
  • It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away.

Resources

YAGNI

YAGNI stands for "you aren't gonna need it": don't implement something until it is necessary.

Why

  • Any work that's only used for a feature that's needed tomorrow, means losing effort from features that need to be done for the current iteration.
  • It leads to code bloat; the software becomes larger and more complicated.

How

  • Always implement things when you actually need them, never when you just foresee that you need them.

Resources

Do The Simplest Thing That Could Possibly Work

Why

  • Real progress against the real problem is maximized if we just work on what the problem really is.

How

  • Ask yourself: "What is the simplest thing that could possibly work?"

Resources

Keep things DRY

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Each significant piece of functionality in a program should be implemented in just one place in the source code. Where similar functions are carried out by distinct pieces of code, it is generally beneficial to combine them into one by abstracting out the varying parts.

Why

  • Duplication (inadvertent or purposeful duplication) can lead to maintenance nightmares, poor factoring, and logical contradictions.
  • A modification of any single element of a system does not require a change in other logically unrelated elements.
  • Additionally, elements that are logically related all change predictably and uniformly, and are thus kept in sync.

How

  • Put business rules, long expressions, if statements, math formulas, metadata, etc. in only one place.
  • Identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc).
  • Apply the Rule of three.

Resources

Related

Code For The Maintainer

Why

  • Maintenance is by far the most expensive phase of any project.

How

  • Be the maintainer.
  • Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.
  • Always code and comment in such a way that if someone a few notches junior picks up the code, they will take pleasure in reading and learning from it.
  • Don't make me think.
  • Use the Principle of Least Astonishment.

Resources

Avoid Premature Optimization

Quoting Donald Knuth:

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

Understanding what is and isn’t "premature" is critical of course.

Why

  • It is unknown upfront where the bottlenecks will be.
  • After optimization, it might be harder to read and thus maintain.

How

Resources

Minimise Coupling

Coupling between modules/components is their degree of mutual interdependence; lower coupling is better. In other words, coupling is the probability that code unit "B" will "break" after an unknown change to code unit "A".

Why

  • A change in one module usually forces a ripple effect of changes in other modules.
  • Assembly of modules might require more effort and/or time due to the increased inter-module dependency.
  • A particular module might be harder to reuse and/or test because dependent modules must be included.
  • Developers might be afraid to change code because they aren't sure what might be affected.

How

  • Eliminate, minimise, and reduce complexity of necessary relationships.
  • By hiding implementation details, coupling is reduced.
  • Apply the Law of Demeter.

Resources

Law of Demeter

Don't talk to strangers.

Why

  • It usually tightens coupling
  • It might reveal too much implementation details

How

A method of an object may only call methods of:

  1. The object itself.
  2. An argument of the method.
  3. Any object created within the method.
  4. Any direct properties/fields of the object.

Resources

Composition Over Inheritance

Why

  • Less coupling between classes.
  • Using inheritance, subclasses easily make assumptions, and break LSP.

How

  • Test for LSP (substitutability) to decide when to inherit.
  • Compose when there is a "has a" (or "uses a") relationship, inherit when "is a".

Resources

Orthogonality

The basic idea of orthogonality is that things that are not related conceptually should not be related in the system.

Source: Be Orthogonal

It is associated with simplicity; the more orthogonal the design, the fewer exceptions. This makes it easier to learn, read and write programs in a programming language. The meaning of an orthogonal feature is independent of context; the key parameters are symmetry and consistency.

Source: Orthogonality

Maximise Cohesion

Cohesion of a single module/component is the degree to which its responsibilities form a meaningful unit; higher cohesion is better.

Why

  • Increased difficulty in understanding modules.
  • Increased difficulty in maintaining a system, because logical changes in the domain affect multiple modules, and because changes in one module require changes in related modules.
  • Increased difficulty in reusing a module because most applications won’t need the random set of operations provided by a module.

How

  • Group related functionalities sharing a single responsibility (e.g. in a class).

Resources

Liskov Substitution Principle

The LSP is all about expected behavior of objects:

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

Resources

Open/Closed Principle

Software entities (e.g. classes) should be open for extension, but closed for modification. I.e. such an entity can allow its behavior to be modified without altering its source code.

Why

  • Improve maintainability and stability by minimizing changes to existing code.

How

  • Write classes that can be extended (as opposed to classes that can be modified).
  • Expose only the moving parts that need to change, hide everything else.

Resources

Single Responsibility Principle

A class should never have more than one reason to change.

Long version: Every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. Responsibility can be defined as a reason to change, so a class or module should have one, and only one, reason to change.

Why

  • Maintainability: changes should be necessary only in one module or class.

How

Resources

Hide Implementation Details

A software module hides information (i.e. implementation details) by providing an interface, and not leak any unnecessary information.

Why

  • When the implementation changes, the interface clients are using does not have to change.

How

  • Minimize accessibility of classes and members.
  • Don’t expose member data in public.
  • Avoid putting private implementation details into a class’s interface.
  • Decrease coupling to hide more implementation details.

Resources

Curly's Law

Curly's Law is about choosing a single, clearly defined goal for any particular bit of code: Do One Thing.

Interface Segregation

Reduce fat interfaces into many client specific interfaces. An interfaces should be more dependent on the code that calls it than the code that implements it.

Why

  • If a class implements methods that are not needed the caller needs to know about the method implementation of that class. For example if a class implements a method but simply throws then the caller will need to know that this method shouldnt actually be called

How

About

Categorized overview of Programming Principles & Patterns

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Ruby 100.0%