I am compiling a Rules of Programming Mindset for my team: What are yours?

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

1 Dangerous, without unit tests! – Steven A. Lowe Feb 9 '09 at 4:30.

Code does not exist until entered into a versioning system.

Don't be afraid to admit "I don't know" and ask. 10 minutes asking someone could save a day pulling your hair out!

Don't reinvent the wheel If there ought to be a function for it in the core library - there probably is.

1 And if it's not in the . NET Framework, there's probably something you can download (MVC, AJAX, etc. ) – Richard Gadsden Feb 5 '09 at 12:33.

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.

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

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.

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.

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.

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.Gh 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.

5 I wonder why they didn't call it SRPOCPLSPISPDIP principles... – Torsten Marek Feb 5 '09 at 1:23.

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

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: 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. 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.

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. 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).

Google before you ask your colleague and interrupt his coding.

2 +1- I have a similar rule, if I can google an answer or approach in 30 seconds it means you have to learn to search as well as I do. – Jas Panesar Feb 6 '09 at 19:17.

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

1 But nearly no code is not always the best answer (ie if there's a function that nearly does what you want, it's not always best to work around the one flaw) – Richard Gadsden Feb 5 '09 at 12:37.

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!

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).

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.

Don't Panic When Debugging Take a deep breath and THINK! About what could be causing the bug. Via The Pragmatic Programmer.

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.

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.

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

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 felow developers. 4.

It helps you learn from your mistakes and refresh your memory about a genious code you have written before.

Build it correct first Make it fast second.

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.

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.

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

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!

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.