You don't need to document the dreck you have. You need to document what marketing believes the dreck you have does. The last place you want to look for that is the actual source code.

Now, I only say this because the OP said (and I paraphrase) "I have a bunch of spaghetti that I can't figure out, so how do I clean it up?" The answer is "Write some tests, then refactor, then write some tests, then refactor, then ..."

Your testsuite then becomes the basis for your documentation. Obviously, you convert all the ok() calls into English or Swahili or whatever, but it's still the foundation.

That may work okay for some places, particularly if your revenue stream is only loosely coupled to the code in question. Personally, the code I work on has a lot of revenue pushed through it every day, in a very quantitative manner. So, refactoring from what it does do to what it "should" do is fairly risky. What looks best to the developer isn't always best for the business, and even if a change is for the better any unexpected changes in the metrics raise flags.

YMMV, but I think that in a organization of any significant size, it's generally a bad idea for developers to make unilateral decisions about how the product should be changed.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other