Good Namingconvention?
# help-with-umbraco
p
Hey umbracians! I've wanted to know if anyone has a good Naming Convention written down for the most Umbraco Items like, Pages, Block List Elements, Block Grid Elements, Macros, Compositions and so on. How do you name them? Do you have anything manifested how you always call them? Some examples: HeadingComposition, CarouselBlock,
d
Well, you pretty much captured my naming convention. If it's used as a composition, call [something]Composition. If it's used in a blocklist/blockgrid, call it [something]Block. If it's a page, call it [Something]Page. Or at least the alias is named like that. For the display name, I usually make it something that reads comfortably. Usually starting with a word that I will likely look for first. So anything related to related content will start with 'Related Content' and anything related to news will start with 'news'. Other displaynames, for example for blocks, are written to form sentences that are convenient to read for content editors. One good example is a blocklist for for example a sitemap in the footer. The alias could be 'footerSitemapColumn', whereas the display name could simply be 'column', so that in the content section, the blocklist add button reads: 'Add new column'. This also requires a vertically sliced folder structure for document types, otherwise you get lost in the various document types called 'column'.
k
+1 to this. We use aliases that are useful for developers (
hugeHeroBlock
) and display names that are useful to editors (
Huge Hero
).
m
I always prefix the alias'
ElementXxx
and
CompositionXxx
so that they are nicely arranged when models are generated. Also helps with intellisense, I can type "Element" and have a list of my elements
For pages, I am still undecided, as templates get generated as well and "PageHome" or "PageHomePage" doesn't really feel super nice
d
Ohhh I like this approach, I should try that out.
m
I actually just finished writing a notification handler which checks if there is a parent folder with the name "Element" or "Composition" and then enforces the naming policy so you only need to type the "friendly" name, and not mess about with changing the alias manually. For Elements, it also creates a template file in the block list area
d
Oooooo
I did a different thing, I wrote a set of automated tests that check all our conventions on all document types and datatypes. Somewhat similar
p
Thanks everyone for your help! Some really intersting approaches!
o
Amazing ideas in this post. Good idea with the Notification Handler @Matthew
m
I've got a few things like that to keep things clean and tidy. I've made a datatype handler which categorises newly created data types into folders. It's kinda useful since there is no way to specify a folder when you create a new data type from a content type property editor
o
Ahh yes. You have to do it beforehand if you want to organize it
h
I use the same approach as @Matthew - "CompHero" "CompPageSettings", "Element...", and also I use "Block...". For "pages" or other items like settings nodes, I don't have a convention, but I haven't found that to be an issue. I also use some folders for organizing Doctypes - "Compositions" and "Blocks" (with some subfolders in Blocks to differentiate a bit). For DataTypes, I tend to name them based on the property editor, then with some info about configuration ("MNTP - News", "MNTP - Blog Posts", "Textarea - 2 rows", "Media - Image [Single]" , etc.) this makes it easy to reuse DataTypes when creating new Document Types.