{"id":515,"date":"2013-08-28T12:04:42","date_gmt":"2013-08-28T16:04:42","guid":{"rendered":"http:\/\/blogs.law.harvard.edu\/acts\/?p=515"},"modified":"2013-08-28T12:14:08","modified_gmt":"2013-08-28T16:14:08","slug":"documenting-documentation","status":"publish","type":"post","link":"https:\/\/archive.blogs.harvard.edu\/acts\/2013\/08\/28\/documenting-documentation\/","title":{"rendered":"Documenting Documentation"},"content":{"rendered":"

I recently waded back into simple web application development (more on how that feels later), and one of the many aspects of coding that I’ve been refreshing myself on is how to best document what I’ve written so my future self doesn’t get too confused over what I implemented or why I implemented it in the way I did. The application is deadly simple, so simple that I hesitate to call it an application. The web page contacts a PHP script via an Ajax call, and the PHP script does its thing, sending back a JSON-encoded object. The client subsequently uses the object to display a message of success or failure.<\/p>\n

As I said, deadly simple.<\/p>\n

Nevertheless, as simple as the application is, I’ve been researching how best to document PHP and JavaScript. For PHP, the definitive answer appears to be phpDocumentor 2<\/a>. For JavaScript, there is JSDoc<\/a>. Here are some additional links that I found useful:<\/p>\n

phpDocumentor<\/h3>\n