Less code means fewer bugs

Article#: 00128

Date: 2026-10-14

Author: Radim

Cockroaches eating bread crumbs on a clean table

There is only one code you can be 100% sure is bug-free. And that is: no code. :-)

That does not mean we should stop programming. It means that every line of code, every function, every interface, and every additional state in a program must have a reason to exist. Because every new piece of code is also another place where a bug can appear. And that is not all. We also have to test it, maintain it, modify it when needed, and still know years later why it is there.

The goal is not the shortest program:

Less code does not mean squeezing a PLC program into a few "genius" lines that even their author no longer understands six months later. Ten clear and well-structured lines are often better than one "magic" one-liner.

Good structure may even add a few extra lines. The goal is not less code. The goal is no unnecessary code.

Implement the same function only once:

In automation, I often see similar logic implemented several times. Once for automatic mode. Once for manual mode. Maybe a third time for service mode.

If we create two nearly identical implementations, they start to live their own lives. Today they are the same. A year later, someone modifies the automatic mode and forgets the manual one. Another year later, nobody really knows why the two behave differently.

Where possible, use one common control logic and switch only the source of the command. In automatic mode, the command may come from a sequence or from a higher-level program module. In manual mode, from the HMI. The actual control logic of the device remains the same.

Do not repeat yourself:

If you want to use the same code in several places, you probably need a function, procedure, or function block. This way, the same logic is implemented only once. You then only need to fix a bug in one place, and the fix automatically applies to all instances.

Do not program features "just in case":

When developing software, it is very tempting to prepare for everything that might come one day. But that is one of the easiest ways to create a bloated program.

Another interface. Another mode. Another parameter. Another function... Nobody needs it today, but maybe it could be useful one day. Maybe.

The real future requirement will very often be different from what we imagine today. So do not program hypothetical requirements. Design the program so that it can be extended. But do not implement every possible extension in advance.

A flexible architecture is good. But unused functionality is not flexibility. It is just more code. If a function is really needed one day, implement it when you know its actual requirements. They may be completely different from what you imagine today.

Delete dead code:

In some projects, you will find functions that are never called, sequence states that can never be reached, old variables, or disconnected branches of logic. Or complete parts of standard software that came with a library but are never used by the actual machine.

Dead code immediately raises questions: Is this used somewhere? What is it for? Can I delete it? Is it prepared for some future function? Is it activated by some configuration I have not found yet?

Every one of those questions costs time. And dead code has another problem: it is often not tested regularly. The active program changes. Data types change. Interfaces change. Standards change. Dead code stays. After a few years, it may no longer be compatible with the rest of the program.

If you do not need the code, delete it. Git or another version control system is a much better archive than your PLC program.

Standard software does not mean everything:

Standardization is the right approach. But a standard library with twenty functions does not mean every project has to use all twenty.

A good standard is not a monolith. A good standard should allow you to use only what the application actually needs.

Build the program in a modular way. Use what you need. Leave the rest out of the project.

Refactoring also means deleting:

Software grows during a project. We add new requirements, special cases, and make changes. If we only keep adding, the amount of code can grow almost indefinitely. That is why we also need to remove things regularly.

When refactoring, do not only ask: How can we make this code cleaner? Also ask: Do we still need it? Does the same function already exist somewhere else? Can we merge two solutions? Is this just a leftover from an old concept?

Deleting code is also development. And sometimes it is the best change you can make.

And then came AI:

With AI, creating more code has become extremely easy. A function that might take a programmer an hour can now be created in seconds. That is a major advantage. But only if you actually need the code.

AI dramatically reduces the cost of creating code. It does not reduce the cost of the complexity you add to the project. You still have to test it. You still have to maintain it. It can still contain bugs. And it can still be part of your project years from now. With AI, it is therefore even more important to ask one simple question before generating another function: Do we actually need it?

Every piece of code must have a reason to exist:

We have many ways to avoid bugs and improve software quality: We can test. We can do code reviews. We can simulate. We can use standards and automated tests. All of that helps us detect and prevent errors early.

Beyond that, there is one very simple principle: Keep only the code you really need. Do not repeat the same logic. Do not leave dead parts in the project. Do not program hypothetical features. And regularly remove what no longer serves a purpose.

Related previous articles:

User:

Log in user:

Log in user:

Log in user - Failure:

Log in user - Failure:

Register user:

Register user:

Register user - Failure:

Register user:

Register user - Failure:

Register user:

Register user - Failure:

Register user:

User settings:

User settings:

User settings:

User settings: