Okay. I can see that I've made a total hash of explaining this in words; so I'll try with the aid of a couple of diagrams ('scuse the crudity).
The first shows the 3 faces of a bounding box furthest from the viewer, complete with their grid (tick) lines and showing the local coordinate system (at the current rotations):
+Z
/________________________
/\ \ \ \ \ \
/ \____\____\____\____\____\
/\ /\ \ \ \ \ \
/ \/ \____\____\____\____\____\
/\ /\ /\ \ \b \ \ \
/ \/ \/ \____\____\____\____\____\
/\ /\ /\ /\ \ \ \ \ \
/ \/ \/ \/ \____\____\____\____\____\
+Y /\ /\ /\ /\ /\ \ \ \ \ \
\/ \/ \/a \/ \/ \____\____\____\____\____\
/\ /\ /\ /\ /\ / / / / / /
Z \/ \/ \/ \/ \/____/____/____/____/____/
\ /\ /\ /\ / / / / / /
\/ \/ \/ \/____/____/____/____/____/
\ /\ /\ / / / c / / /
\/ \/ \/____/____/____/____/____/
\ /\ / / / / / /
\/ \/____/____/____/____/____/
\ / / / / / /
_\/____/____/____/____/____/_
X \ +X
Y
Each of the points (ends of lines) is maintained internally as a 3D point (x,y,z) commensurate with the local coordinate system.
The boundingBoxDraw() code:
But, the same, single routine is used to draw the faces and gridlines. So, when drawing face?:
 The xcoordinate selects the face. (Actually, one of two: either at minX or maxX depending upon the rotation.)
And the 'horizontal' index counter has to set the zcoordinate of the line segments;
And the 'vertical' index counter sets the ycoordinate of the line segments;
 The zcoordinate selects the face. (Actually, one of two: either at minZ or maxZ depending upon the rotation.)
And the 'horizontal' index counter has to set the xcoordinate of the line segments;
And the 'vertical' index counter sets the ycoordinate of the line segments;
 The ycoordinate selects the face. (Actually, one of two: either at minY or maxY depending upon the rotation.)
And the 'horizontal' index counter has to set the xcoordinate of the line segments;
And the 'vertical' index counter sets the zcoordinate of the line segments;
This diagram shows the 2D representations of the 3 faces from above: +Y +Y
+ +Z
Z ++++++ +Z X ++++++ +X 
+X ++++++ +X
           
+      
++++++ ++++++
+ ++++++
           
+      
++++++ ++++++
+ ++++++
   a       b   
+    c   
++++++ ++++++
+ ++++++
           
+      
++++++ ++++++
+ ++++++
           
+      
++++++ ++++++
+ ++++++
Y Y
+ Z
The drawFace() function (currently) looks like this:
Note that the nomenclature of the 3 minOrMax? conditions from the drawBoundingBox routine, now make no sense in this routine. At this level, the first of the 3 conditions simply selects which position (end) of the face coordinate this face is drawn at.
The other two conditions aren't used at this (drawFace()) level. They are only used at the next level down,  drawGrid(), which is called twice, once for the 'horizontal' lines, and once for the vertical, and each condition is only needed for one of those two calls  to determine which end of each of the two sets of parallel lines, the tick marks, values and axis labels get drawn.
This is the drawGrid() (which should probably be called drawHalfTheGrid()):
Note that the horizontal & vertical nomenclature is wrong at this level. Because the same routine is drawing both, the two coordinates (Z&Y or X&Y or X&Z depending upon the face the grid is being drawn on), switch when drawing the two sets of parallel lines; effectively rotating the 2D face in the process.
I hope that explains the problem of naming things such that they make sense each (deeper) level of reused abstraction?
(Final note: I'm still not happy with some of the naming in the above routines, but I'm getting there; however, the general question about finding a good way to deal with the problem remains.)
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks  Silence betokens consent  Love the truth but pardon error.
