Determine style guide for function naming

[luckytyphlosion]

Examples to kick off discussion.

Example 1

Example 2

Example 3

Example 4

Example 5

[AnonymousRandomPerson]

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 GetEncounterResult. I don't mind if the proposed style is chosen specifically for HeartGold (although I don't personally like it), but if it's intended to spread into the other pret repos then I feel that will be a losing battle.

[adrienntindall]

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, Encounter_GetResult is equivalent to if the Encounter struct had a GetResult function. But this is c. So classes aren't real.

[AnonymousRandomPerson]

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". GetResult is simply a bad function name, and a better name like GetEncounterResult would not run into the same issue.

[adrienntindall]

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).

[adrienntindall]

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

[AnonymousRandomPerson]

What happens when two or three structs are passed into a function, or no structs?

[adrienntindall]

Use the first one, I really haven't had much issue with this convention so far

[AnonymousRandomPerson]

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.

[adrienntindall]

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

[red031000]

1. no
2. yes
3. yes
4. no
5. yes

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

[red031000]

as for Encounter_GetResult vs GetEncounterResult we have gradually be leaning more towards the former, but there are many examples of the latter still around, as for which one is preferred I don't mind, but for the latter I can see it being awkward in some circumstances

[AnonymousRandomPerson]

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.

[red031000]

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

[PikalaxALT]

Save_XXX_Get was intended to create a uniform naming scheme for the save block functions, as a counterpart to Save_XXX_sizeof.