[Bf-committers] Doxygen docs?

joeedh joeeagar at prodigy.net
Wed Jan 5 22:45:04 CET 2005

Alexander Ewering wrote:

> On Wed, 5 Jan 2005, joeedh wrote:
>> The code is self-explanatory, after you finish having apoplexy at the 
>> wierdness of it :)  .  Blender violates so many software-design 
>> "rules" that it isn't even funny.  Also there is a contradiction 
>> between the design and
> Dunno. I don't know about any software design rules, nor about any rules
> in general in life. I guess that's a good attitude.
>> the code: The design in abstracted, but the code is not (referring to 
>> the main code in blender/source/blender of course).  I'm excluding 
>> the sound and image modules BTW, I've never looked closely at them 
>> but they're in C++ and they seem to be fine.
> You see, this probably comes down to a question of taste. For me, your 
> last
> statement ("They're in C++ so they're fine") is the complete terror. I do
> not really care about design as long as the code gets the stuff done 
> and is

C++ is a nice, good language that has been taken a little too far in 
terms of complexity.  It's worth the effort of learning, though.

Also, I cannot express strongly enough how important good software 
design is.  The better the design, the more easily you can add new 
features, and plus it helps cut down majorly on bugs.  You can do so 
much with a good design. 

I tend to code so, for example, to add a new spacetype you only have to 
define a new structure, code a draw and event function, then add these 
to an array of a special structure array BuiltinSpace (aka python 
style).  No having to insert code into switch statements in four or five 
different files.  You simple add to the BuiltinSpace array like so:

static BuiltinSpace builtin_spaces[] = { {"Material", draw, evt, init)}, 
{[name], [draw func], [event func], [init func]};

Hope that makes sense.


More information about the Bf-committers mailing list