Over the years I've seen what is considered to be the correct way of programming a PLC. A couple of examples; double latching is considered a no.
The other one that I hear a lot, the software should be simple enough that the maintenance guy/gal understands it.

I've put up two points ...latching and the KISS idea. Does anybody have some other point to add or is it just a mute argument where the strongest opinion counts?
What about I don't care what it looks like as long as it works???

 

I've never considered software to be 'pretty' in any shape or form ...

It was in the early 90's end client mechanical engineer clearly defined his software which was
full of latches that he expressly defined/named. Absolute nightmare to code and had to do a redundancy check
as at least half the latches were duplicate or redundant. Could not explain that any process fault/operator misuse/mechanical failure would lead to latches being permanently energised. Had to put in a master latch reset which would transparently reset on process/operator/mechanical failure.

Years later was another nuclear process on a Modicon mainframe. The PLC was on UPS and the ventilation system so critical that it had to continue running even if the PLC failed. So coded in such a way that, on PLC wake up (power up) it had to work out whether the process was already running. If not, no problem; if it was then basically monitor plant parameters. The tricky bit was working out steady state conditions,then taking over control in a bumpless transfer.
It was late in Factory Acceptance Test the client's highly qualified but young inexperienced had panic attacks about what they had asked for and what they got.

 

I've never considered software to be 'pretty' in any shape or form ...

Thanks for the reply....I know, this is why I posted the question...I'm trying to see what the tribal rules are?
I'm very aware of the ins and outs of dealing with badly thought-out code...I've made a lot of money doing this...but it's not really the nature of code it's to do with people.
What about software design patterns??
Standardized code?
Encapsulation??
Weak links between modules??
Abstraction of interfaces??
That's one thing about putting code together...PLC's are simple concepts...and can be gobbled together by people with little to no background. ...but is it readable ...easily maintained...or is all that knowledge invested into a single individual?....Tribal Knowledge?

 

I tended to work on the KISS principle for code assembly on the proviso, if I could understand it, other engineers would have a chance to do so. Did quite a few retrofit control systems back in the late 90’s. Noted other early designs were based on the same principle.

Bigger systems with multi - PLC‘s / multi engineer coding was more of a challenge, it just made factory test more of a challenge.

The worst example was a site visit to a local power station (coal in those days) where they couldn’t locate the software engineer who coded it. Every I/o point (there were hundreds) went into a matrix or came out of it. Several of us puzzled for hours but could not work out how the matrix worked. Apparently that was intentional.

 

Several of us puzzled for hours but could not work out how the matrix worked

That's most probably a state machine, there is a way to express it as a matrix....I've got the detail knocking around somewhere.
The behavior doesn't shock me I see it often, primadonnas, that's the OEM's fault for allowing this behavior but I've also seen OEM protect their code through complication, sometimes using third-party packages to write PLC software or not supplying key documents.

So KISS is one idea..Occam's razor
The other is "my precious" syndrome....from the movie Lord of the rings...