programmer-problems

corollarium:

Pesky bugs. How I smack them:

1. Code review. After writing anything I check it myself (don’t waste someone else’s eyes before you reviewed the code yourself). This catches most typos (things like = for ==, variables with typos in interpreted languages, etc). I also simulate code in my head, which makes sure simple logic errors that may have been made are caught early, before even running anything.
2. Plenty of logs. I start any project by having a good Log class, with multiple log levels with filtering, information about the line and file that called the log, sometimes even automatic backtracing in cause of errors (in Python I automatically fall into a . I usually can get a pretty good idea of what went wrong just by checking these logs. Many times adding a few extra log() calls with detailed information about variables is quicker and simpler than using a debugger. And in some cases (websites, for example) setting up a debugger is not trivial, so this has to solve the problem.
3. Tests. This is 2a), in fact, because you can only test properly if you have a test suite. I’ll write someday about how I write test suites, but the basic needs are universal:
   1. tests should be as simple as possible;
   2. should cover all of the code;
   3. should be completely automatic when viable (3D graphic applications are not that easy to write automatic tests, however);
   4. and should test for both the “good cases” and the “bad cases”.
4. If things are looking complicated and logs did not help enough, call that faithful debugger. These days my use of debuggers is quite simple: I often set breakpoints in the code itself (debugger for javascript, raise(SIGINT) for C/C++ and gdb), since it’s usually faster than navigating through the code in the debugger if I know where I want to stop. When the breakpoint is hit, I print all variables to check if their values are correct, and if necessary I step through a few calls.
5. Stack traces are your friends. In C/C++ I let the program run until it crashes, run a backtrace (bt) and start to move up in the call stack until I get to the culprit — usually it is pretty obvious.
6. In JavaScript and Python you can fall into an interactive terminal when the debugger stops that is just as good as the real program: so you can pretty much type any code there, which is run instantly. Then you see immediately if it fixes the code. I’ve come to love this: interactive programming can be extremely useful (great for testing complicated selectors in javascript, for example!). gdb can do some of that, but has several limitations due to C++ being compiled. But use STL support at least for decent printing of STL structures.
7. After the bug is fixed, make sure it becomes a test in your suite!

alexwpratt:

90% of computer science TAs are the same.  They hear your problem.  They smirk.  They lean back and release a hearty laugh.  They say big words to make sure you understand how stupid and ignorant you are.  They speak loudly to make sure the whole room know you’re dumb and they are the most intelligent, attractive, and perfect specimen to walk the Earth.  They grab your keyboard, kick you out of your chair, and fix the problem, pulling a few lean-and-demean looks along the way.

Then they run the program.  

Seg fault.

What was that you were saying earlier??

lol, gpoy my freshman year.

I usually just ask one of the compsci bros in my class who’ve been programming long before uni. They’re the best. XD;

neonspandex:

MOST BADASS BLOG EVER.

i wish it were a tumblr; i’d follow the shit out of it.

lmfao, same here! XD

cjbrowne:

programmer-problems:

Hi, guys. :D
I just found an interesting simulation program IBM made. It’s a free simulator that teaches you how to program a robot and simulate it to battle robots made by other people!

Here’s the link: http://www.ibm.com/developerworks/java/library/j-robocode/

Learning to code with fun…

Those screenshots are really, really old.  Better to go straight to the sourceforge site: http://robocode.sourceforge.net/

There’s also a wiki to help newbie robocoders find their feet: http://robowiki.net/

It now supports eclipse and netbeans integration too, by the way, there are articles on the wiki about it; it’s much easier to use eclipse/netbeans than their built-in “IDE”.

But yeah, this thing is awesome.  Bloody difficult to get anything worthwhile to happen though, so probably not as great an introduction to Java as it first seems.  Mind you, I am the sort of person who always starts on “hard mode” and therefore I wrote my first AdvancedRobot before I’d touched the BasicRobot class (still haven’t touched that class) - I eventually got it Wave Surfing and Pattern Matching but my implementations of those were so terrible that it was hardly worth it.

Anyway, if anyone has any questions for an intermediate robocoder, my ask is always open :)