Archive for June 2011

Steps for being a good programmer

Here are some general pointers I try to remember when writing code. Even though following these guidelines always helps me, I do a poor job at following them. So, I’m hoping that  I’ll follow them better if I write them down here.

Work from the top down

    This can be a nice way to ease into writing . Think about what you want the code to do and write a function name that represents it. (for example, play_game(…)) Then, think about what you want that function to do, and write function names that represent it. (initialize_game(…), update_game(…), draw_game(…)) Keep doing this until you have super simple functions that need to be filled in to make everything work.

    Design good data structures

      This applies to both object oriented design and not. Spend time designing good data structures and objects. Design good relationships between them. I’m not going to describe what makes a data structure good or bad here, but for some reason I can always tell the bad ones when I begin trying to use them in functions.

      Design good simple functions

        Similarly to designing good data structures, design good simple functions. For example, if you have a function name that has the word “and” in it, it may be time to reconsider the design of your code.

        Break the problem down into smaller parts

          This is a more general way of summarizing all of the points above. Writing a new application may be a daunting task. Break the problem down into smaller problems, until the problems that remain are simple and easy to solve.

            If you don’t have the data you need, move the functionality up to a higher level function

            This one’s a little tricky to describe. If you’re working in a function and you seem to need to keep sending more and more data structures as parameters, stop and reconsider if that function is really the right place for all of that logic to happen. Consider moving it up into the function that calls that function instead. This principle seems to help me pretty often.

              Code for the specific application you’re working on

              This is one of the most important points in this list! It’s easy to think it’s a good idea to make your data structures and functions work well for other programs or “future projects”. You know, making your code generic and “reusable”. Well, stop it. The future projects you’re thinking of probably won’t ever get written, and you’ll waste time making your code generic instead of just making it work well for the program you’re working on.