Jump to content

Programming best practice question


Recommended Posts

I'm in the middle of building the most comprehensive, largest program I've ever attempted, and it's utter chaos. I've figured out how to do pretty much everything within the scope of my original idea (a universal game scripting system.) The problem is, I can't seem to lay out the particulars of each aspect of the program. There's too much interconnectedness and I end up writing code for one part, then completely scrapping what I've written to encompass a new idea or to solve a problem I encounter. It's frustrating, and I know there's got to be a better way, or a tool that will help.

What tools and methods are there to lay out a program's design clearly, so that I can create a task list for myself and follow it?

Link to comment
Share on other sites

Hello Jrowe,

Your quandary sounds familiar to me as I've asked it before. I cannot solve the problem in your domain, but I can talk about helpful ideas, tools, etc. that I've gleaned for this community and those outside of it. What I offer below may be disciplines you already employ; if so, please feel free to disregard them. In no particular order:

0 ) The best tool for the job is the one on your shoulders. Code generators, IDEs, UML modeling, Visio - will only help you in creating crap faster if you don't understand exactly where you're going.

1 ) Download TodoList. This tool may not help in mapping out the system architecture, but it will help immensely in keeping track of the tasks you need to finish.

2 ) Go read The Pragmatic Programmer and Code Complete

3 ) Don't repeat yourself. If you're cutting and pasting large sections of code - STOP. You're creating a maintenance nightmare for yourself down the road. Think of how you can generalize the solution such that you can write that function once and access it from multiple places in your code. I'm sure there are contexts where the Editor pattern (i.e. Cut-and-Paste ) is unavoidable, but for the most part I've found this to be very helpful.

4 ) Keep your functions short and sweet. I've heard some go as far as saying if you're approaching 50 lines in a function, you may need to break it up. This is contextual, but may be good advice in your situation.

5 ) Use a very descriptive variable naming convention - one that allows you to immediately understand its type and its purpose.

6 ) If you're coding AutoIt inside SciTE, type "setupudf" above your function and press space. Force yourself to fill in the information. Pretend its a mad-lib. You'll thank yourself later.

7 ) Map out your solution ( or a portion of it ) before you even touch the keyboard. It sounds like you understand the essence of the problem domain, but the details are proving to be tenuous. When this happens to me, I find myself feigning progress by adding useless features until I'm so far in I can't see out. Stop. Step away from the keyboard. Pick up the post-it note, graph paper, cocktail napkin, ANYTHING to get your thoughts out in a transient format.

8 ) Employ some form of source control.

9 ) Adopt a Test-Driven Design methodology. Or one similar to it. In TDD, you first create tests for system attributes/behaviors before you even write them. In fact, you write them first knowing that they will FAIL. Then you write the code that will make the test PASS. Furthermore, these tests should exist at the smallest granularity of functionality, and should be able to run quickly in a harness that reports the results. If your system has been designed upon layers and layers of tests, you stand a greater chance of knowing immediately when functionality was broken by an addition or change.

I hope this helps!

Zach...

Edited by zfisherdrums
Link to comment
Share on other sites

Yup, some good stuff in there. I took out my trusty quad-graph paper notebook and wrote a list of what I wanted my program to do. I then took each feature and broke it into tasks. I'm working on breaking the tasks into functions and code, arranged in columns, with lines showing where data is passed back and forth.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...