[Bf-committers] Final Design of Basics (render api)
two.a.ron at gmail.com
Sat Jun 30 03:06:02 CEST 2007
Hi again Campbell,
> Could you have some kind of rationale behind the naming of functions?
My rationale up to this point was "reads like english," but you're
right I should come up with a more systematic naming scheme. Also, for
readability I have been using the convention of no abbreviation. Code
is read more often than written, so I really want to make this API
readable, and clear in whatever ways I can. A few extra characters
never hurt anyone.
Here's an attempt:
--- callbacks, plugin defined structures ---
no prefix, CamelCase for types, underscores for names.
--- enums ---
Rapi_TYPE - Rapi_DATATYPE
Rapi_OBJECT_VALUE_NAME - Rapi_GEOMETRY_POLYGON_MESH
// organization is less obvious with these than function names
// but readability would diminish if I did VALUENAME instead.
--- handlers types ---
RapiType - RapiObject, RapiVertex, etc.
// CamelCase for types, underscores for names as a general rule.
--- functions ---
Rapi_Object_OperationCamelCase - Rapi_Object_GetNext()
// 3 sections divided by underscores: prefix, data, operation.
// I think this is reasonably organized and readable.
I'll go ahead and put these in the render api page, because I think
they're good enough to satisfy, anyone is free to suggest further
More information about the Bf-committers