For the DataLakeHouse team we actually had a drawn out conversation about style for all development principles. At least the basics for now. This involved “Do we use hyphens or underscores for development?”, “When do we use hypens vs. underscores?”, “Are there situations where underscores in code are better than hypens?”.
You can imagine there was quite the developer debate. For this we turned to our experience but also some other well-known developer guides. Although the back-end sees mostly declarative code, there are several languages in use for the DataLakeHouse: Scala, Python, HCL, Java. And, on the front-end admin portal: typescript, CSS/SaSS, html, json.
Google’s developer style guide is plain and very straightforward for the discussion of use of hypens compared to underscores and camelCase.

What we decided, as even Google’s style guide alludes is that there are necessary exceptions for using a delimiter to separate words in programming/development. For example, Java doesn’t appear to be the best at handling hypens for variable declarations and the like. BASH and Linux OS environment variables are known to use UPPERCASE structures with UNDERSCORE (“_”) as the delimiter between words.
I personally enjoy the ability to click on variables are even values that are separated using underscores because most IDEs and productivity tools will then select the entire character string including the underscores. This is not usually the case when attempting the same with hyphen separated strings.
![]() | ![]() |
Right: Double-click on hyphen word (only time, instead of real-time selected)
We’ll be updating our style guide for DataLakeHouse from time to time but the basics will be to follow suite with the pre-designed models, pipelines, and other definitions in the framework. For example, all BASH script and env variables are using underscore (“_”), airflow logic is mainly using hypen(“-“), HCL logic follows suite for declarations with underscore(“_”), and variable names using hypen(“-“). We’ll have a full break-down coming in our revamped documentation but that is the gist for now.
If you have any feedback on which you typically prefer to use when coding we’d like to hear from you. Please comment below. In particular this conversation is always fun to have with CSS and TypeScript/JavaScript developers.