Express Ideas in Code

The computer reads processor’s orders. The code is for other people. Included future you.

Good code is self-documenting.

Still, comment to clarify, and document.

I only know that I know nothing

The code should be simple and logical. Never clever.

Winning a debate on dialectics is not wining, is obfuscating to the point of exhaustion.

See the code as a conversation with a computer. Keep asking questions.

Build Structures, not Armies.

A good gate needs of few guards.

Don’t fear to make a complex structure if it will lessen the load for the working parts.

This means that a good compiler will take a huge load easily, as it can take it’s time to build the program.

Once the program is built, any sacrifice you made to have more simple code will translate into less efficient programs.

If you have to choose, always sacrifice compiling instead of clarity.

You don't control Time, but don't let time control you

You don't control running time. That's up to the processor optimization, and maybe the universe.

Accept that and carry on.

If you have to choose, always sacrifice the apparent "time’s efficiency" instead of clarity.

When lost, go back home.

When in doubt, back to basic.

Computers only know Data and Processes.

Data abstracts knowledge.

Processes undertake actions.

Functions are processes that produce Data.

Everything else is based in this fundamental principles.

A better Cambass Doesn’t make a better artist.

All great artists from the Renaissance sketched their pictures first. They had access to all kinds of fabrics and tints, but they would always start with charcoal and paper.

Try your solution in a simple system first. Then, escalate it.

You don’t need a fancier setup, but a simple one that makes what you need.

Write _ISO Standards

Standard means transportable into more systems. It will also be easier to maintain and improve in the future.

To paraphrase Kant:

Write code as it should become a universal standard.

Functions need a Purpose

Say what should be done, not how.

Write by functionality, not by algorithm. State the algorithm in notes under the definition if that’s relevant.

Type Safety is Extra Safety

Use clear types extensively.

Ideally, a program would be completely statically (compile-time) type safe.

Compile checking > Run-Time checking

You don’t need to handle errors caught at compile time. And makes for a clearer code.

Don’t do at run time what can be done well at compile time.

Run-Time checking > No Checking

What cannot be checked at compile time should be checked at run time.

Leaving hard-to-detect errors in a program is asking for crashes and bad results.

Don’t leak any resources

A leak is colloquially “anything that isn’t cleaned up.” The more important classification is “anything that can no longer be cleaned up.”

Relying on system with guaranteed cleanup such as file closing and memory de-allocation upon process shutdown can simplify code. However, relying on abstractions that implicitly clean up can be as simple, and often safer.

Don’t waste _CPU Time nor _Memory Space

Time and space that you spend well to achieve a goal (e.g., speed of development, resource safety, or simplification of testing) is not wasted.

Subset of Superset

To make good things, build good parts. And connect them well.

Divide and conquer. Your enemy is the code. Divide him.

Stand on the Shoulders of Giants.

Use libraries.

Better yet, use clear, well documented, and well designed libraries.

Be A Colossus

Write so your code can help others stand on your shoulders.

Expect the unexpected

Not all Exceptions are Errors.

“Performance” is not affected by handling Exceptions. Stop using it as an excuse.

Choose meaningful names

One function, one task.

Just give one responsibility to each function. Then, build on top.

“The Single Responsibility Principle (SRP) is a computer programming principle that states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.”

“The SRP states that a class or module should have one, and only one, reason to change.”

Classes and functions should be small and obey the Single Responsibility Principle.

Functions should have no side effects

Specify explicitly in the function contracts.

Power lays not on writing rules, but on being the exception

Encapsulate rule violators. Keep them local. Avoid its leak.

Sometimes, ugly, unsafe, or error-prone techniques are necessary for logical or performance reasons. This doesn’t mean you can’t control them.

Read, listen, comment. 🙈🙉🙊

Comments should tell you What, How, or Why of something.

What : At the library, program, or function level. Functionality.

How: Inside the library, program, or function.

Why: When called.

It would be even better if your code was self explanatory.

Imperative is the How.

List of steps

Declarative is the What.

What we have and what we need.

Play the Ender’s Game 🐝

Kill ALL bugs.

Don’t let them evolve into Features.

Appetite for Destruction 💥

Minimize scope.

Destroy pointers as soon as you are done with them.

Abandon all hope, those who enter here.

Warn all those who may enter a laborious hellish task of what horrors await them.

I find this comment just perfect:

/**

Dear maintainer:

Once you are done trying to 'optimize' this routine,

and have realized what a terrible mistake that was,

please increment the following counter as a warning

to the next guy:

total_hours_wasted_here = 42

**/

The Only Valid measurement of code quality is WTF/minute

<2 WTFs/minute ⇒ Good Code

>5 WTFs/minute ⇒ Bad Code

>10 WTFs/minute ⇒ Restart

>20 WTFs/minute ⇒ Fire that guy

dude, WTF ⇒ +3

WTF is this sh!t ⇒ *2

If it isn’t tested, it’s broken

Control your Quality

No side effects

Don’t touch what you shouldn’t be touching.

What are you Optimizing For?

What are people around you optimizing for?

Understand what is the customer needs.

Don't Repeat Yourself

If you have to do it more than twice, a computer should do it for you.

Many Eyes make any bug shallow

This is known as the Linus’ Law.