“What’s in a name? That which we call a rose by any other name would smell as sweet.” – William Shakespeare
Names are important.The topic of naming conventions isn’t restricted to Power BI only, but I want to call it out because even though we have no (or very few) restrictions when it comes to naming things (entities, attributes, measures) in Power BI, I still see instances where technical naming conventions bleed over into the reports and artifacts we expose to end users…without paying any attention to their needs or preferences.
Is this really (or should it be) a development best practice? In my opinion, YES! Good coding habits, which include naming conventions, is in most cases a development task and often overlooked as an opportunity to get some feedback from the business.
Here are a few examples of the things I see and what I think it should be…
We prefix database tables with “Dim” or “Fact” in Data Warehouse environments to help group tables by function and make its usage clear for other developers. This can be a good convention to have in the back-end, but our end users don’t care about that. All they care about is that it’s an entity from which they expect to see (or select) attributes and measures related to customers.
Using long names for measures definitely brings clarity but the names are sometimes cut off when presented in charts or graphs, making it difficult to read. We have the luxury of using special characters in Power BI, and should use that to our benefit and shorten names where needed.
As developers we are used to the boolean (or bit) data type, and our coding constructs include the true/false verbiage as a standard. Most people however don’t speak like that, and converting this to a simple yes/no value in reports will be much more intuitive to end users.
Ah, another database naming convention that makes its way onto reports. There are exceptions, but in most cases people will expect a yes/no value when seeing a verb as an attribute name.
There are many more examples like this, but I think these point out the different variations I typically see. Let’s think about our end users when creating reports, even when it comes to the smallest of details…
