I am compiling a rules of programming mindset for my team: What are yours? [closed]

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

Always leave the code a little better than when you found it.

Answer 2

Code does not exist until entered into a versioning control system.

Answer 3

Don't be afraid to admit "I don't know" and ask.

10 minutes asking someone could save a day pulling your hair out!

Answer 4

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 5

Don't reinvent the wheel

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

Answer 6

Maintainability is important.

Write code as if the person who will end up maintaining it is crazy and knows where you live.

Answer 7

Someone else won't fix it.

If a problem comes to your attention, take ownership long enough to ensure it will be taken care of one way or another.

Answer 8

Don't optimize unless there's a demonstrable problem.
Most of the time when people try to optimize code before it's been proved necessary, they'll spend a lot of resources, make the code harder to read and maintain, and achieve no noticeable effect. Sometimes they'll even make it worse.

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
- Donald Knuth

Answer 9

How hard can it be?
Don't let any problem intimidate you.

Answer 10

Don't Gather Requirements -- Dig for Them

Requirements rarely lie on the surface. They're buried deep beneath layers of assumptions, misconceptions, and politics

via The Pragmatic Programmer

Answer 11

Follow the SOLID principles:

Single Responsibility Principle (SRP)

There should never be more than one reason for a class to change.

Open-Closed Principle (OCP)

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

Liskov Substitution Principle (LSP)

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

Interface Segregation Principle (ISP)

Clients should not be forced to depend upon interfaces that they do not use.

Dependency Inversion Principle (DIP)

A. High level modules should not depend upon low level modules. Both should depend upon abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.

Answer 12

Best Practice: Use your brain
Don't follow any trend/principle/pattern without thinking about it

Answer 13

I think almost everything that is listed under "The Zen of Python" applies for every "Rules of Programming Mindset" list. Start with 'python -c "import this"':

The Zen of Python, by Tim Peters

• Beautiful is better than ugly.
• Explicit is better than implicit.
• Simple is better than complex.
• Complex is better than complicated.
• Flat is better than nested.
• Sparse is better than dense.
• Readability counts.
• Special cases aren't special enough to break the rules.
• Although practicality beats purity.
• Errors should never pass silently.
• Unless explicitly silenced.
• In the face of ambiguity, refuse the temptation to guess.
• There should be one-- and preferably only one --obvious way to do it.
• Although that way may not be obvious at first unless you're Dutch.
• Now is better than never.
• Although never is often better than right now.
• If the implementation is hard to explain, it's a bad idea.
• If the implementation is easy to explain, it may be a good idea.
• Namespaces are one honking great idea -- let's do more of those!

Answer 14

Test Driven Development (TDD) makes coders sleep better at night

Just to clarify: Some people seem to think TDD is just an incompetent coder's way of limping from A to B without borking everything up too much, and that if you know what you're doing, that means there is no need for (unit) testing methodologies. That completely misses the point of Test Driven Development. TDD is about three (update: apparently four) things:

1. Refactoring magic. Having a full set of tests means you can make otherwise insane refactoring stunts, juggling the entire structure of your application without missing even one of the two hundred crazy subtle side effects that result from it. Even the best programmers are reluctant to refactor their core classes and interfaces without good (unit) test coverage, because it's damn near impossible to track down all the little 'ripple effects' it causes without them.

2. Detecting pitfalls early. If you are writing tests the right way, it means forcing yourself to consider all the fringe cases. Often, this leads to better design choices once the actual development begins, because the coder has already considered some of the trickier situations that may call for a different inheritance structure or a more flexible design pattern. The need for these changes is often not apparent - or intuitive - during initial planning and analysis, but those exact changes can make the application much easier to extend and maintain down the line.

3. Ensuring that tests get written. TDD requires you to write the tests before writing the code. Sure, that can be a pain in the ass, since writing tests is tedious compared to writing actual code - and often takes longer, too. However, doing so is the only way to make sure the tests will be written at all. If you think you'll remember to write the tests once the code is done, you're almost always wrong.

4. Forcing you to write better code. Since TDD forces all code to be testable (you don't write code before there is a test for it), it requires you write more decoupled code so that you can test the components in isolation. So TDD forces you to write better code. (Thanks, Esko)

Answer 15

Google before you ask your colleague and interrupt his coding.

Answer 16

Less code is better than more, as long as it makes more sense than lots of code.

Answer 17

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 18

Be a Catalyst for Change

You can't force change on people. Instead, show them how the future might be and help them participate in creating it.

via The Pragmatic Programmer

Answer 19

Don't Panic When Debugging

Take a deep breath and THINK! about what could be causing the bug.

via The Pragmatic Programmer

Answer 20

You may copy and paste to get it working, but you may not leave it that way.

Duplicated code is an intermediate step, not a final product.

Answer 21

It's Both What You Say and the Way You Say It

There's no point in having great ideas if you don't communicate them effectively.

via The Pragmatic Programmer

Answer 22

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

From: Coding Horror

Answer 23

Build Breaker Buys Lunch

Answer 24

Publish Early, Publish Often

Answer 25

Build it correct first. Make it fast second.

Answer 26

Frequently conduct code reviews

Code review and consequently refactoring is an ongoing task. Here is a few goodies about code review in my opinion:

1. It improves code quality.
2. It helps refactor reusable codes into reusable libraries.
3. It helps you learn from your fellow developers.
4. It helps you learn from your mistakes and refresh your memory about a genius code you have written before.

Answer 27

Anything that could affect how the application runs should be treated as code, and that means putting it in version control. Especially build scripts and database schema and data (.sql) files.

Answer 28

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 29

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 30

Convention over Configuration

Especially where conventions are strong and some flexibility can be sacrificed.