OSDev.org

hello..
Have u started documenting your project? I feel the need of documenting my codes. I want to use tools like DFDs and UMLs to serve this purpose. Is there any other and more efficient way of documentin project? What strategy have u used in doing it?

Lots and lots of sheets of A2 paper with design on it, a roadmap/tasksheet of things to do, and the order in which to do them, and reasonably commented code. In terms of end user documentation, a few collections of incomplete Word, OpenOffice.org, and plaintext documents with notes and documentation in them.

I've no documentation at all. The only documentation that I have is my code, which I try to comment well. And when I finish a part of my code I post something about my blog how it works, thus that could be seen as some form of documentation.
Thinks like UML are only useful when using classes, and as most people here are deving in plain C, they cannot use UML. I saw you're using c++ with an OOP design, so it works for you.

hello...
I think most of us have made our kernels design such that it fits modularity. So although its not made in C++, it can be documented with UML (except class diagrams) . Anyone have tried this?
I have documented many projects using UML, but all those were applications. Never tried to document an OS. Even my code is well written with comments as all u have, but i think using Software Engineering techniques may help me in future when my kernel grows really big.

I don't get a lot of time to work on my OS (one that hasn't gotten very far). Occasionally I will document on a theoretical approach for a somewhat complex design, an example would be my memory manager. My manager has not been actual coded, its on a plain RTF file that I come back to when I find a flaw or a more efficent method to add to it. The problem is the internal structure can change dramatically when you find some flaw, and because at times I don't touch the project in weeks. This is the reason why I only document what was going through my mind, to make use of the time I have. Other then that, a lot of structured details and so on is within my source code, somtimes having to draw a ascii diagram in them.

A2! damn'.

most of Clicker documentation (prior the wiki) was found on slice of paper roughly twice the size of a playcard ...

I don't know about the rest of the world, but the phrase here in England is "a back of a fag packet design" (fag == cigarette).

Alternatively use the Special Design Paper(TM) (aka toilet roll).

I have to admit to doing the occasional sketch on a napkin at a buffet when inspiration strikes me (occasionally even one put on by the compsci department here ;D). My OS is soon going to have a Wiki as I'm going to revive it I think, I'm going to start by documenting as much as I can and then coding, the "proper" approach for once

Edit:
When did I start calling it compsci? Have I suddenly become American?

I use two of the best documentation methods:

- for large scale things, post about them here.. can search them with the forum search later, and someone might give good comments too..

- for small scale things, comment code.. actually I also keep medium scale things documented in header files..

Wiki with the occasional picture in pseudo-UML thrown in. When I want the docs in some portable format, I export them to XHTML (PhpWiki supports this very nicely).

Even though I'm implementing my OS in C, I'm using a very OO style of writing C. This makes it practical to design every class in UML first before implementing it. I've been using Poseidon UML, which is free, but terribly slow on my machine.

I also comment every function and use Doxygen to generate HTML docs.

Lots of paper I'm using in order to document ideas and construct stuff. Comments in Code, especially in functions which do loooots of grunt work.

Well. Piece o' paper 'n' a sharp pencil are my main development tools. *gg*

Regarding doxygen... I think the concept is very nice, but the tool tried to do too much, and didn't come with a satisfying default config last time I looked (which has been some time since). Has this improved?

Solar wrote: Regarding doxygen... I think the concept is very nice, but the tool tried to do too much, and didn't come with a satisfying default config last time I looked (which has been some time since). Has this improved?

I have prior experience with Doxygen from work, so I didn't mind spending a bit of time tweaking the configuration. From what I've seen, it's much simpler to use it for C than for C++, although if you configure it right the C++ output can be quite nice (e.g. -- auto-generated inheritance diagrams that are somewhat template-aware).

Pype.Clicker wrote: A2! d*mn'.

most of Clicker documentation (prior the wiki) was found on slice of paper roughly twice the size of a playcard ...

Haha, I do a bit of sketching and web development in my free time. I hate working on small pieces of paper for anything that includes a diagram of some form.

I suspect there was more documentation for Clicker on that double-playcard than there is on about a dozen sheets of A2 for Pexio.