Certainly follow what Allen said. In addition to Modularity (one of my favorite bones to chew), develop your program from Top/Down AND from Bottom/Up - Concurrently!
One of the harder parts is determining your modules... where does one end and another begin.
It's easy enough to say... "This section of the machine is one module, this is another...." and so on.
I find that modularity is more a matter of function than location. You need to recognize that while there are mechanical functions, there are also, and more importantly, "conceptual functions".
A conceptual function would be something like... "Go To The Store".
The mechanical functions associated with that concept involve things like... stand up, turn left, walk down the hall, open the door, etc.
The mechanical functions are a sub-set of the conceptual function.
Now, if you think about it, those mechanical functions are really other conceptual functions! What does it really take to stand up? It takes a lot of mechanical activity and coordination!
As you continue developing you'll find that you need to receive, and sometimes, transmit messages.
Before you execute "Go To the Store" you'll probably need more info from the Wife-Module. Besides telling you to get up off your a$$ and go get some beer, the Wife-Module might also tell you that there is a list in your pocket.
You need to plan what messages are needed by which modules, where those messages are going to come from, and what messages are sent by modules and to whom.
I don't know of any standard, or any book for that matter, that has been written describing a rational approach to these things.
In general, it boils down to you paying close attention to the details and organizing YOUR understanding of those details.
A PLC Program is nothing more, or less, than Organized Details!