[ramble]
There aren't any real standards per se because everyone's needs are so different. Nevertheless, one should still practice good program design techniques.
Use top down software design.
Break the operation down into logical zones (eg vacuum pump, cold trap, retort, hotzone, powersupply) or logical sequences of operation (eg close, feed powder, compact, open, eject). Then write a subroutine for each section. My general rule of thumb is that if I dont think I can write it in 30 lines or less, I need to break it down some more. That is just a general rule however, there will be times when it makes more sense to keep all the lines together for that part.
As I usually use AB plcs, I also create data files to match each zone or step (eg B13, T13 for vacuum pump, B23, T24 for cold trap, etc.)
There are some other things as well that will help out anyone who is looking at your program in the future. Early on in my programming career I developed truth tables and karnaugh maps and applied logic reduction techniques and built this nice little compact program. Its still in use today, but no one, not even myself, can read it anymore. Those rules may have applied back in the days when you designed PCBs with discrete gates, but in a PLC it doesn't matter. If it makes sense to include a bit on a rung for the sake of readability, even thought that bit might be covered by combinations of other bits on the rung, then go ahead and do so.
Example:
The RUN bit might have AIR_PRESSURE_OK among its permissives, but if if makes it more readable to do the following
RUN OTHERPERMISSIVE AIR_PRESSURE_OK OUT
------] [-------] [-------------] [-------------( )
then go ahead and do it, someone from maintenance might just be glad you added the extra bit someday because he didn't have to sort through spaghetti code. Don't go overboard on it however.
Memory conservation is not really an issue in most PLC programs, and its not like a mainframe being shared among multiple users - so go ahead and use it where it will make your job or someone elses job easier. The chips are stil there and you paid for them even if you don't use them.
Program tag names and electrical drawing tag names should match.
Above all else document, document, document. And keep a program revision history, a from/to change log, and a description of why.
Do not adopt a kingom-builder attitude and horde your know-how with poor documentation. Someone who is irreplacable for those kinds of reasons is all so unpromotable.
[/ramble]