As we continue our series with programming, I seem to be spending a lot of time on concepts and less on code. There is a reason for that. I think for most of us who program for Autodesk products, it was something that we just kind of ‘picked up’. Sure, we may have had a class or two in school about programming. But the reason we are playing around with it now was either out of:
For me it was a mixture of both. I started tweaking some lisp code a user had written for a company and then left the company. Our standards changed and so I needed to change the code to meet the new standards. I had NO idea about lisp but could find the layer names written in the code. Well, if I could change the layer names I began to wonder if I could tweak this or that – curiosity stepped in.
The issue is we may never have been taught good programming techniques. So before I jump right into code, I thought it important to spend just a little time talking about some good practices.
On with the post
Okay, so you have a cool idea for a tool. So you immediately jump right into whatever programming development environment that you are using and start coding, right? Wrong!
If we take a moment and first try to visualize what do we want as an end result. (You probably already know that since you have this cool idea)
Okay, what do we need from the user to get to that end result.
Next, how can we make sure that the user gives us what we need and not something else.
We have all the data. Are we sure it is correct data?
Now what steps are needed to take the data and reach the end result.
Could we divide and conquer some of these steps?
Ways to visualize
For programming, many use either a flow chart or a data flow diagram. In fact, I just wrote a flow chart for how am I going to handle trial versions of some software that I am working on. It is below. You can see that the user will be presented with four options. From those options, I walk through (simply) the steps needed to get to the end result.
However, what I use often is simply writing out the whole thing as if I am writing a story.
The key whatever you do is be able to picture – not just the outcome or result – the routine as a whole. This requires us to step back and away from the computer for a minute.
Are we ready to code yet??!