Subscribe to 10 GOTO 10        RSS Feed
****- 3 Votes

Advice For Programmers (2010)

Icon 12 Comments
Advice For Programmers (2010)

[inspired by this thread]

I have been programming for over 15 years, and I am nearly completely self taught. It has been a long road and there have been many frustrating nights spent agonizing over compiler errors or twists in logic I just could not quite figure out. Programming (especially in C/C++) takes a certain amount of patience and clarity.

I offer some advice on how to proceed:

#1 Software is developed in steps. You don't sit down and write 200 lines of code without ever compiling... you work in steps and compile often. I generally don't add more than about 20-30 lines of code before I run things by the compiler. Note that the code may not be ready to RUN at this point, but it should get past the compiler. When I finish a function I compile, when I complete a logical block I compile. I compile OFTEN -- it helps avoid the onslaught of cryptic compiler errors.

#2 Adopt a Clean Consistent Style -- your should find a style of code that you are comfortable with so that your eyes can readily scan over you logic. Two big points are indention and bracket styles because these are the two big eye cues for structure. Variable/Function/Type names should be done in a consistent style such as camelCase. Good code flows as the eye scans it.

#3 Comment -- but not too much. I find that if put comments every other line etc. the code is hard to read and harder to scan with the eye. This heavy commenting might be ok for someone who is studying the code line for line, but it is not good for the programmer quickly looking for errors. MOST error are syntax or structural not logical. You SHOULD be knocking out 90% of those errors in a couple of seconds each!!! The remaining 10% are trickier and will require you to evaluate the syntax/structure of your program. A ton of comments will just get in the way.

#4 Prefer End Of Line comments to block comments. That is use //this kind over /* this kind */, why? Because when you are troubleshooting you will often want to comment out sections of code (most IDE's have a button for this) -- the block comments can get in the way of this.

#5 Comments can be a troubleshooting tool. -- Often compiler errors are caused by code OTHER than the line pointed to by the compiler. So often it helps to judiciously comment out sections of code to see if the error goes away or to see if the error changes. So if the compiler gives and error on line 99 but line 99 looks correct to you, then try commenting it out and see if/how the error changes. Try commenting out the section above Line 99 to see if the error was in there... etc. This works best of course if you have been programming in baby steps so you have and idea of what changed since the last time it compiled correctly.

#6 Use print statements/beeps/message boxes as a debugging tool. Sometimes you just need to a hint to find the bug. Often that hint comes from testing your assumptions. For example the if(a = c) { } kind of bug is often revealed by testing your assumption of weather that block executes or not. (Note assertions are another good way of testing assumptions.)

#7 Craftsmanship! If I need to write a function to preform a mathematical calculation that goes into some big fancy OpenGL program with 100's of classes and 1000's of lines of code, I generally write the function first in a small command line program -- WHY? Because I want to get a prototype working before I try to plug it into the big messy application. This allows me to test more rigorously on how the function is supposed to work without having to deal with all of the code at once. So try to craft pieces of your code in a manageable environment BEFORE you try and integrate it with a large project.

#8 Design! It can be very hard to know exactly how to craft a program (which parts need to be done first etc.) -- so often it is best to start out on paper. Now don't go thinking you need to plan out the whole thing (though the more you do the better), even just sketching out some basic block diagrams, a sketch of the user interface, a few UML-ish class diagrams outlining main data elements... i.e. even a few quick notes to orient yourself to your task are better than trying to shoot from the hip.

#9 Testing! QA -- if you write a function, test it. If you write a class, test it. Just because it works in the exact situation you designed it for, does not mean that it does what it is supposed to! Very often I fall into the trap myself of thinking, "well the program worked on my machine... so it should work" -- only to have some dumb bug come up when someone else tries to use it.

#10 Prefer full general functions to specific ones -- Try to make your functions abstract enough so that they can be reused in similar situations. This means keeping input/output out of general logic (i.e. a function like convertDeg2Rad() function should not prompt the user "please enter angle in degrees: " -- but take in a parameter called "degrees" and return a value for radians). This means avoiding "magic" numbers (values just placed into the code with no explanation of why they are there or what they are for) -- if changing the value changes the what the function does, then it should be a parameter or a named constant. So for example Array bounds and what not should not hard coded. Other values like multiplying by 2 are ok if there is a clear logic to why they are there or what they are for.

#11 Prefer Full Class implementations to targeted ones -- Try to make a class logically consistent with the object it is modeling (even if you don't need all of the functionality for this program). That is, your Savings Account Manager program may never need to Withdraw money from the account... BUT since that is a common behavior with a Bank Account including that function will be FAR better than leaving it out. Again remember that you may wish to reuse this code, or you may wish to expand your program farther. So a class should be designed to what it models not what functionality the program needs.

#12 Code is meant to be read as well as executed -- Think of your code as telling a story. You should be able to "read" your code. So avoid constructs that obfuscate logic such as deep nesting or large code blocks that deviate from the the stated purpose of the function (chances are these blocks should be made into named functions themselves). Use descriptive variable names. Use names consistently (for example I generally use i, j, k for loop iterators, an x,and y for coordinates -- I DON'T use i for "interest", because when I see 'i' I look for a loop, or if I need a loop I am inclined to auto-type for(int i =... and forget that the name 'i' is already in use).

#13 Backup/Use version control/Use a scratch pad/SaveAs -- I can not tell you how many times I have taken working code and broke it! Many of the modern IDEs do auto versioning or allow you to undo revisions and there is a REASON. We all make mistakes. More than that, it is often nice to have a history of how a program has evolved. For example I have tons of programs with naming schemes like: mandelbrot1.cpp, mandelbrot2.cpp, mandelbrot3.cpp -- each one is different yet the series shows a growth in my understanding of the program.

#14 Code Review -- if you are on a team this is outstanding! Walk though the code with your team members. If you are on your own, stop every once in a while and mime walking though the code by writing documentation or taking notes (or ask some people on DIC or a friend to look over the code with you). When you look at your code you see it though YOUR logic. I find that my logic is often flawed ever so slightly (like I didn't see certain conditions that might readily exist).

#15 DON'T be afraid of mistakes!! Learn from them! -- I have embarrassed myself 100's of times on this forum. I have had Jr. Programmers point out my dumb mistakes in big code reviews. I have caused massive data loss, I have written 100s of lines of code just to discover a function that could do it in 1, I have written incredibly slow code that could have executed FAR faster, I have made LOTS of mistakes! These things have taught me more than all of the flashes of insight or ingenious solutions, all of the books, all of the sage advice from gurus... Mistakes happen - what you do with them is what defines their meaning and importance.

#16 Be Interested. Browse Blogs/Books/Snippets/Tutorials -- try things out, more than that, try to make them your own, that is try to use ideas you pick up to do MORE than what the original author did. I know that I learn a TON from osmosis just from hanging around this forum. I have 4-5 note books with just little snippets or outlines of code that I found in the library, I have megabytes of code snippets from stuff I have played with from the web. One of the MOST important skills in programming is the ability to do research.

#17 Do Programming! Write programs. Not just big project, do little one offs to. Programming is all about experience. Half the time I can't really tell you *why* I approach a problem the way that I did, it is just that intuition steered me. You only gain intuition though experience. Do "classic assignments" even if they seems easy, for example write some of those irritating little "draw a shape using loops" -- challenge yourself to do it in different ways.

#18 Keep it simple -- Strive for simplicity. Now there are levels of abstraction and so what is simple to a Perl programmer may leave the rest of us cross-eyed but once we learn about perl there comes a point when it *clicks* and we see the simplicity. You should always strive for simplicity because bugs hide in complexity. Abstraction is often a way to achieve simplicity even when there are complex tasks. For example if you look at the main loop in most games it is only a few lines of code... yet it runs the whole game. If you find yourself writing a function with more than 100 or so lines, or a class declaration with more than 100 or so lines (or a class with more than 5-600 lines) then you are probably doing things wrong... or at least complicating something that could be simpler.

#19 Step Away. Agonizing over a problem tends to lead to circular thinking or random stabs in the dark. When you find yourself running though the same thoughts, or just trying different things in frustration -- STOP... take a breath, take a short break, try to just *think* about it for a bit, solidify the nature of your problem in your mind and then just walk away from it for a while, when you get back, work on something else for a while. Often you will find that either the answer comes to you while you are doing something else, or it just falls out when you return the problem. Do not underestimate the power of your subconscious to solve problems. The hardest problems I have ever faced have all been solved in my sleep causing me to jump out of bed and rush to the computer.

#20 Be passionate. For many programmers programming is a job, they do it from 9 to 5 and don't really think about it outside of that. For others programming is a business and they put in the long hours and reinvest their dollars and could care less what it is they actually do -- if that is the kind of programmer you want to be, then go ask them for advice. For me programming is part of who I am. It is a compulsion as much as it is a job or a hobby or a pastime or a fascination. When my programs are sub-par it hurts. When my programs preform properly it is exciting and gives me a boost in self-esteem. When I am face with a frustrating problem I get worked up and angry and sometimes depressed -- when I solve the problem (and I always do... might take a while) it a fantastic high. My point is that I relish the challenges I face and take pride in the things I accomplish. I love to talk to other programmers who are also passionate. I love what I do. If I didn't, I would not do it because programming is not an easy thing...

To liberally paraphrase John F. Kennedy: We do these things not because they are easy, but because they are hard.

12 Comments On This Entry

Page 1 of 1


08 June 2010 - 06:30 PM
Some very nice pointers, appreciate your advice NickDMax. Keep up the good work!



08 June 2010 - 09:18 PM
#15 made me feel better. One of my coder friends is always shoving me down, but I guess if your spending more time fighting your ego than learning to code, you won't go very far...

Anyways, awesome post NickDMax. Thanks!


09 June 2010 - 07:46 AM
Hello NickDMax!

Every new programmer should read what you wrote!

Following your advice would save all programmers a lot of grief.

I especially liked, "#20 Be passionate." I think the secret to success and happiness is finding and following whatever arouses your passion. If you do not feel a passion for what you are doing, you should try something else, and keep trying different things until you eventually find your passion.


09 June 2010 - 11:05 AM
Great stuff and well written. I do believe #4 is a bit of style preference rather solid development tip because I have used both successfully in different situations. But comments are always the most bickered about style topic out there so I am not going to fret.

The rest of the tips, solid! Many of these I try to preach myself when giving advice. Good to see that most of them are written down for others to read. :^:


09 June 2010 - 11:42 AM
@Martyr -- well it is "advice" and one can take from it what they want. The reason I said to prefer one over the other, rather than use one over the other is just because my experience is that the block comments tend to cause troubles since they "don't play well with others" -- I don't have a problem with block comment's themselves. There are many documentation systems like Doxygen that make excellent use of block comments!

Note that it was not my intent to really advocate one "style" of commenting over another -- but to avoid needless aggravation when using following the advice in #5. Its just one of those things I picked up - I hate it when I have block comments that I have to edit just so I can comment out a large section of a source file.

And this is all just "advice" -- some people can write 100's of lines of code and never make a typo (I guess), others might be so afraid of making mistakes that they just don't do it. These are not "rules" -- anyone can feel free to ignore them anytime they want (heck I do). :)


09 June 2010 - 12:04 PM
Muy bueno. Me gusta mucho. Donde estan mis pantalones? XD


09 June 2010 - 12:17 PM
@athlon32 -- reading over #15 I wonder if I was a little too general. There ARE mistakes that one should really be ashamed of but not many of those happen while learning to program. When you are a professional programmer though you need to be a little more afraid of mistakes. For example a mistake in a traffic light control system, or a rocket launch control system, or even a regulator routine on some industrial machinery can result in loss of life. These "mistakes" are more than likely inexcusable errors. So while learning feel free to make all the mistakes you want so long as you are learning from them and learning how to avoid making similar mistakes in the future. Please don't think I am a advocating casual view of rushed, sloppy, or insufficiently tested coding in a professional setting. I *was* very embarrassed in that code review mentioned -- but it DID help me ensure that I had a more standardized testing and QA system in place.

But you make a good point about fighting your ego: We are all human and we all err. Part of being a responsible professional (in whatever you do) is taking steps to ensure that human error does not escalate. That means learning from your mistakes.


09 June 2010 - 12:19 PM
Tus pantalones están donde las dejó. ¿Dónde estuviste anoche?


10 June 2010 - 10:10 AM
Lol! <3 No se!


10 June 2010 - 11:42 AM
good stuff. Thanks for sharing. Opened my eyes and gave me ideas for a couple of those.


10 June 2010 - 05:28 PM
This is a great read! Thanks a lot Nick!


09 July 2010 - 09:42 AM
Superb efforts, thanks :bigsmile:
Page 1 of 1

May 2020

24 25 2627282930

Recent Entries

Search My Blog

0 user(s) viewing

0 Guests
0 member(s)
0 anonymous member(s)