When naming your columns, do you generally repeat the grouping in the column name?
I’m curious as to what others do. Thanks.
As a general rule, I don’t do that.
But I do use quite verbose/descriptive column names.
Taking your example above, I would have:
You don’t fear that grouping could break? I’ve been wanting to shorten column names for a long time, but I hesitate. In your example above, should grouping break, we’d be left with:
which could be nightmarish.
Or do you think the grouping (group/) is part of the column name and that there’s nothing to worry about?
I haven’t really given it any thought before, but yes. Even if grouping broke, you’d still be left with foo/bar
I don’t have really strong views on this, but I do try to be consistent - at least within the same App. My approach has changed over time. When grouping first came along, I used to group columns by type. But then I slowly evolved towards functional grouping, which is what I mostly use now. I used to use dashes on column names (phone-number), then for a while I used underscores (phone_number), then spaces (phone number), and more recently I’ve started using camel case (phoneNumber). 
btw, when I said that I use verbose/descriptive column names, I wasn’t kidding. Here is an example:
Your column names seem to get longer as you run them through subsequent computed columns. This looks oh so familiar.
I use Pascal case (PhoneNumber).
hehe, yes. It becomes quite critical when you have two or three hundred computed columns in a table…
hahhaha… replace them with One javaScript column 
I tried several different approaches but settled on this one:
Each Field starts with the Table name making it easy to understand if one had Related Tables e.g. Company with Company ID, Company Name etc…
It envolves some more typing but it helps to understand relations between tables and especially when designing forms:
When Tables become bigger then Hide and Search Columns become very handy.
PS I use Row ID in every table and always create a copy on Insert e.g. 
Row ID and Property/ID in the Property Table.
That way I still have the original Row ID present when using Linked Tables in a different App and must communicate with the original Data e.g. to enter an Enquiry and link it to the relevant Property.
@MGA thanks for sharing, I find this very helpful to improve my habits.
Since we seem to be working on a similar app (I’m working on a property management app), I’ll continue sharing, you might be able to relate.
In tables for collections (not a helper table, calculator table or reporting table), the structure I end up with typically is as follows:
A ‘row’ group: row timestamp, row owner, and if needed row index. In a way this is meta data and I wish this data were available by default in each table so I need not rebuild it.
A group for the main object of the table.
Usually a few groups of related objects. This group usually includes an object ID and at least one lookup column.
A group which I call RelationsQueries. This group only contains relation and query columns. I place the groups of related objects before this group of relations and queries mainly for aesthetic purposes, I like having the main and related objects grouped side by side. Since relations and queries are links and don’t actually contain data, I wouldn’t mind not seeing them in the table at all, they belong on the side really. I might start hiding them.
A group which I call Display. The purpose of these columns is usually only to adjust how some data points might be displayed in the Layout Editor: default images and values, including 2+ data points in a single field with a template column, things like that. The basic data is already somewhere else in the table, I just need to tweak it a little for display purposes. These columns too don’t serve that much of a purpose, I could consider hiding them.
Functional groups, where each group serves a specific feature or action on-screen.
Here a screenshots to illustrate:
Darren will smile, but recently I discovered a table where I had a group called ‘PrimaryKey’ to designate a set of columns that represented the primary key of the table. I like the idea of identifying at a glance which columns are part of the primary key, though now I think I prefer indicating this in the name of the columns rather than have a dedicated group.
All of this is always a learning process for me. I’m a student every day, so thanks for sharing.
yeah, basically, I always and all apps I’m already used to do it 
I never do the Tenant/TenantName part. I don’t even consider the fact that grouping can break, and if it does I would trust Glide to fix it as a priority 
I do use grouping names based on their functions like “Lookup”, “Relations”, “Queries” etc.
Maybe I just hate long column names in general.
There is absolutely nothing wrong with verbosity. In fact when I worked as a development lead - I constantly asked my developers to make their function, variables etc be named for what they do. You should not have to document your code if the code is clean and written well… I take that approach with column naming.
One persons verbosity - is another persons clarity.
Ha! Agreed! There have been times where I’ve created column names that are almost complete sentences. I also use the → a lot.
Eg: ifActive→id or rel_id→users
Oh yeah, that’s annoying
