I'm working on a display library which in most cases works on a 2D plane but it has some components which display 2D projections of a 3D space.

This domain has the notion of Position, Size, Position3D and Size3D.

Position and Size are straightforward:

data class Position(val x: Int, val y: Int)

data class Size(val width: Int, val height: Int)

but when I introduce the 3D variants height is no longer self-explanatory:

data class Position3D(val x: Int, val y: Int, val z: Int)

data class Size3D(val width: Int, // this is OK
                  val height: Int, // is this the Y or the Z axis?
                  val depth: Int) // is depth universally recognized?

Is there a best practice for this problem?

I can work around it by doing something like this:

data class Size3D(val xAmount: Int,
                  val yAmount: Int,
                  val zAmount: Int)

but it feels a bit hacky.

Edit: How should I name 2D vs 3D sizes? Should I keep using height in 2D (y axis) even if in 3D height is for z axis?

How can I solve this?

  • Microsoft Direct3D uses height, width, and depth for the field names. They're pretty popular so you might follow that convention.
    – John Wu
    Commented Feb 16, 2018 at 2:29
  • BTW, what language is this? Commented Feb 16, 2018 at 7:30
  • This is Kotlin, sorry!
    – Adam Arold
    Commented Feb 16, 2018 at 9:38

2 Answers 2


Remember that things can rotate. So there is no definitive way to do this. All you can do is set a convention.

A popular one would pair this

with this:

But you shouldn't assume those words evoke these images for everyone. Indeed there is not a set universal convention for them.

Some others even insist that height and depth are the same thing and insist on adding length (which never helped me since any direction can be a length).

Still others swap x y and z around. I like this one only because it keeps x and y close to where they were in 2D.

In the end you have to set your own convention. Make it clear and stick to it.

Edit: How should I name 2D vs 3D sizes? Should I keep using height in 2D (y axis) even if in 3D height is for z axis?

Simple, don't do that. The moment you change either of the associations previously established in 2D you're destined to create confusion. There is no fixing it. 3D height can't be for the z axis if 2D height is something else.

Now as I said, objects rotate within axis. Height is has nothing to do with the z axis unless you happen to rotate the object so that it does. If you insist that all objects be initialized into that rotation, or that they don't ever rotate, then this is an unfortunate inconsistency that is most easily resolved by making depth align with the z axis in 3D and the other two consistent with 2D. Which happens to be exactly what the images I posted suggest doing.

What I suspect you're really trying to do is communicate the association the 3 axis and the 3 size parameters have in that initial position. There are a few ways to do that.

Implicitly, using parameter position

Position3D(x, y, z)  
Size3D(w, h, d)

Explicitly, usings comments:

data class Size3D( //Initial alignments: 
    val width: Int, //x axis
    val height: Int, //y axis
    val depth: Int //z axis

But in no case would I recommend the name xAmount. That just creates a different kind of confusion. If you must go this way use the name pattern: xLength, yLength, and zLength.

  • I've edited my question to clarify. My main problem is the conflict of Size and Size3D because height has different meanings in the two.
    – Adam Arold
    Commented Feb 16, 2018 at 7:02
  • @AdamArold better? Commented Feb 16, 2018 at 7:34
  • Yes. To clarify it further in most cases the 2D Position represents columns and rows in a terminal (I'm working on a text GUI). But I have some GUI components which represent 3D space (a game area) and in that case I work with x, y, z coordinates. The problem is that in games z is usually the height not the depth.
    – Adam Arold
    Commented Feb 16, 2018 at 9:22

It may depend on the exact field that you're working in. Certainly in games and cinema, we refer to the third size element as depth. We even have depth buffers that store the distance from the viewer to an object or set of objects. I would think that CAD applications would do the same.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.