Good or bad programming is not indicated by how well the machine performs the activity that it is supposed to perform under 'normal' conditions. As hinted by the previous posts - it is indicated by how well the machine handles things when conditions are not normal. Mid-cycle power failures, sluggish mechanical components, low air pressure, failed limit switches, and so on. Sometimes you spend more time programming for the contingencies than programming for the desired process.
An IBM RPG programmer friend of mine used to say that he hated PC serial communications because you had no control over what was coming at you down that line - and you had to allow for anything. That's the nature of the world that PLC programmers live in. Nobody can truly allow for everything but there are several steps that you can take to stabilize your world. A lot requires familiarity with the instrument that you are playing - guarding against mid-scan data changes from IO or from communications, proper handling of power-on and emergency stop situations, and so on. Careful selection of data types and sizes is really important.
Don't beat me up for this - but my PERSONAL opinion is that there tends to be more bad programming in AB PLCs than in other brands.
Reason #1: The biggest reason is their US popularity. More novice programmers are put into the AB world than the other brands. So many that proclaim to be experts because they've had some AB training yet they have no knowledge of the fundamentals of programming. Can't fault AB for this!
(Knowing how to program and knowing how to enter code into Logix are two very different things. Don't assume that my generation is not tech savvy because I don't care to know how to post to Facebook on my cellphone. My generation invented the Internet!)
Reason #2: Company policies and AB hype that push for ladder logic for everything even when it is a bad choice. Obscure brand-specific instructions that were designed to do things in ladder that never should have been done in ladder.
Reason #3: Minimal or non-existent enforcement of data types. There's data size and type conversion warnings in my C compiler that make me think before typing in a data type cast. How come the PLC people think they do not need that?
(My understanding of the ADA programming language is that it required permission from Congress to do a data type conversion. This is a gross exaggeration - but the designers of ADA may have had some valid reasons for hand-cuffing programmers.)
Reason #4: Confusing the quality of a code editor (AB is the best) versus the quality of the programming language implementation (another issue). We could burn up megabytes squabbling about this one.
- - - - - - -
A side note:
Years ago (35+) I was presenting a paper at the ESD - Engineering Society of Detroit - PLC show. The massive AB booth was crowded with people. A little observation showed that a substantial portion of them were AB or distributor people. They were making plastic pyramids.
Not far from the AB booth was a small booth with a guy that had a combination PLC/HMI/Motion controller. Nobody talking to him. He commented that he had a solution that could do really well and do it very economically if properly applied to a situation that suited it. He sadly said that the American market bought on name and not on suitability for the function. Nobody really cared about cost or ease of application. He believed that the European market - at least at that time - was more open to alternatives.
I don't remember if I told him the old saying ' 'You never get fired for speccing IBM'. Still true today with AB, probably more than ever.
Fortunately for all of us in the US AB has done some really good things in many areas, especially communications protocols. They seem to have had the size and clout to push a pretty good mostly open communications standard. I'm glad they did.