I am compiling a rules of programming mindset for

Question

I have been working on a list for a while that helps me share the why of programming approach and thought as much as how to do something.

For this, I wanted to build a list of things that are:

• best practice,
• best thought,
• best approach...

that help a programmer's ability to analyze, think, approach, solve and implement in the most effective way.

I have seen dozens of incredibly valuable comments in questions throughout Stack Overflow, but I couldn't find a place where we keep them together. There is the most controversial opinion on Stack Overflow. However, I'm just looking for sagely insights that can be shared and help my team, and I approach and solve problems better through better programming.

Hopefully this can be one place to gather the one or two liners that are concise, profound and easy to share, repeat, review. If we keep it to one rule per answer it might be easiest to vote up/down.

I'll start with the first.

DRY - Don't Repeat Yourself - In code, comments or documentation.

Answer 1

KISS - Keep it simple, stupid.
Pick the simplest solution that works.
Don't make things (too) complicated before they need to be.
Just because everyone else is using some complicated framework to solve their problem, doesn't mean you have to.

Answer 2

Understand the tools you use

Don't use a pattern until you've understood why you're using it; don't use a tool without knowing why; don't rely on your framework or language designer always being right for your situation, but also don't assume they're wrong until proven to be!

Answer 3

Don't reinvent the wheel

If there ought to be a function for it in the core library - there probably is.

Answer 4

Take part in open source development

If you are using open source code in your projects, remember to post your bugfixes and improvements back to the community. It's not a development best practice per se, but it's definitely a programmer mindset to strive for.

Answer 5

Habits of the lazy coder

The first time you are asked to do something, do it (right).

The second time you are asked to do it, make a tool that does it automatically.

And the third time, if the tool doesn't cut it, design a domain specific language for generating more tools.

(not to be taken too seriously)

Answer 6

Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

From: Coding Horror