Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In a book I'm reading there is a chapter on documentation for your code. The book is about PHP and described some easy methods but also going for some complicated and time consuming methods (xml, xsl) like DocBook.

At my current small company (5 people) we even rarely write comments, but I'm wondering if in a big company how detailed documentation do they write? Do they use such tools like DocBook? Is it complex or simple?

share|improve this question

closed as primarily opinion-based by durron597, MichaelT, Kilian Foth, Dan Pichelman, enderland Jun 29 '15 at 19:05

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

Consider rephrasing your title. "How complex is the documentation you write?" – Mark Canlas Sep 29 '10 at 21:37
@Mark @centurion Fixed up your english there. No worries – TheLQ Sep 29 '10 at 21:41
up vote 3 down vote accepted

Working on PHP and NetBeans, the documentation style is pretty much PHPDoc way. Thus I write a little more than what the IDE generates.

e.g. IDE generates:

 * Description for ClassA  
 * @author Sam-Mauris Yong  

class ClassA{

    function __construct(){
        echo "5";


I'll probably write:

 * Class A Helper Class
 * Some example class used here
 * @author Sam-Mauris Yong
 * @license GNU Public License v3

class ClassA{

     * Constructor for example class
     * echos 5
    function __construct(){
        echo "5";

share|improve this answer

I follow this convention:

// MPlayer_PlayAlbum
//  Creates a playback selection of the given album and starts playing it
//  int AlbumId  [in] Zero based index of the album to playback,
//                    or -1 to playback all the albums (not for iPod)
//  int ArtistId [in] Zero based ID of the artist, or -1 if AlbumId is from the
//                    global enumeration of albums; if AlbumId is -1 this
//                    parameter is ignored
//  int TrackId  [in] Zero based index of the track representing the first item
//                    to play; if AlbumId is -1 this parameter is ignored
//  ERROR_SUCCESS if the function succeeds
//  ERROR_UNINITIALIZED if the remote control is not initialized
//  ERROR_INVALID_PARAMETER if one ore more parameters are not correct
//  ERROR_DEVICE_NOT_AVAILABLE if no device is present
//  ERROR_DEVICE_IN_USE if it's currently impossible to use the device remotely
DWORD WINAPI MPlayer_PlayAlbum(int AlbumId, int ArtistId, int TrackId);

I avoid adding author name as source control already take care of tracing original author and contributors.

share|improve this answer
+1 for using source control for attributions. – Peter K. Feb 14 '11 at 22:31

I tend to write documentation like this:

Method name(method signature)

This is method. Here is a high-level explanation of what it does.

Here is what param 1 represents.

Here is what param 2 represents.


Here is what it will do if you pass it invalid data in the parameters.

See also:

Method's class
Related method
Other related method
share|improve this answer

It depends on a few things:

  • formalism of code. code that other people gets a finer comb than personal code
  • technicality of code

As a rule, all non-trivial functions get a line that says what they do.

At the other end:

//params and their meaning
//description incl. weirdnesses
//exceptions that might show up
//maintainer notes
//future todos

Plus a few delimiters such as /////////////////////////////////// or what-have-you.

share|improve this answer

I firmly believe that 90%+ of the time, code should be self documenting, IOW, variable names, method names and class names should clearly tell the story of what's happening. Only in rare cases when I'm having to do something somewhat unexpected (iterating through a collection and lowercasing the values) will I document WHY I'm doing it (not WHAT I'm doing).

I've got a roughly 500K line code base and I'd bet there are less than 30 lines of comments in the entire thing and it's (mostly) clear what the code is doing and why. I find I'm mostly documenting around external APIs.

share|improve this answer

Depends on the type of work you're doing, how it is run, with which SDLC approach and the size of the team.

In one group where I work, documentation is a wished for entity with variable names of 1-3 letters each. Half the time the class names are 1-3 letters each or a "handler." My own code is as much as possible self-documenting with about a 2-3 page word doc on how it should be used.

In the other group where I work it's a waterfall project. We write 30-40 pages worth of documents for each stage (this last document I wrote complete with diagrams, tables and figures was 60 pages.) There are 3 primary stages before code is even written and in each stage there is a specification, a preliminary, a checklist, a formal document, a verification matrix spreadsheet, and a review.

Hope that helps.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.