-
Notifications
You must be signed in to change notification settings - Fork 97
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
Determine style guide for function naming #213
Comments
Explorers of Sky's hacking scene already has symbol names that are widely accepted within that community, and they generally use the no-underscore convention like |
The reasoning I have for this function naming convention is because the code is trying to pretend like it has classes and class functions by passing struct pointers over and over. Hence, |
This feels like pretending that classes are real in a different way, by prefixing the "class name" in front of any functions associated with that "class". |
Encounter_GetResult and GetEncounterResult read the same to me, except in the first it's immediately obvious that you need to put the encounter struct in as an argument where the second could just be a function that gets it from a FieldSystem or the like. It also helps to differentiate between functions that will get the same variable/have similar functionality but through different structs (ex FieldSystem_GetBattleResult vs BattleSystem_GetBattleResult). |
The point is the code is written in a way that pretends classes are real, and trying to go against that isn't going to lead to a clean convention |
What happens when two or three structs are passed into a function, or no structs? |
Use the first one, I really haven't had much issue with this convention so far |
Not really a fan. The first struct is not always more important than the other ones, and there are plenty of cases where this convention would get in the way of a succinctly named function. And this doesn't account for functions where no struct is passed in either. |
I think that you're thinking about this too much and no naming convention is perfect, the thing is if we don't use it we're going to have way more functions that are poorly named than ones that aren't. Also class functions arent the only functions to exist |
this is mostly making exceptions to save stuff, and changing it would be a lot of work but, if it's wanted I can slowly go through and change save stuff to be a bit better |
as for |
I can see this helping in specific circumstances, but I don't feel it makes sense to apply this convention as widely as it's being proposed. As mentioned previously, I don't mind if this convention is decided for HeartGold, but I won't be following this convention for Explorers of Sky to avoid breaking their existing widely accepted function names. |
EOS is a chunsoft game so it's possible (and likely) that things are not done in the same class-esque structure as the main series games |
|
This issue has had no activity for 60 days and will be marked stale. If there is no further activity, it will be closed in 30 days. |
Examples to kick off discussion.
Example 1
Example 2
Example 3
Example 4
Example 5
The text was updated successfully, but these errors were encountered: