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:
@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.
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.
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.