Re: Implementation of boolean types.

From: dawn <dawnwolthuis_at_gmail.com>
Date: 14 Jul 2005 09:01:57 -0700
Message-ID: <1121356917.385228.319240_at_g47g2000cwa.googlegroups.com>


-CELKO- wrote:
> >> When ISO came up with this standard, what percentage of existing databases provided more than two possible values for gender? <<
>
> The problem was that too many databases were using the local language
> equivalent of 'M' and 'F' and could not exchange data, nor model a
> corporation nor show a missing value. This code was designed for
> normal usage, not medical freaks.
>
> >> I don't know how we are going to get past the underscores in attribute names vs camelCase names issue, however. I'd appreciate more consistency in naming throughout an application and camelCase is here to stay. <<
>
> Get a copy of SQL PROGRAMMING STYLE

I have a copy and paid money for it too -- I HAVE read your entire treatment of this subject. I simply disagree.

> for some of the details about
> readable names. For example, camelCase is worse and you can measure it
> with eye movement studies.

and that should, indeed, be a factor in the decision, but not the sole factor. Upper case is much harder to read than lower case, but there are good times to use all upper, none-the-less.

> The eye is attracted to an uppercase letter
> because it marks the start of a sentence or a noun. Then the eye has
> to twitch back left to the start of the word.

Yup. But surely this is not the only requirement for the standard.

> What makes this really bad is thart the second unit of the name is
> often a scale or other standardized postfix, as requred by ISO-11179
> rules. When you read "fooType" and "barType" you get confused because
> you processed the second unit first.

and if you roll a piano up next to me, I won't just be able to play Bach either.

> Effectively, your eye is saying
> "it's a TYPE, the last thing i read was FOO so I expect a FOO, wait!
> Nope! it's BAR. now I can move to the next unit of text after twitching
> this.".

You laid out the case for using the underscore. It is a good one, but not sufficient. Others standards have also been thought out. I don't know if UML standards indicate naming conventions, but the diagrams I have seen use the more OOP naming standards.

Ours is an industry where screws and screwdrivers insist on different standards, so we always need that screw-to-screwdriver tool in the middle. Then someone pipes up and says that is good because we want to decouple the screw and the screwdriver anyway. Think how easy it would be to build with a legos that were made with such an that approach. Heavy sigh.

--dawn Received on Thu Jul 14 2005 - 18:01:57 CEST

Original text of this message