I prefer to see code with the following features. Note that I come from a largely Siemens background and should be read with this bias in mind!
1. Concise variable names written in CamelCase (xxxVariableName) with a meaningful prefix that indicates the function or location of a variable. For example, inpVarname for variables connecte to a physical input, pibVarName might refer to a permit into the block from external.
2. Also where possible, I like to ensure that variable names when considered in the context of where they are located in a DB or UDT have minimal redundancy. I hate reading things like Heater002.HeatingElements.TurnOnHeatingElement1.
3. Good encapsulation of objects. For example, I like to see device blocks for processing analogue inputs include simulation and test features that don't have to be programmed specially for each project. A library of these sort of things makes implementing future projects that much easier. Device blocks in general should be capable of being "wired" to the rest of your code with minimal hassle and external logic.
4. Above the device level, I like to see standardized integer based state machine layout (there was a good thread on this a few weeks ago) written with clarity and robustness in mind,and with appropriate troubleshooting features built into the code (inhibit transitions, skip to step, minmum state time).
4. "symbol has priority" style is my preference in S7. I don't much like seeing code with loads of manual buffering placed all over the place.
5. Minimal tag interface to interface panel or SCADA. The number of tags influences the processing load the PLC must bear and also influences the cost of some packages. A well defined standard interface for tags can, depending on package, reduce development time as well.
6. Searchable links to functional specification. Where possible the functional spec should be linked to the code
7. Comments for physical inputs and ouputs should make finding them in the electrical drawings easy.
8. I can't believe nobody else has said it yet - try and use a standardized languge where possible (Ladder, FBD). Writing code in less common languages like STL, SFC or any other graphical/text language is likely to reduce the chance of being able to reuse the logic on another project, the more so since clients don't often like to buy new packages and retrain their maintenance people to troubleshoot problems late at night when support is far away.