What are your “development principles” when you’re building out Power BI reports?

For the experienced developers out there, what are the rules of thumb you use when you create reports? I'm more interested in the DAX development domain here—less so about visualization principles. For example:

One of my rules is never put a table name (or function name like "blank" or "all") in a measure name. Why? Because DAX intellisense will often frontload those suggestions, forcing me to cycle through options I don't actually want. When necessary, I will acronym-ize table names when I might need to distinguish between similar base measures. Something like CST Avg Orders (customer) compared to SLS Avg Orders (sales).

Another rule I used to follow was to have presentation measures, measures that contained a more finalized name of metrics and simply referenced another measure so that if business rules changed, I could swap the presentation measure's logic to another measure. This was a rule I found necessary when I needed to do mass-rename automations via Tabular Editor without having to change visual references. (This rule has gone the way of the dinosaurs with tools like Claude's powerbi-modeling MCP being able to find such references and update them easily, though.)

Another general rule I have is to prefer the KEEPFILTERS function when making CALCULATE filter statements because it makes validation easier. Change later if requirements call for it.

This is something I've always wanted to do but have been rather too lazy to keep up with, which, I now realize, has become even more prevalent when giving AI models skills context in development.

I'm just generally curious what other rules you have out there (so I can obviously "steal" some that are really great). Any great articles out there on this subject? This thief thanks you in advance.