You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's super confusing that there are cases where z coordinate values are used in variables with the name y. The use of the ambiguous height and width rather than a name that indicates the axis to which that size applies is also confusing. There's nothing functionaly wrong about the code, it's just using very misleading variable names.
/// Gets the standard height (z-axis) offset for the specified direction.
/// @param[in] dir The direction. [Limits: 0 <= value < 4]
/// @return The height offset to apply to the current cell position to move
/// in the direction.
inlineintrcGetDirOffsetY(int dir)
{
staticconstint offset[4] = { 0, 1, 0, -1 };
return offset[dir&0x03];
}
We should endevor to name things what they are, and avoid ambiguous terms like "width" and "height".
Since many of these cases are user-facing in the Recast interface, we should take care to not introduce breaking changes to the API outside of a major release.
I've started renaming things in implementations to be more accurate and am making notes of places in the interface that would require a major update to change.
The text was updated successfully, but these errors were encountered:
"Height" is also used ambiguously to sometimes refer to the number of cells of the heightfield along the z-axis, and sometimes to refer to the number of heightfield cells along the y-axis.
It's super confusing that there are cases where z coordinate values are used in variables with the name
y
. The use of the ambiguousheight
andwidth
rather than a name that indicates the axis to which that size applies is also confusing. There's nothing functionaly wrong about the code, it's just using very misleading variable names.rcGetDirOffsetY
is a great example caserecastnavigation/Recast/Include/Recast.h
Lines 1093 to 1101 in d0b2ed8
We should endevor to name things what they are, and avoid ambiguous terms like "width" and "height".
Since many of these cases are user-facing in the Recast interface, we should take care to not introduce breaking changes to the API outside of a major release.
I've started renaming things in implementations to be more accurate and am making notes of places in the interface that would require a major update to change.
The text was updated successfully, but these errors were encountered: