Subject: Rules for bad programmers Wed Mar 22, 2023 9:12 am
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.
Last edited by Henk on Mon Oct 23, 2023 12:35 pm; edited 1 time in total
TheSelfImprover
Posts : 3079 Join date : 2020-11-18
Subject: Re: Rules for bad programmers Sat Aug 26, 2023 7:14 pm
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.
Henk
Posts : 1357 Join date : 2020-11-17
Subject: Re: Rules for bad programmers Tue Sep 26, 2023 1:31 pm
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.
Henk
Posts : 1357 Join date : 2020-11-17
Subject: Re: Rules for bad programmers Thu Sep 28, 2023 10:41 am
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.
Henk
Posts : 1357 Join date : 2020-11-17
Subject: Re: Rules for bad programmers Mon Oct 09, 2023 4:47 pm
No nesting. Already a sign you did not create short methods. If you can't make changes easily there is something wrong.
Henk
Posts : 1357 Join date : 2020-11-17
Subject: Re: Rules for bad programmers Mon Oct 23, 2023 12:26 pm
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.
Henk
Posts : 1357 Join date : 2020-11-17
Subject: Re: Rules for bad programmers Tue Oct 24, 2023 4:17 pm
Always verify. Each character you type might be a mistake.
Henk
Posts : 1357 Join date : 2020-11-17
Subject: Re: Rules for bad programmers Wed Oct 25, 2023 1:29 pm
Each method should compute one result.
Henk
Posts : 1357 Join date : 2020-11-17
Subject: Re: Rules for bad programmers Fri Nov 10, 2023 12:26 pm
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.
Henk
Posts : 1357 Join date : 2020-11-17
Subject: Re: Rules for bad programmers Fri Nov 10, 2023 2:11 pm
Always reserve time for refactoring. Making it work is far not enough.
Remember keep everything local, private as much as possible.
Henk
Posts : 1357 Join date : 2020-11-17
Subject: Re: Rules for bad programmers Wed Dec 13, 2023 2:30 pm
Always keep the system dead unless the system is more important than your health. Or better disable the feature you are working on.
Henk
Posts : 1357 Join date : 2020-11-17
Subject: Re: Rules for bad programmers Tue Dec 19, 2023 2:12 pm
Always declare local variables at start of method definition otherwise debugger may not display their values
TheSelfImprover
Posts : 3079 Join date : 2020-11-18
Subject: Re: Rules for bad programmers Tue Dec 19, 2023 7:32 pm
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 ({}).
Henk
Posts : 1357 Join date : 2020-11-17
Subject: Re: Rules for bad programmers Tue Dec 19, 2023 8:25 pm
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.
TheSelfImprover
Posts : 3079 Join date : 2020-11-18
Subject: Re: Rules for bad programmers Tue Dec 19, 2023 9:20 pm
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.
Henk
Posts : 1357 Join date : 2020-11-17
Subject: Re: Rules for bad programmers Fri Dec 22, 2023 12:46 pm
Avoid assignments. Especially to arguments of a method. Why not do functional programming?
Henk
Posts : 1357 Join date : 2020-11-17
Subject: Re: Rules for bad programmers Tue Dec 26, 2023 1:21 pm
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.
TheSelfImprover
Posts : 3079 Join date : 2020-11-18
Subject: Re: Rules for bad programmers Tue Dec 26, 2023 4:10 pm
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
Posts : 1357 Join date : 2020-11-17
Subject: Re: Rules for bad programmers Thu Jan 04, 2024 1:58 pm
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.
TheSelfImprover likes this post
Henk
Posts : 1357 Join date : 2020-11-17
Subject: Re: Rules for bad programmers Sat Aug 24, 2024 9:15 am
Henk wrote:
Avoid assignments. Especially to arguments of a method. Why not do functional programming?
Devil made me do it. I did many unnecessary assignments to a class. Or bad object oriented programming.
Had much trouble with debugging. Now I have to rewrite. Talking about wasting time.
By the way I still don't understand monads. What is it. Storing or hiding the side effect of a method in an object??
Henk
Posts : 1357 Join date : 2020-11-17
Subject: Re: Rules for bad programmers Sat Aug 24, 2024 10:28 am
Make everything private unless there is a good reason to make it public.
TheSelfImprover
Posts : 3079 Join date : 2020-11-18
Subject: Re: Rules for bad programmers Sat Aug 24, 2024 12:46 pm
Henk wrote:
By the way I still don't understand monads. What is it. Storing or hiding the side effect of a method in an object??
Monads are essential in functional languages: they enable flows of tasks to work better.
C# does have monadic binding: take the following data relationship.
Parent can have multiple children. Child can have multiple toys.
You want a list of toys where the parents are older than 30. In C#, the monadic binding "SelectMany" makes this easy:
Of course, you can get the same list of toys without using the "SelectMany" monadic binding - but it's not so easy, not so intuitive, and hence more likely to be error prone and more difficult to maintain.