[Bf-committers] Doxygen docs?

Chris Burt desoto at blender.spaceisbig.com
Wed Jan 5 22:34:58 CET 2005

Don't suppose you read the architecture document joeedh? This sounds 
more to me like you don't understand C as well as you understand C++ so 
you're making the mistake of saying the C code isn't written as well as 
the C++. I'm sure you're making SOME valid points but I'm also pretty 
sure part of what I'm saying is right..

joeedh wrote:
> joeedh wrote:
> (WARNING: mini-essay follows)
> Here is a small ten-minute essay dedicated to why documentation would 
> help.  (BTW it's bad because I did in ten minutes, I'm tired and it's 
> raining *shiver* I hate rain).
> Blender is divided into basically four sections:  what I call Direct 
> Code, Internal Libraries, External Libraries, and the gameengine.
> Internal Libraries and the gameengine arn't too bad.  A lot of the code 
> in there has been rewritten in C++ (the gameengine was written *in* C++) 
> and the best of it (like GHOST) even has doxygen comments.
> However, the bulk of Blender's code  (in terms of features) is what I 
> call Direct Code, located in source/blender (except for the main() 
> function which is in creator/creator.c).  Except for the sound, image, 
> and boolean modules, almost every feature there is coded in C.
> There are many problems with this code.  First of all, there is this 
> habit to do copy-paste struct inheritance (which certainly confused me 
> at first).  For example, with the exception of Library block structs, 
> each structure has a "struct <structname> *next, *prev" at it's head 
> instead of a "Link head" (like it should be).
> Also, there is a lack of abstraction within the C code, even though the 
> design is fairly abstracted.  For example, adding a new object type, or 
> a new Library block type, requires adding code to about ten different 
> files, as everything is done on a per-case basis.  I understand why this 
> is; after all a lot of that code comes from a time long before modern 
> software design.  But it's still confusing.
> And don't forget the spacetypes.  When I made an abstracted spacetype 
> layer (which I did in C) for C++ components I have to add code in three 
> seperate source files.  Finding where to put the header drawing code was 
> especially annoying.
> Blender is a great application, I know, and the code works, but let's 
> face it: good documentation would be really helpful to navigate through 
> its wierdness!
> joeedh

More information about the Bf-committers mailing list