For producing documentation for application users, the best way I have found is to imagine myself as a user and think about what I would like to know about this application in both the how to use it and how it relates to any business processes that they use, plus any hints/tips for using it and help contact information.
From a technical point of view, while using a help file or HTML readme is by far the most common form, I've had a table with common questions and answers, accessible via a menu option which lets the user view the questions and answer on screen via a report and print it out.
This works well, because it makes adding new entries or changing existing ones far easier than generating a new HLP or CHM file.
I don't think that there is such a thing as best practise as far as user documentation is concerned, because each application has its own reason for existence, quirks and business processes to support.
Talking about technical documentation for developers, DBAs and IT support staff is another matter, and should include fully commented source code, with sensibly named objects and controls in accordance with a defined naming convention, 1st and 2nd level entity relationship diagrams showing table relationships. Basically, anything that you would want to see if you were coming into the project at that point to take over.
John