Inconsistent use of length/width in box factories

[DavidMStraub]

Hi,

I'm currently using build123 and CadQuery in parallel for pedagocical purposes and differences in behaviour are quite instructive to identify possible problems.

One issue I noticed is that cadquery.func.box treats length/width in the opposite way, but I also noticed this is not consistent in CadQuery inernally:

• In OCCT/OCP, BRepPrimAPI_MakeBox takes the arguments dx, dy, dz. Obviously, it is completely subjective which of dx and dy to call length or width.
• Solid.makeBox takes length, width, height and passes them in this order
• box takes w, l, h and passes them in this order

I think it's confusing that length and width have opposite meaning in these two functions.

If you consider changing it, I would strongly suggest to actually use length, width, height (as opposed to l, w, h) in both cases for consistency. Independently of whether anything is changed, I also suggest specifying in the doc string which of those dimensions is in x- and which is in y-direction.

Let me know if I can contribute anything.

[adam-urbanczyk]

Thanks, that came up before. We do need a consistency pass. I'd actually call them width, depth and height. What do you think?

[DavidMStraub]

I think without the doc string, none of the choices (length or width or depth) is self explanatory, and with the doc string, the choice doesn't matter because it's clear.

I personally vote to stick with length, width, height because I'd prefer build123d and CadQuery to remain as close as possible to avoid confusion, although I understand this might not be a a valid argument here 🙂

[jmwright]

Related issue: #1491