-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(In)Consistent API Naming #65
Comments
Here are my personal thoughts/suggestions, which I've generally been trying to follow: Functions go like libnameFunctionName(int mixedCaseArgs); Types are named with LibnameFullCase. Structs are always typedef'd anonymous structs. Struct member names are also lowerMixedCase. And then constants/enums LIBNAME_CATEGORY_ETC. And headers belong in include/libname/modulename.h, the exception to this being that liblv2 goes in include/lv2, but its function names are prefixed with sysEtc rather than lv2Etc, since the lv2 prefix is taken by include/psl1ght/lv2 (the lv2 syscall interface). So now we have some headers defining functions like I described above, and then others where it follows sys_this_is_a_function style. I prefer to only use that when necessary, like when implementing standard POSIX headers. We also have some headers kinda thrown around without any real thought to their organization. Comments? |
sys_blah_blah isn't POSIX, but using these names still do buy some portability versus other PS3/Cell SDK:s. And I think any PRX call should use the official name (the one used to compute the function id number) when possible. |
I agree, using the official name when possible should be encouraged. |
zeldin: I know those aren't POSIX, I was referring to that nomenclature style as a whole. As for using the original PRX names, that is a plus for portability... But goddamn Sony is even more inconsistent with those names >.> |
AerialX: I did not mean to imply that you thought differently, just to point out that the same reasons for conformity also apply there. Maybe I should have started the sentence with "Albeit" or something. Sorry about the confusion. ^_^;; Yes, Sony do chose inconsistent names, but choosing the inconsistent names for compatibility and a common nomenclature in communication at least gives a reason for the inconsistency, granting it some legitimity. (Not meaning that it was legit of Sony to pick inconsistent names, but that it would be for PSL1GHT to pick the same names for compat reasons.) |
I am not sure I'd be happy with "cell" in our function names if we were to use official prx lib func names... |
Maybe someone should start a compatibility layer project, one that provides the same include paths as the sdk and #defines psl1ght names to the original prx names. |
We don't have any set rules and it's getting to be kinda random. We need to decide on a standard set of rules and put them up somewhere like on a wiki page. Then rename psl1ght's functions accordingly.
The text was updated successfully, but these errors were encountered: