ProDeo
Would you like to react to this message? Create an account in a few clicks or log in to continue.
ProDeo

Computer Chess
 
HomeHome  CalendarCalendar  Latest imagesLatest images  FAQFAQ  SearchSearch  MemberlistMemberlist  UsergroupsUsergroups  RegisterRegister  Log in  

Post new topic   Reply to topic
 

 Rules for bad programmers

Go down 
2 posters
AuthorMessage
Henk




Posts : 1271
Join date : 2020-11-17

Rules for bad programmers Empty
PostSubject: Rules for bad programmers   Rules for bad programmers EmptyWed 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
Back to top Go down
TheSelfImprover

TheSelfImprover


Posts : 2965
Join date : 2020-11-18

Rules for bad programmers Empty
PostSubject: Re: Rules for bad programmers   Rules for bad programmers EmptySat 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.
Back to top Go down
Henk




Posts : 1271
Join date : 2020-11-17

Rules for bad programmers Empty
PostSubject: Re: Rules for bad programmers   Rules for bad programmers EmptyTue 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.
Back to top Go down
Henk




Posts : 1271
Join date : 2020-11-17

Rules for bad programmers Empty
PostSubject: Re: Rules for bad programmers   Rules for bad programmers EmptyThu 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.
Back to top Go down
Henk




Posts : 1271
Join date : 2020-11-17

Rules for bad programmers Empty
PostSubject: Re: Rules for bad programmers   Rules for bad programmers EmptyMon 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.
Back to top Go down
Henk




Posts : 1271
Join date : 2020-11-17

Rules for bad programmers Empty
PostSubject: Re: Rules for bad programmers   Rules for bad programmers EmptyMon 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.
Back to top Go down
Henk




Posts : 1271
Join date : 2020-11-17

Rules for bad programmers Empty
PostSubject: Re: Rules for bad programmers   Rules for bad programmers EmptyTue Oct 24, 2023 4:17 pm

Always verify. Each character you type might be a mistake.
Back to top Go down
Henk




Posts : 1271
Join date : 2020-11-17

Rules for bad programmers Empty
PostSubject: Re: Rules for bad programmers   Rules for bad programmers EmptyWed Oct 25, 2023 1:29 pm

Each method should compute one result.
Back to top Go down
Henk




Posts : 1271
Join date : 2020-11-17

Rules for bad programmers Empty
PostSubject: Re: Rules for bad programmers   Rules for bad programmers EmptyFri 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.
Back to top Go down
Henk




Posts : 1271
Join date : 2020-11-17

Rules for bad programmers Empty
PostSubject: Re: Rules for bad programmers   Rules for bad programmers EmptyFri 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.
Back to top Go down
Henk




Posts : 1271
Join date : 2020-11-17

Rules for bad programmers Empty
PostSubject: Re: Rules for bad programmers   Rules for bad programmers EmptyWed 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.
Back to top Go down
Henk




Posts : 1271
Join date : 2020-11-17

Rules for bad programmers Empty
PostSubject: Re: Rules for bad programmers   Rules for bad programmers EmptyTue Dec 19, 2023 2:12 pm

Always declare local variables at start of method definition otherwise debugger may not display their values
Back to top Go down
TheSelfImprover

TheSelfImprover


Posts : 2965
Join date : 2020-11-18

Rules for bad programmers Empty
PostSubject: Re: Rules for bad programmers   Rules for bad programmers EmptyTue 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 ({}).
Back to top Go down
Henk




Posts : 1271
Join date : 2020-11-17

Rules for bad programmers Empty
PostSubject: Re: Rules for bad programmers   Rules for bad programmers EmptyTue 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.
Back to top Go down
TheSelfImprover

TheSelfImprover


Posts : 2965
Join date : 2020-11-18

Rules for bad programmers Empty
PostSubject: Re: Rules for bad programmers   Rules for bad programmers EmptyTue 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.
Back to top Go down
Henk




Posts : 1271
Join date : 2020-11-17

Rules for bad programmers Empty
PostSubject: Re: Rules for bad programmers   Rules for bad programmers EmptyFri Dec 22, 2023 12:46 pm

Avoid assignments. Especially to arguments of a method. Why not do functional programming?
Back to top Go down
Henk




Posts : 1271
Join date : 2020-11-17

Rules for bad programmers Empty
PostSubject: Re: Rules for bad programmers   Rules for bad programmers EmptyTue 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.
Back to top Go down
TheSelfImprover

TheSelfImprover


Posts : 2965
Join date : 2020-11-18

Rules for bad programmers Empty
PostSubject: Re: Rules for bad programmers   Rules for bad programmers EmptyTue 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
Back to top Go down
Henk




Posts : 1271
Join date : 2020-11-17

Rules for bad programmers Empty
PostSubject: Re: Rules for bad programmers   Rules for bad programmers EmptyThu 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

Back to top Go down
Sponsored content





Rules for bad programmers Empty
PostSubject: Re: Rules for bad programmers   Rules for bad programmers Empty

Back to top Go down
 
Rules for bad programmers
Back to top 
Page 1 of 1
 Similar topics
-
» The NNUE split programmers are in
» Why do programmers care only about elo and not about faster mating?
» MuZero: Mastering Go, chess, shogi and Atari without rules

Permissions in this forum:You can reply to topics in this forum
ProDeo :: Programmer Corner-
Post new topic   Reply to topicJump to: