My first rule after no reserved words and special characters is no underscore in names.
The underscore is too strong a separator because we rely mostly on the top of characters to recognise them quickly. A name should hang together and variants of CamelCase do a better job.
The underscore is also used in modules to separate the object from the event. And the default names on imported tables from MS SQL Server. And the aliases in the query designer when including the same table twice.
but when you are writimng queries in database directly, there is a problem with CamelCase, in postgres you have to use quotes "" to say to application that you want to use exact field name.
Just an FYI, once the table is linked in Access, you can rename the Access linked table to whatever you want. I usually use a SQL backend, in which case Access by default replaces the schema separator with an underscore, so dbo.Employees becomes dbo_Employees. First thing I do after linking a new table is rename the linked table to Employees. (Access maintains the name of the target table in your PostgreSQL/MySQL/MSSQL db within other properties: this does not affect what table is linked to when you change the name).
I'm not sure what using quotes with CamelCase has to do with naming conventions... doesn't make sense that if you use CamelCase, you have to also include the quotes (as opposed to any other convention...). In SQL Server (and Access), an object with a name as a reserved word can be explicitly noted by using square brackets: [dbo].
.[Description]... is that what you're asking about?
I know MySQL tends to prefer backticks: `MyField` (which I always found rather ridiculous, along with the look_im_a_php_and_mysql_developer convention).
Anyway, CamelCase (or PascalCase if you prefer, some people consider camelCaseToStartWithALowercase) tends to be the norm for most Windows-based development.
Also: while underscores are low on my list as a matter of personal preference, they're generally harmless except: do be careful of anything that starts with an underscore, as this has special significance internally.
but when you are writimng queries in database directly, there is a problem with CamelCase, in postgres you have to use quotes "" to say to application that you want to use exact field name.
This enables the use of double quotes as object delimiters and single quotes around strings. With it this setting OFF the T-SQL naming standard must be used. This the same as Access where names with spaces or special characters must be delimited with square brackets and either double or single quotes can be used for string delimiters.
Query and Table definitions for ODBC Data Connections in Excel use the quoted identifiers.
I use CamelCase because except for the definition of a variable, I never have to use the shift key. Access proper cases the name when I complete the statement. If it doesn't, I know I've made a typo. Aside from requiring a shift, I also think the underscore is to strong a separator. I do occasionally use it when I want a strong separation but that is rare.
Actually, there are times when you have to remember to type the case correctly anyway because sometimes auto-correct corrects the wrong way.
IF you have a mixed-case ENUM statement (to give names to possible integer values that represent symbolic states via numbers), and if you type the declaration in mixed case, but THEN at some point type the enumerated name in all lowercase, ALL INSTANCES of the ENUM name go back to lower case. If you then go back to the original definition and type it correctly, that fixes it. But it is truly BIZARRE the first time you see that happen.
Actually, there are times when you have to remember to type the case correctly anyway because sometimes auto-correct corrects the wrong way.
IF you have a mixed-case ENUM statement (to give names to possible integer values that represent symbolic states via numbers), and if you type the declaration in mixed case, but THEN at some point type the enumerated name in all lowercase, ALL INSTANCES of the ENUM name go back to lower case. If you then go back to the original definition and type it correctly, that fixes it. But it is truly BIZARRE the first time you see that happen.
As a quick workaround, you can use the fully qualified enum name instead of just member:
Code:
Public Enum SomeStuff
StuffThis = 0
StuffThat = 1
End Enum
Then write:
Code:
If SomeVar = somestuff.
... when you hit the dot you get the intellisense and can pick it out of the list. You don't have to worry about the caps in the enum name (it's only an IDE bug for the members), and it's still faster/easier (IMO) than trying to write the perfect casing every time (especially when the member names are long)
I think the only place it doesn't work is within a case statement, but I still do this then a few quick keystokes to hop back and delete the left qualifier, still works pretty well.
OTOH, I'm a huge advocate of fully qualified naming, and even use it with modules and procedures. Much less to remember (https://dymeng.com/module-naming/)