What is the first rule of programming

The 10 golden rules of programming

Since I'm still at the PHP conference in Berlin, we are lucky enough to be able to present a guest article again today. Stephan Elter was creative and put together his 10 golden rules of programming. So, as always, clear the stage:

Most developers have them in one form or another, but each of them probably looks a little different: The 10 Golden Rules of Programming.

1. Use an IDE

Programming is not a duel in the wild west, the winner is not the one whose editor started faster.
With increasing complexity and increasing requirements, you are grateful for any help: Refactoring, error reporting, code completion, structure views - only under time pressure and beyond 1000 lines of code do you begin to understand why a development environment really makes sense.

2. Use OOP

Always build your program object-oriented. The number of errors and the shorter troubleshooting time will thank you. And reusable code really does exist!

3. OOP is not the reality.

... and no picture of it either. And nobody can claim that the processes and procedures in reality are actually beneficial.
At least be arrogant enough to believe you can do better than reality.

4. Don't be afraid of functions

Always use classes and objects when it makes sense - but don't be afraid to use normal functions or develop parts procedurally if it makes sense. PHP is not small talk, you can do it.

5. Don't change any variables, ever

There is still space in the main memory for another variable.
When you have read out or generated a value, keep it in its original form. Do you have to modify it take a new variable - you never know when you will need the value in its original form again or how quickly you will have forgotten a modification and then look for the error or have to "reverse" the value elsewhere.

6. Primitive or ingeniously simple?

Write your code so simply that you can not only read it, but also understand it and maybe even wait.
A few saved lines, two or three conditions merged, make one out of three IFs? The next troubleshooting is already waiting for you - or the colleague who is allowed to wait for your compressed, unreadable code.

7. Do not leave any construction sites open (“broken window”)

There is hardly anything more difficult, so do it anyway: Fix bugs right away.

8. Optimize the design - not the code

No code can cost more time than unnecessary database queries, nonsensical runs or cumbersome processes. Code optimizations, on the other hand, are like the dark side of power - they're fast, seductive! But they only bring immeasurable suffering in the form of new bugs or poor maintainability.

9. Trust the compiler

He is fast, he is your friend and he takes care of the necessary optimizations. What it can't do, a faster processor or cache engine can do!

10. Know your language

You can only really do without optimizations if you know your language and can deal with its strengths and weaknesses.

11. No golden rules

No way!

If you want to deal a little more seriously with this topic, the following books are recommended:
"Code Craft" by Pete Goodlife
"The Mythical Man-Month" by F. P. Brooks, Jr.
"The Pragmatic Programmer" by Andrew Hunt and David Thomas

What are your rules? Do such rules make sense or are they just nice joke?