Slashdot Mirror


Writing Documentation

twms2h queries: "It is everybody's favorite task, the worst part of programming: writing the documentation. I have been charged with writing lots of documents, some smaller some larger, most of them documenting programs I wrote myself. In order to avoid the torture of fighting with Microsoft Word all the time (which crashes on me regularly) I am looking for an easy way to get printed and electronic (HTML/PDF) documents from as simple a source as possible. I have looked into several of the processing tools that are available on the net." Below is twms2h's take on a few of the documenting systems available. The preference is to keep things simple, editing ASCII files to produce high quality documentation. Are there other tools some of you know of that might prove to be better solutions?

"So far, I like aft, mostly because it is simple to use, and gives me nice result as HTML. Unfortunately HTML is not enough, since I also need a very good looking printable version.

There are alternatives like DocBook, which I could not get to work and udo (Page is German, get the translation from the fish) which I have not yet looked into very closely.

Then of course there is TeX and any number of WYSIWY-won't-G word processors. I haven't used TeX much, I only tried my luck in writing a few letters (and found out that it is not suitable for this). I went through hell when I wrote larger documents with various versions of MS Word and I am not really a fan of Star Office even though version 5.2 has not yet crashed on me (however 6.0 beta did). KWord, part of KOffice doesn't seem to be stable enough yet.

I would prefer a simple ASCII only format as the source for being converted to more complex formats anyway, especially since it could be easily put into CVS for version management (Anybody tried that with MS-Word documents? Don't!)

As all these projects show I am not the first one faced with this problem. I wonder what experiences Slashdot readers have had with these and other packages?"

9 of 583 comments (clear)

  1. try YODL by CommanderTaco · · Score: 5, Informative

    the samba guys used to use YODL before they switched to docbook. pretty easy to use, and you can convert to other document languages including html, latex, etc.
    http://www.xs4all.nl/~jantien/yodl/

  2. LYX by ocelotbob · · Score: 5, Informative

    Have you tried LyX? It's a very powerful multiplatform typesetting program. Seems to do everything you want it to do.

    --

    Marxism is the opiate of dumbasses

  3. Check out doxygen by plalonde2 · · Score: 5, Informative

    Doxygen lets you mark up your source code pretty easily, and generates decent looking documents. You can use the same markup (and cross-reference facilities) in non-code documents processed at the same time.

  4. JavaDoc? by FortKnox · · Score: 5, Informative

    Find something similar to Javadoc (unless you code in Java). Rational has a great set of suites to also document projects.

    And I don't think "documenting" is the worst part of programming. Its very sterotypical.
    I love design, and document while coding (usually in Java with Javadoc comments). Isn't that the way you are supposed to code?

    Especially in a team environment (even more "especially" with Open Source), documentation is critical. Having a good design documented well is how developers should interact with one another.

    Also check TogetherSoft. They have software that creates the UML while you code.
    I also like Together's identification of titles. A "Developer" is someone that designs, codes, and documents. A "Coder" is someone that codes. Which are you?

    --
    Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
  5. Docbook, docbook, docbook. by seebs · · Score: 5, Informative

    I'm doing a bunch of documentation right now, and I *LOVE* docbook. I agree, it's a bit of a pain to set up; we started with openjade as a basis, and worked from there.

    Still, I love the format; it's clear, it's precise, and it's very well-suited to documentation.

    BTW, I'd like to point out that, if you think documentation is the worst part of programming, you're probably not writing very good documentation. Documentation can be a lot of fun. Think of it as a way to make sure that you won't have to do the maintenance later, because anyone will be able to do it based on your writing. :)

    --
    My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
  6. HTML, LaTeX, LyX., Word... by Faramir · · Score: 5, Informative

    A few notes from my experience:

    HTML: easy to write, easy to format. HTML TIDY will make everything beautiful for you. HTML actually prints very nicely. I believe most browsers will let you turn off the default page header/footers. I can see, however, that page breaks might be an issue. You'll probably want to use style sheets anyway, and there's a feature in CSS2 that allows for defining page breaks (Paged Media documentation). Also see Converting HTML to other formats.

    LaTeX: Personally, I'm a big fan of LaTeX. Never tried pure TeX. However, once (if!) I master the CSS2 paged media commands, I'll probably abandon LaTeX. I don't know that one's really any easier than the other; it's just comes down to the simple fact that I know HTML better.

    LyX: I found this very non-intuitive and gave up on it quickly. As I recall, the tab key did not work as I expected it, and various things just weren't what I expected them to be.

    Word: I know you, the poster, don't want to use Word, so this is for others who must use it. I dislike MS as much as the next /., but I must say that Word is actually a very good product. There are things that annoy me (especially placement of pictures), and there's the macro virus issue, but you probably don't need macros in documentation anyway. As someone else pointed out, there are versioning features in Word. In addition, there are collaboration features that let you track, accept, and reject changes. The style sheets are pretty powerful (most people never use them), and allow you to quickly and easily create tables of contents. And of course, if you're in Windows and have Word already, and assuming it does not constantly crash, it's really the easiest thing to use. Just don't try exporting your document to HTML!

  7. docbook does work, and works well by jeffr · · Score: 5, Informative

    We're using the preloaded docbook on RH7.2
    and it works fine.

    Grab some emacs elisp files from sourceforge
    to round out the package and you are good to go
    with tag completion and font color locking
    in emacs.

    Docbook advantages:

    * no worries about formatting, just write content

    * can generate html, postscript, possibly wml, carved stone tablets, etc.

    * can be parsed by freely available xml parsers
    to intelligently extract, say, all authors, all section titles. This could be done with raw
    perl, but why rewrite an xml parser when so
    many already exist?

    * documents can be easily stored in an OODB,
    using an xml->object marshaller, if you are
    into that sort of thing. This allows
    any number of documents to be subject to
    the full power of the database querying
    and indexing.

    Latex (tex) is great, and I've used it for 20 years,
    but its definitely not the same thing as docbook.

    Latex
    allows - encourages actually - one to think
    about appearance while writing the document.
    And you do get great looking output.
    But you sacrifice everything that docbook/xml
    offers in terms of document parsing for other
    purposes.

  8. Re:LaTeX seemed the simplest way by klund · · Score: 5, Informative

    You can make nice pdf and print version. Yes it takes some time to get use to and most WYSIWYG people don't like it but it rocks in CVS.

    In addition to producing HTML and PDF with latex2html and pdflatex, there are some other features in TeX/LaTeX that appeal to code monkeys like me.

    1. Real include files. For example, you can write a mission statement page that gets included in the front of all your documents. When the mission statement changes, you only have to update it in one place, and all your documents reflect the change.

    2. \ifthenelse{}{}{} conditionals. This is really handy when combined with the include files above. I have one set of source files that produce three completely different (but related) documents based on a few \def statements. For example, one's for internal use only and one's for wide release, but I only have to fix typos once.

    3. Define (\def) statements. I keep version numbers and product names here. PHB says "We just changed the product name from "iCrap" to "eCrap". No problem. It's even easier than search-and-replace.

    4. Comments. I comment the source files the my LaTeX documents. Most the time it's just snide remarks, but sometimes I leave useful comments behind.

    %% The behavior described in the next paragraph
    %% used to be a bug. Now we charge extra for it.

    --
    My word processor was written by Stanford Professor Donald Knuth. Who wrote yours?
  9. For a real-world example... by devphil · · Score: 5, Informative


    We're using Doxygen to generate HTML and man pages (!) for libstdc++-v3, the standard C++ library that comes with g++ 3.x. Doxygen can also generate LaTeX, RTF/Word, and some other formats which I don't remember. If you have some additional nifty utilities installed, and tell Doxygen where they are, then Doxygen can automatically use them. Take a look at the inheritence and collaboration graphs on the pages I linked to: normally they're much plainer, and not color-coded. But I had dot(1) installed, which can generate pretty graphs.

    Incidentally, LaTeX is much better than TeX when doing letters. There's a set of macros specifically for writing letters, and I use them all the time for, say, business letters.

    .

    I'm told that it's not that hard to write a module for Doxygen to teach it how to create a new output format, if the half-dozen it knows about don't fit your needs.

    --
    You cannot apply a technological solution to a sociological problem. (Edwards' Law)