Sometimes, no naming convention is simplest.
Now, I appreciate that might sound absurd. But we specialise in saving apps from other freelancers, agencies, and citizen developers, which means we spend more time seeing how-not-to-build-a-Bubble-app than almost anyone.
And one pattern I keep seeing is founders and developers putting into a ton of elaborate element naming schemes that deliver nothing!
I’m going to try and show you why not everything in your Bubble app needs to be named, and how you can make best use of your time to organize your app.
Why name anything?
It is worth being clear on what a naming convention is actually for. A good one does three things: it saves development time, it gives us more information about something than we would otherwise have, and it makes it easier to reason about the application. If a convention does not do those, then it is not useful. That is the test everything below is measured against.
Bubble has already given us a universal naming convention for front-end elements. You know it already - it defaults to Text X, Group Y, or Button Z.
I do not see any value whatsoever in renaming every element. There is certainly value for you as a developer if you are paid hourly, but it does not deliver value to other developers who work on the project, or to your client.
Examples of conventions that hold little semantic value:
Prefixing all groups with
GR_[group name]Adding emojis into names
Removing the element type entirely
There are a few reasons why:
Most groups are functionally irrelevant. They exist to structure the UI and nothing else. A name adds nothing.
A specific, complex naming convention makes it harder for a developer unfamiliar with your project to start working on it.
It can make search more difficult. Most developers are used to searching for "Button [x]". If you have renamed all your buttons to BTN - [x], you have taken away that muscle memory.
Now… every app is different. Equally, I have seen Group XZZZZZZZZ before. That’s clear not useful and is generally a result of naming no elements, and having a huge page with hundreds of workflows and thousands of elements. If you’ve got to that point, then perhaps you do need to be a bit more judicious with your naming.
What should be named
As a rule of thumb, if the element has a workflow or some relevant logic attached, name it so it is clear what it does. Almost all buttons fall into this category: Button Create Account, Button Make Payment.
Key UI groups should also get useful names - Group header, Group user card. But keep the element type prefix as-is, so other developers know what they are looking at.
That is basically it for the front end. Effort spent renaming everything else is effort that could have gone into the parts of your app where naming actually matters.
Where naming becomes non-negotiable
Based on our experience, the naming of front-end elements does not affect the maintainability of an app much. Your logic and data structures are a different story. There, at a glance, you need to know what you are looking at and what type of data you are dealing with. If you are familiar with TypeScript, it is the kind of thing an IDE gives you there. In Bubble, your naming convention has to do that job.
What we recommend:
Data types and option set fields in Title Case and singular:
Invoice, notDT_Invoice.Billing Account, notstripeBillingAccount.Basic fields (text, number, date) in camelCase.
Fields that link to another data type or option set use that type's exact name. A field holding a
Useris calledUser.Booleans prefixed isX/shouldX/hasX, because "This Check's isNew" reads naturally in an expression.
Now, there are plenty of good naming conventions for your backend (and plenty of bad ones). The naming convention above is one we recommend, but that’s not to say that others aren’t useful. Just consider it against the three purpose of a naming convention I mentioned earlier.
The real payoff of the one we suggest above comes in workflows and expressions. We name workflow parameters exactly after the type of data they carry, so when you wire up a custom event or backend workflow, User maps to User and App maps to App. Call a spade a spade, and the purpose and type of every field is intuitive without clicking into anything.
Food for thought!
George
Founder, Not Quite Unicorns & Buildprint