Rules for bad programmers

Simplify:
- Remove as many parameters as possible
- Remove as many properties from a class as possible


Use as many immutable datatypes as possible. Efficiency is only for good programmers. Not for bad programmers.
Only use simple names for you are lazy and you always make typing errors.

Create only short methods for you are too stupid to understand long methods. Not to talk about making changes in long methods.
Make conditional expressions as short as possible for you hardly ever understand them or they give you unexpected results.

One strong trend I'm seeing in young devs that enables me to run rings around them when there's a halfway complex process to develop: they're too lazy to write classes.

They'll write any amount of awkward code that's difficult to understand, maintain, and even get right in the first place in preference to writing a class.

This situation should be the other way around: in some cases, object oriented programming didn't exist in mainstream development when I was their age.

Also one return statement per method because you were so stupid to create long methods so you probably overlook a return. So best to have one return to avoid that.

Better to write code with bugs than code which is (too) difficult to debug.
Because code which is easy to debug can be debugged.


Code which is too difficult to debug should be eliminated or replaced as quickly as possible.

No nesting. Already a sign you did not create short methods. If you can't make changes easily there is something wrong.

Don't use exceptions. For you are too stupid to understand them. In the eighties they did not use them much so why should you.

Always repeat yourself for your memory is terrible.

Always verify. Each character you type might be a mistake.

Each method should compute one result.

Create as many static methods as possible. No need to study the whole class to find out what a method is doing or what it is dependent on. By the way avoid creating unnecessary objects. Nobody is going to re-use your stupid classes in the future.

Always reserve time for refactoring. Making it work is far not enough.

Remember keep everything local, private as much as possible.

Always keep the system dead unless the system is more important than your health.
Or better disable the feature you are working on.

Always declare local variables at start of method definition otherwise debugger may not display their values

Henk wrote:

Always declare local variables at start of method definition otherwise debugger may not display their values

It's a good idea to declare them before usage (rather than using them inline, undeclared), but they only need to be in scope - they don't need to be at the start of the method.

Scope could, for example, be an arm of an "if" statement, or anything inside a pair of double braces ({}).

TheSelfImprover wrote:

Henk wrote:

Always declare local variables at start of method definition otherwise debugger may not display their values

It's a good idea to declare them before usage (rather than using them inline, undeclared), but they only need to be in scope - they don't need to be at the start of the method.

Scope could, for example, be an arm of an "if" statement, or anything inside a pair of double braces ({}).

When out of scope and you put the debugger at the end of the method you can't find out how the result got the wrong value for these variables are now out of scope.

That's exactly how it should be: once a variable is out of scope, it should no longer be possible to access it. If that's not what you want, then yes: put the variable declaration at the start of the method, where it will be in scope for the whole of the method.

Avoid assignments. Especially to arguments of a method. Why not do functional programming?

Add assertions to your code for your assumptions are always wrong. Better write unit tests but you are too lazy for doing that and the interfaces you write always changes.

Henk wrote:

Add assertions to your code for your assumptions are always  wrong. Better write unit tests but you are too lazy for doing that and the interfaces you write always changes.

+1 and I would go further: each time your code does something wrong, add a unit test for that error. If you don't, either you or some other idiot will revert the change that fixed the code to solve another problem!

Christmas cracker jokes for programmers:

1Q. Why was Christmas dinner with Elon Musk awkward?

1A. He kept going on about his X

2Q. Why do devs confuse Halloween with Xmas Day?

2A. Because OCT 31 == DEC 25

Henk wrote:

Also one return statement per method because you were so stupid to create long methods so you probably overlook a return. So best to have one return to avoid that.

In my opinion short methods using multiple returns is more clear/simpel/ less error prone than one return. For instance when you are only interested in the first case you can skip the remaining code.