For API's in intern or extern we normally aren't so fussed about their API's, however the way gawain is being used - it's functions and types are being included anywhere GPU is used, so it impacts nearly all drawing code.
Currently the API doesn't seem very consistent.
- No prefix identifier for headers, constants, structs and functions
(this is something many C API's do OpenGL, Vulkan, FFMpeg & Python do, we also do this for most of Blender's API's)
Having a common prefix is important since C doesn't have name-spaces, Blender's editor code for example mixes many API's: windowing (GHOST)/drawing (gl)/audio (AUD)/Codecs (av)/input-methods (IME)/Blender Python (BPY)/File loading (BLO)... and many more...
When mixing logic from so many libraries means its important to be clear what library function calls are referencing.
It's also useful to do this for auto-completion, so you can type a prefix and see all the symbols available.
- Public names (which get imported into most of Blender's drawing code) are very generic, eg:
Batch, Attrib padding, IndexType, ElementList, VertexBuffer ... with the chance these could conflict with other definitions.
- Mixed camelCase / snake_case for function names, also within the same name, eg:
ElementList_build, clear_AttribBinding VertexFormat_clear, VertexFormat_add_attrib, add_line_vertices, Batch_add_VertexBuffer, Batch_done_using_program.
Gawain is a fairly small API, so it's not really so much work to give it some consistent conventions.
We could loosely follow Blender's conventions here: https://wiki.blender.org/index.php/Dev:Doc/Code_Style#Naming
GWBatch, GWAttrib GW_attrib_binding_clear GW_batch_vertex_buffer_add GW_element_list_build GW_element_list_vertices_add_line GW_vertex_format_attrib_add
Or something closer to whats there now with a common prefix and more consistent word-ordering,
where (prefix+type are camel-case, the rest not).
gwBatch, gwAttrib gwAttribBinding_clear gwBatch_vertex_buffer_add gwElementList_build gwElementList_vertices_add_line gwVertexFormat_attrib_add
... or something else.
(note that now might not be best time to apply such changes, but there is some chance it gets left as-is too if not handled soon enough).
Update, added utility to refactor the API: D2678