App Naming Conventions

QUESTION:
As one of my apps continues to grow in size, I realize just how important good naming conventions are for a smooth development workflow. As a fun little question for the community, what are ways in which you name particular elements of your apps? This could be names of views, names of actions, bots, events, etc. This could even include column naming. Iโ€™ll go first:

MY PROCESS:
The app Iโ€™m currently working on has many different views starting from the start screen that then branch off intoโ€ฆprobably close to 20 unique views now (system views excluded). So having some sort of organization keeps me sane.

If a view is at the top, it gets the title NodeES:: followed by the relevant views names. EX: NodeES::ADM or NodeES::PM. So in a sense, NodeES is like a namespace.

Then digging in to those views, you might get actions such as NodeADM::Goto.ExampleView where I have the namespace, what type of action it is, and in this example (GoToViewinApp) points to ExampleView.

I use something similar for naming processes, or events where I might specify the relating namespace, what the general process is (especially if it includes multiple views and steps), and then that processes role in the overall process. So NodePM::ProjectInit.Main might be the main containing process with sub-routines like NodePM::ProjectInit.NotifyPm or NodePM::ProjectInit.UpdatePm

WHATโ€™S YOUR PROCESS:
Now Iโ€™d like to hear your M.O. Is there something that you find helpful in a kind of naming convention? Do you have any rhyme or reason to your naming? Where do you see that my method can improve. Let this be a general platform for all things relevant to naming!
3X_d_c_dc5ab3fc13af582a5cbf3d2861362489343e2816.png

1 1 515
1 REPLY 1

I came here with the very same question and for the very same reason. I have realized that my naming for Slices, Actions and Format Rules especially need to be a little more consistent and structured and as I build things bigger, I am losing track of what things do.

Views I am fairly comfortable with, basing the naming on the dataset and following the โ€œFormโ€, โ€œInlineโ€ and such like that AppSheet defaults to doing and trying to be consistent with the use of underscores. The data tables themselves again is not a problem; I just stick to the singular names for the object type.

I know itโ€™s bad when I have an Action called โ€œDo something else 3โ€

Top Labels in this Space