Best Programming Practices

I came across this blog post today, and it provides some excellent advice for best programming practices. I figured it would be a nice resource for our community to have, so I've posted it here:

8 Likes

Good article. Endorsed.

3 Likes

Great article. Wish the people's projects I'm now maintaining read it years ago lol.

Just to add my own input based on coding within the Ignition specific environment especially for Ignition beginners -

  1. Keep business logic completely separate from the GUI. This isn't new advice to keep your layers separated, but it's something when your designing an Vision/Perspective GUI to keep in mind. I see the magic push button pattern everywhere. Now imagine you have a magic push button in a vision window and you're being asked for a similar window to do the same business logic in a perspective view - now you have a real headache on your hands. Write the business logic first, then call it from the GUI - the GUI is only there to provide parameters to your business logic functions IMO (besides showing status/state of the system). My personal workflow when possible is design the database tables, write a project script that does my logic on the db/tags, and only when that is working, create my screen where a user can select parameters and push a button to call that bit of logic.
  2. Try to come up with one way that you will handle certain common scenarios - like what do you do if you try to do a system.tag.writeBlocking and one tag out of a list fails? You hopefully want to handle this sort of scenario the same way (or mostly the same way) in every part of your project, so you should code some common way to do that and call that. This way as well, if you ever want to change how you handle this all throughout your project, you only have to do it one place. Similar advice for handling database transaction commit/reverts.
  3. Please keep all your business logic in Ignition if possible. I've run into multiple projects where the business logic is split between Ignition and stored procedures in the database, or even harder to pin down - triggers on database tables etc. I understand it's not always avoidable but if you can put all of your business logic into Ignition's jython, then you should, or at least as much of it as possible and document somewhere when some other crucial piece of business logic is being handled by something else.
5 Likes

I think I disagree about type in the name of a tag. I think PLC code having the type (abbreviated) in the name can be useful.

1 Like

Might be appropriate for PLC's, I can't speak to that, but for scripting or databases oddly enough where I see it all the time (stuff like tblMyTable) it is just bloat that can make things harder in the future if the type of the object has to change without giving any additional information you don't already know.

4 Likes

This might be useful in some cases, but I'm not sure I've seen one :man_shrugging:. With the right static code analysis options selected in Beckhoff TwinCAT you won't make any accidental type mistakes and type is always visible in a tooltip on mouseover variable names. In RSLogix we did, however, use variables like tempDINT or tempREAL.

3 Likes