Showing posts with label casing. Show all posts
Showing posts with label casing. Show all posts

Friday, February 10, 2012

Casing

What is the accepted way of Casing Table,Fields and Stored Procedures?
This is a real problem when mixing and matching.
For example, C uses lower case for everything, but when calling .Net
functions - you have to use Pascal Casing (1st Character of all words
Capitalized). In VB.Net, you use Pascal style for everthing but variables
where you use Camel Casing (1st Character of all ll words capitalized,
except the 1st word).
I tend to use Microsofts guidelines where everything but variables are
Pascal. Variables are Camel Casing. I never use and never liked Hungarian
(prefixed with variable type).
Celko mentioned the problem with Camel Casing being harder to read.
I have seen various ways of casing in Sql Server.
I have also seen various opinions on whether to pluralize table names
(Employees table instead of Employee table). I tend to pluralize myself,
but have seen guidlines that suggest it is better to use the singular form.
I see Sql statements both as SELECT and select, but haven't really seen any
definitive agreement on this.
Much of this just seems to be personal preference - which would be a real
problem in C as case is important.
Just curious.
Thanks,
TomSee my rules in SQL PROGRAMMING STYLE. They are based on ISO-11179,
human factors and readability research. It is a mater of a few decades
of research, not personal taste.
1) For table names, in order of preference
industry standard name - best
collective nouns (Personnel) -better
plural nouns (Employees) - bad
singluar (employee) - not usable, less the set has just one member
Capitalize it, as you would in English, German, etc. for proper names.
2) uppercase reserved words because they are read as a Bouma (single
unit of eye scan). The compiler will take care of typos.
3) lowercase scalars because they are longer and this easier to read
and less likely to be misspelt. Never use "camelCase" because the eye
jumps to the capital letter, then back to the start of the word.
The reason C is a "lowercase" language actually has to do with
teletypes! It is a physical effort to hold down the shift key and when
you are a two-finger typists, you don't want to write anything very
long.|||"--CELKO--" <jcelko212@.earthlink.net> wrote in message
news:1125333962.715849.259610@.g47g2000cwa.googlegroups.com...
> See my rules in SQL PROGRAMMING STYLE. They are based on ISO-11179,
> human factors and readability research. It is a mater of a few decades
> of research, not personal taste.
> 1) For table names, in order of preference
> industry standard name - best
> collective nouns (Personnel) -better
> plural nouns (Employees) - bad
> singluar (employee) - not usable, less the set has just one member
> Capitalize it, as you would in English, German, etc. for proper names.
I assume you are speaking Pascal casing here.

>
> 2) uppercase reserved words because they are read as a Bouma (single
> unit of eye scan). The compiler will take care of typos.
> 3) lowercase scalars because they are longer and this easier to read
> and less likely to be misspelt. Never use "camelCase" because the eye
> jumps to the capital letter, then back to the start of the word.
What about Pascal style for variables (fields), scalars?
CamelCase is used quite a bit and is the what was used for Hungarian
(although it has been pretty much being phased out of MS notation).

> The reason C is a "lowercase" language actually has to do with
> teletypes! It is a physical effort to hold down the shift key and when
> you are a two-finger typists, you don't want to write anything very
> long.
>
True.
Thanks,
Tom