From adaecb65eaa1abf437a24c93a08b2b7c2266c5dc Mon Sep 17 00:00:00 2001 From: Danny Holman Date: Thu, 20 Mar 2025 14:15:38 -0500 Subject: core: refactor core API to be in proper style Bring the rest of the core API to be in line with the project coding style. This commit also makes the coding style change formal by updating the coding style document in the documentation. Signed-off-by: Danny Holman --- doc/coding-style.rst | 19 +++++++------------ 1 file changed, 7 insertions(+), 12 deletions(-) (limited to 'doc/coding-style.rst') diff --git a/doc/coding-style.rst b/doc/coding-style.rst index 68c2240..8908eef 100644 --- a/doc/coding-style.rst +++ b/doc/coding-style.rst @@ -135,20 +135,15 @@ should have a name that reflects their purpose and scope. For instance: Typedefs -------- -Typedefs should be avoided at the global or API level, as it can hide -information about a struct or pointer. Things such as ``type_t`` are prone to -create confusion and are heavily frowned upon. The rationale is that when a -programmer sees ``type_t var``, they have no context as to how the type needs -to be used. Instead, leave the backing type information in full view: - -.. code-block:: c - - struct type *var; +Typedefs should generally be avoided at the local level, however, at the global +or API level, a bare structure could become a bit too wordy for general use. +Instead, use a typedef to avoid hitting the 80-column limit unless it is +readable as it is. The engine has already defined the standard C23 integer types for use in -engine code, so there is no need to do any kind of typedef. Even if the backing -type information is platform-dependant, a simple ``void*`` is almost always -preferable to creating a new type wholesale. +engine code, so there is no need to do any kind of typedef for standard types. +Even if the backing type information is platform-dependant, a simple ``void*`` +is almost always preferable to creating a new type wholesale. Functions --------- -- cgit v1.2.3