Back to General and Gameplay Programming

Tips on Improving Logical Thinking?

Liuqahs15 · 2013-01-02T09:45:06

I've been programming for a little bit over a year, and have some experience in JavaScript, PHP, a tiny tiny amount of Java, and mostly C++. I've noticed that I've gotten to the point where I can program for, say, a couple of hours without checking to see if it runs, and then when I'm done for the night everything will build just fine. At least in the general case. That's very different from when I first started, and I'd have to click Buld and Run every 10 minutes just to make sure I'm not writing buggy code on top of already buggy code. But now I'm starting to see that even though my code will build fine, there will almost always be some logical errors that, upon review, I say to myself "Why would I even write that? It's a simple mistake, but it makes no sense. I should've known from the start." I'd like to be able to change that about myself, and not make so many silly, illogical errors so that my first run of code on any project will be less buggy and weird. Any suggestions on fun or interesting ways to change this? I've heard of Code Complete, but it's quite expensive. I thought maybe I should learn a bit more about actual computer science before diving into that book. I've never really enjoyed project euler. My mom loves doing things like cryptograms, but I never really had much fun with them. So other than stuff like that, what do you guys do that you think might improve your logical abilities?

General and Gameplay Programming Programming

Started by Liuqahs15 January 01, 2013 05:59 PM

11 comments, last by larspensjo 11 years, 3 months ago

Xai

1,851

January 02, 2013 06:44 AM

A couple of other things to help your mind moving:

Visualize things

- draw pictures, diagrams, scribbles, ... it doesn't matter if its a picture or squares representing memory, with lines for pointers ... or if its a UML diagram of an activity, a flowchart, or just a scribble with 5 circles and some lines representing your logical state machine. Mental and physical visualization can help you think clearly and keep your thoughts focused.

As said before - pause and review

- take the time to think before you code, while you code, and after you code. You can vary the amount and the ratio based on your success and how repetitive your task is: when doing something similar over and over again the up-front thought needed is nearly zero, the coding is fast, so half the time will be in simple review / double-check, when solving a problem you've never even completely understood before, with ramifications you may not yet have noticed, you'll need a lot of up front time, and also a lot of coding time (where half the problem will show up) ... then a CAREFUL review when you think you are done, to identify what you have missed.

Know the difference between what you KNOW (for sure), what you THINK you know, and what you know you DON'T KNOW. As you plan, or read and review code - this distinction guides how much focus you need to bring to the table.

Also - the longer you spend debugging the same issue ... the more likely it is something "stupid" ... which really means, something in an area you are making an assumption about, that for whatever reason is not currently true (like a problem with code you thought was working yesterday).

Decompose ... separate ... divide and conquer.

When solving a problem, break it down into smaller chunks .. but just as important as chunk size or complexity is how SENSIBLE and therefore understandable and memorable a chunk is. 4 chunks for - parsing the file into memory, validating the contents for validity, reconciling the contents against the previous day, and updating the processing statistics - might be easier to code and debug for a really complex algorithm, then for instance something that parses a header and updates statistics, then parses the body, reconciles it and updates statistics, then parses the footer, validates the whole, and saves a copy ... for a simple algorithm Even though the first might have 1000 lines of code and the later 200 ... the brain can only handle so many thoughts at any given time ...

and you can take chunk 1 of the 1000 line idea ... and further break it down ...

which leads to the last suggestion

NAME everything ... CLEARLY ... and name it well. And as your design changes KEEP YOU NAME UP TO DATE. a function "UpdatePlayerPosition" that moves the player, unless it is under AI control, and then if raises an event for the AI which will do the update later in the "HandleAI" function instead - suggests someone grew the design without making sure the names and layers still fit together right. And a function called "ComputeTaxAndUpdateOrder" is in fact better than "ComputeTax" or "UpdateOrder" if in fact it does both things, regardless of what the function USED to do. Taking the time to name things well, means you also take the time to understand them correctly. Which pays huge dividends in reducing the number and severity of stupid errors.

Good luck.

Trienco

2,555

January 02, 2013 06:48 AM

I'm usually doing fairly well with my negative attitude. Don't look at it and think about how it's going to work, try to think of all the things that could go wrong and what will happen if they do. Paint it black, consider worst case scenarios and never be complacent and think "this seems so neat, it just has to be the 'right' solution".

As an alternative, do it by the book. Determine requirements, write tests and start planing and coding the actual code. It's going to cost you a lot of time, but generally writing tests can you let you see lots of issues to keep in mind during development.

f@dzhttp://festini.device-zero.de

larspensjo

1,561

January 02, 2013 09:45 AM

I have been programming for 35 years, and still have the same problems. So I probably will never learn. This is what I do (which depends a little on whether I am working with a free time home project or working with a professional product):

Make small changes, and make sure they always work. If something big is needed, I break it down to small changes.
Switch between open and closed mode. When I am sitting at the keyboard, I am in closed mode, and can usually only implement what I have already decided and planned. I leave the keyboard and go somewhere else to get into open mode. In open mode, I let the brain free to think around. Perfect for me is to go for a run. That is when I come up with the good design ideas. Or sit down in the sofa with a sketch of paper.
Write code as if you are going to show it to a "beginner". When you explain the code to someone, and they say "of course, how else would it be done", then there is a high chance you got it right.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian W. Kernighan
Be prepared to re-factor the source. When you start small, and expand, you inevitably come to a point where you find the original design is no longer easy to maintain or flexible. Get into open mode and find out how to make it look pretty. Still, I usually start with a simple design, because it can be hard in the beginning to know all the requirements.
Source code is like a piece of art. If you feel proud looking at it, there is a higher chance the design is good.
Read a lot on discussion forums. Join them, and express your view. You will either help others, or get feedback and learn new things yourself.
Work both top-down and bottom-up. When you work top-down, use stubs that makes the application possible to compile and run. I find it common, when in top-down mode, that I will have to wait with something while something else is being completed. It is easy to forget to go back and complete that other thing, so I always leave a "TODO" comment in the source code to help myself.
Keep things small. Classes, functions, files, etc. A class declaration (in C++) should fit on one page. A function should fit on one page. Every indentation level used in a function double the probability of bugs for me.

[size=2]Current project: Ephenation.
[size=2]Sharing OpenGL experiences: http://ephenationopengl.blogspot.com/

Tips on Improving Logical Thinking?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Tips on Improving Logical Thinking?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines