I’ve seen a lot of people struggle with coding. I’m not sure exactly what it is that throws them because they’re not generally stupid or otherwise ignorant, and they can describe almost any other process easily in a manner that others can follow. Coding just seems to be one of those things that people have a WTF reaction to.
Some or all of this is going to seem pretty obvious to a lot of you, but I’ve seen people struggle with every step on this list. This process can also apply (with some modification) to almost any other project, not just coding.
Steps 2 and 3 may be interchanged in some projects. If you’re writing PLC code for an existing machine, odds are the PLC is already wired in; this means your inputs and outputs have already been assigned for you.
1: Read the Entire Project Overview
Do this first. Don’t worry about anything except what you’re trying to do; the how will come later. Give it a read or two to get a feel for what you’re trying to accomplish.
2: Break It Into Chunks
You’re writing your code one line at a time. Act like it. Say you need to (in this order) open a door, run a conveyor for five seconds, stop the conveyor and close the door (simultaneously), and activate a drilling process consisting of a whole different sequence of operations. Pick one piece of this sequence and figure out what to do with it. When you’re working on that 5-second conveyor operation, don’t worry about the drill. Put it completely out of your mind. Yes, on occasion you’ll have to go back and change something you already worked out, but you can go back and do that when you need to. Trying to figure out everything you need all at once is a surefire way to burn out.
3: List Your Needs
Now go through and figure out what you need to make it work. Do you need to activate a conveyor? Write that down and assign an output. Do you need a variable for something? Write it down with a good descriptive name. When I’m writing PLC code, I start with a list of Inputs, Outputs, Latches, Timers, and Counters. Then I make a list of all the steps in the process.
You will almost always need to revise this list on the fly. It seems like every time I think I’m done with the list, something else pops up (usually a latch in PLC code, subroutines and variables by the legion in VB/C#).
4: Use A Good Labeling Scheme
You’ll save yourself a lot of headaches if you make your labels intuitive.In RSLogix or something similar, you should name your inputs and outputs. You should also label them with what the device is.
In something like Visual Basic, Java or C#, use labels that you can make sense of and group together. Say you need six different variables or subroutines for a door (open and close, whether the door is opened or closed, whether or not it’s locked, and lock/unlock). The easiest way to write this is doorUp(), doorDown(), doorPosition, doorLocked, doorLock(), doorUnlock(). You can tell by looking at them that they’re all related to the door and what they do.
5: Use Pseudocode
Once you have a good idea of what the step you’re working on requires and what variables and instructions you’ll need, write pseudocode for it. Pseudocode is one step short of actual code. Instead of writing actual code, write the step in English broken down as simply as you can so that later you can replace the pseudocode with actual code. It also allows you to do parts of it in shorthand: instead of writing six lines of code to do something, you can just write “do process X” in your pseudocode and make a note that you need to code that process, which will be its own step.
This is especially important if you’re using a symbolic language like PLC ladder logic — if you can write the code without something like RSLogix, you don’t need this page. Only after the pseudocode is written do you actually code it. If you’ve written good pseudocode, the actual code will be little more than a manual Find/Replace process where you replace your pseudocode with actual code; you can even write the actual code in addition to your pseudocode and comment out the the pseudocode as documentation.
This isn’t mandatory, and I skip it on occasion if the code itself is trivially obvious (in which case it’ll just be written into the pseudocode), but it helps on more complex projects.
6: Subroutines Are Your Friends
Have something you’ll need to do multiple times? Write a subroutine.
When I’m coding a PLC program, I don’t have a dozen “activate Output O:0/3” scattered throughout my code. Instead I have one line ending with O:0/3 being activated, and all the ways for it to be activated in parallel rungs on that line and everywhere I need that output activated I insert a latch command. This adds a few lines but it makes the program easier to read, especially if I have to change that output for some reason later on. Using latches instead of direct activation also allows an output to keep running after an input has been momentarily activated and deactivated when a different input is activated (sensor, timer, etc).
A lot of my game code projects require simulated dice. One of the first things I wrote was a basic DieRoll function that takes the number of dice and adds, rolls the dice, and returns the result. Most of these also require a success roll; the dice are rolled and compared to a target, and whether they make it or not is returned as a boolean. A variant on this returns the margin of success or failure. All of these are coded as subroutines (The three above are functions if you want to be pedantic).
Which leads us into…
7: Build A Code Library
Have you come up with a good way of doing something? Keep it in a file of other good subroutines. All of my VB and C# projects use a constantly-evolving code library I call the EI Base. This is a single file I plug into all my projects, containing all the little nuts and bolts I’ve come up with.
This is my method in a nutshell. I hope this helps you in your own coding endeavors.