I am a big standards guy. Not any particular standards, but ensuring you have some in your organization and that people stick to them. Pascal case, Camel case, it doesn't matter to me. I'll build a habit with any of them; I just want some consistency from others working in a team. Or even across teams since people move to different projects over time.

I ran across another post on naming conventions, this one looking at SQL standards, and it's a practical look at a few things. I like some of the ideas, like the singular or plural choice (" Who cares. Just pick one and use it consistently. "), but I especially like the idea of the third item: standard aliasing.

In the past, I've often found that I used the same aliases over and over. When I was the only DBA, this ensured consistency. "P" was always for dbo.Product, and pc was always used for ProductCategory. However, when we added other team members, I quickly realized we didn't use the same conventions. I'd check out code and see prod.productid instead of p.productid. The new people didn't like my single character aliases and I didn't like typing most of the word for theirs.

Ultimately we had to decide what made sense for both of us and compromise. We choose specific items, not all at once, but as needed. We'd have a 30s meeting or exchange a quick chat message and then update a document with the standards. When other new developers were hired, they already had a reference list that they quickly learned.

I think the idea of standard aliases makes sense. It's built into SQL Prompt and some other tools, precisely because many teams want to ensure their developers adhere to a standard, and more importantly, can quickly understand any code they pick up. That's the real reason for standards: they convey information, silently and quickly.