|
|
Our Hot Pick: Rising Antivirus 2006 - Certified by TUV & Checkmark! Get 10% discount by entering this coupon code: ONDISCOUNT10
I still don't buy that this is either product-specific or amateur-specific.
I've seen countless numbers of experienced, formally trained (and who
learned it on their own) database programmers on every platform I've ever
used who use "tbl" for tables, "vw" for views, "usp" for user stored
procedures, not to mention "frm" for forms, "rpt" for reports, etc., ad
nauseum.
Personally, I don't see the point of starting ALL objects in a category with
the same letters; that's generally redundant (though occasionally useful
when you're trying to distinguish between views and tables, etc.). My
general preference is to base it around the function of the object. "acct"
for account-related tables, "resp" for respondent-related tables, "list" for
simple lookup-type tables, etc. Only for objects that don't have a
significant inter-relationship with the rest of the database (i.e.,
localization tables, user preferences, etc.) do I use the generic "tbl",
"frm", or whatever.
And while "tbl" itself may have first appeared in a Smart Access article in
1993, as I said, Hungarian notation itself pre-dates that. As I said,
Simonyi Károly (aka Charles Simonyi) did indeed work at Microsoft, but he
started Hungarian Notation back when he was working for Xerox. It's hardly
a surprise that it later appeared in a Microsoft product that he worked on.
Hell, ignore Hungarian notation for a moment, how long ago did people start
using "i" for integer? "For i = " was one of the first constructs I learned
almost 30 years ago.
Rob
"Craig Alexander Morrison" <cam[ at ]microsoft.newsgroups.public.com> wrote in
message news:ulTN4sYpGHA.4236[ at ]TK2MSFTNGP03.phx.gbl...
[Quoted Text] >> Oh and just for the record, Hungarian Notation became popular with
>> languages like VB/VBA, but actually pre-dates it. The inventor, Simonyi
>> Károly, was working for Xerox at the time and only much later did he move
>> to Microsoft.
>
> For the record "tbl" and other such fripperies first appeared in a 1993
> Smart Access article and has subsequently appeared in the ADH books. I
> don't
> mind one using tags in code but not for database objects. Charles Simonyi
> actually worked on Access 1; I am not sure what he thinks of the
> Lesynski/Reddick extensions.
>
> It is a good sign of an amateur with limited experience of other products.
> Some amateurs are very good programmers though.
>
> Nearly all formally trained Relational (or SQL) Database designers would
> find this "tbl" tag laughable.
>
> --
> Slainte
>
> Craig Alexander Morrison
> Crawbridge Data (Scotland) Limited
>
> "Robert Morley" <rmorley[ at ]magma.ca.N0.Freak1n.sparn> wrote in message
> news:%237AzQEWpGHA.3288[ at ]TK2MSFTNGP03.phx.gbl...
>> Like I said, different ways of thinking. I look at most of your points
>> and disagree with them either in part or in whole, but frankly, this
>> isn't
>> the place to get into this kind of discussion. The original post has
>> been
>> answered with two different solutions, and that's the end of it as far as
>> I'm concerned. I just bitched someone else out in another NG for exactly
>> this kind of "mine is bigger than yours" discussion that serves no
>> purpose
>> but to bicker pointlessly. Everybody's got their favourite apps and the
>> apps they think are toys, we simply disagree on which ones are which.
>>
>> :)
>>
>>
>>
>> Rob
>>
>> "Tim Ferguson" <FergusonTG[ at ]softhome.net> wrote in message
>> news:Xns97FDE698BF5FFgarbleme4455656[ at ]207.46.248.16...
>>> "Robert Morley" <rmorley[ at ]magma.ca.N0.Freak1n.sparn> wrote in
>>> news:uu9k#kPpGHA.1140[ at ]TK2MSFTNGP05.phx.gbl:
>>>
>>>> Obviously someone thought so, or they never would've designed combo
>>>> box lookups to work in tables.
>>>
>>> There are several things in Access that relegate it into the "toy"
>>> platform in the eyes of other database developers on "real" systems. The
>>> quaint but misguided fashion for putting "tbl" in front of object names
>>> is one; the presence of the "look up field" is another. I regret this
>>> because when you get up close, Jet is a pretty fine database engine and
>>> Access is a flexible and usable rapid development platform, but it will
>>> continue to get a rotten press as long as it's aimed at the Janet and
>>> John level of user. The type of users, in effect, that get drowned in
>>> any
>>> case as soon as they step off the dumb-spreadsheet kind of appliction.
>>>
>>> FWIW, it seems that the Access-as-toy party has won the debate because
>>> Jet development is being taken over by the Access UI team. I think it's
>>> time to be off to MySQL before they put in the paper clip telling you
>>> not
>>> to put financial data into an integer field.
>>>
>>>> What it really comes down to is that each of us has our own opinions
>>>> and ways of doing things. Don't get upset with someone just because
>>>> they think and work differently than you do.
>>>
>>> I get upset because of two things. Firstly, posts like yours may be seen
>>> by people who know about databases but not much about Access, who will
>>> merely have their suspicions confirmed that access is a plaything for
>>> people who don't know their way round Codd or Date. The second reason is
>>> that they may be seen by people who don't know much about Access or
>>> databases, and who will then think this is a good and reasonable way to
>>> use it; and whose horizons will forever be shortened.
>>>
>>> All the best
>>>
>>>
>>> Tim F
>>>
>>
>>
>
>
|
|
If the debates are pointless, why are you adding to them? Name things as
you choose. For myself it would be confusing if account-related tables,
queries, forms, and reports all start with the same prefix, but that's just
my preference.
"Robert Morley" <rmorley[ at ]magma.ca.N0.Freak1n.sparn> wrote in message
news:uhstMLcpGHA.4912[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text] >I still don't buy that this is either product-specific or amateur-specific.
>I've seen countless numbers of experienced, formally trained (and who
>learned it on their own) database programmers on every platform I've ever
>used who use "tbl" for tables, "vw" for views, "usp" for user stored
>procedures, not to mention "frm" for forms, "rpt" for reports, etc., ad
>nauseum.
>
> Personally, I don't see the point of starting ALL objects in a category
> with the same letters; that's generally redundant (though occasionally
> useful when you're trying to distinguish between views and tables, etc.).
> My general preference is to base it around the function of the object.
> "acct" for account-related tables, "resp" for respondent-related tables,
> "list" for simple lookup-type tables, etc. Only for objects that don't
> have a significant inter-relationship with the rest of the database (i.e.,
> localization tables, user preferences, etc.) do I use the generic "tbl",
> "frm", or whatever.
>
> And while "tbl" itself may have first appeared in a Smart Access article
> in 1993, as I said, Hungarian notation itself pre-dates that. As I said,
> Simonyi Károly (aka Charles Simonyi) did indeed work at Microsoft, but he
> started Hungarian Notation back when he was working for Xerox. It's
> hardly a surprise that it later appeared in a Microsoft product that he
> worked on. Hell, ignore Hungarian notation for a moment, how long ago did
> people start using "i" for integer? "For i = " was one of the first
> constructs I learned almost 30 years ago.
>
>
> Rob
>
> "Craig Alexander Morrison" <cam[ at ]microsoft.newsgroups.public.com> wrote in
> message news:ulTN4sYpGHA.4236[ at ]TK2MSFTNGP03.phx.gbl...
>>> Oh and just for the record, Hungarian Notation became popular with
>>> languages like VB/VBA, but actually pre-dates it. The inventor, Simonyi
>>> Károly, was working for Xerox at the time and only much later did he
>>> move
>>> to Microsoft.
>>
>> For the record "tbl" and other such fripperies first appeared in a 1993
>> Smart Access article and has subsequently appeared in the ADH books. I
>> don't
>> mind one using tags in code but not for database objects. Charles Simonyi
>> actually worked on Access 1; I am not sure what he thinks of the
>> Lesynski/Reddick extensions.
>>
>> It is a good sign of an amateur with limited experience of other
>> products.
>> Some amateurs are very good programmers though.
>>
>> Nearly all formally trained Relational (or SQL) Database designers would
>> find this "tbl" tag laughable.
>>
>> --
>> Slainte
>>
>> Craig Alexander Morrison
>> Crawbridge Data (Scotland) Limited
>>
>> "Robert Morley" <rmorley[ at ]magma.ca.N0.Freak1n.sparn> wrote in message
>> news:%237AzQEWpGHA.3288[ at ]TK2MSFTNGP03.phx.gbl...
>>> Like I said, different ways of thinking. I look at most of your points
>>> and disagree with them either in part or in whole, but frankly, this
>>> isn't
>>> the place to get into this kind of discussion. The original post has
>>> been
>>> answered with two different solutions, and that's the end of it as far
>>> as
>>> I'm concerned. I just bitched someone else out in another NG for
>>> exactly
>>> this kind of "mine is bigger than yours" discussion that serves no
>>> purpose
>>> but to bicker pointlessly. Everybody's got their favourite apps and the
>>> apps they think are toys, we simply disagree on which ones are which.
>>>
>>> :)
>>>
>>>
>>>
>>> Rob
>>>
>>> "Tim Ferguson" <FergusonTG[ at ]softhome.net> wrote in message
>>> news:Xns97FDE698BF5FFgarbleme4455656[ at ]207.46.248.16...
>>>> "Robert Morley" <rmorley[ at ]magma.ca.N0.Freak1n.sparn> wrote in
>>>> news:uu9k#kPpGHA.1140[ at ]TK2MSFTNGP05.phx.gbl:
>>>>
>>>>> Obviously someone thought so, or they never would've designed combo
>>>>> box lookups to work in tables.
>>>>
>>>> There are several things in Access that relegate it into the "toy"
>>>> platform in the eyes of other database developers on "real" systems.
>>>> The
>>>> quaint but misguided fashion for putting "tbl" in front of object names
>>>> is one; the presence of the "look up field" is another. I regret this
>>>> because when you get up close, Jet is a pretty fine database engine and
>>>> Access is a flexible and usable rapid development platform, but it will
>>>> continue to get a rotten press as long as it's aimed at the Janet and
>>>> John level of user. The type of users, in effect, that get drowned in
>>>> any
>>>> case as soon as they step off the dumb-spreadsheet kind of appliction.
>>>>
>>>> FWIW, it seems that the Access-as-toy party has won the debate because
>>>> Jet development is being taken over by the Access UI team. I think it's
>>>> time to be off to MySQL before they put in the paper clip telling you
>>>> not
>>>> to put financial data into an integer field.
>>>>
>>>>> What it really comes down to is that each of us has our own opinions
>>>>> and ways of doing things. Don't get upset with someone just because
>>>>> they think and work differently than you do.
>>>>
>>>> I get upset because of two things. Firstly, posts like yours may be
>>>> seen
>>>> by people who know about databases but not much about Access, who will
>>>> merely have their suspicions confirmed that access is a plaything for
>>>> people who don't know their way round Codd or Date. The second reason
>>>> is
>>>> that they may be seen by people who don't know much about Access or
>>>> databases, and who will then think this is a good and reasonable way to
>>>> use it; and whose horizons will forever be shortened.
>>>>
>>>> All the best
>>>>
>>>>
>>>> Tim F
>>>>
>>>
>>>
>>
>>
>
>
|
|
.....spoke too soon....
See original thread. (vbg)
--
Slainte
Craig Alexander Morrison
Crawbridge Data (Scotland) Limited
"BruceM" <bamoob[ at ]yawwhodawtcalm.not> wrote in message
news:uid3uTcpGHA.2400[ at ]TK2MSFTNGP03.phx.gbl...
[Quoted Text] > If the debates are pointless, why are you adding to them? Name things as
> you choose. For myself it would be confusing if account-related tables,
> queries, forms, and reports all start with the same prefix, but that's
> just my preference.
>
> "Robert Morley" <rmorley[ at ]magma.ca.N0.Freak1n.sparn> wrote in message
> news:uhstMLcpGHA.4912[ at ]TK2MSFTNGP05.phx.gbl...
>>I still don't buy that this is either product-specific or
>>amateur-specific. I've seen countless numbers of experienced, formally
>>trained (and who learned it on their own) database programmers on every
>>platform I've ever used who use "tbl" for tables, "vw" for views, "usp"
>>for user stored procedures, not to mention "frm" for forms, "rpt" for
>>reports, etc., ad nauseum.
>>
>> Personally, I don't see the point of starting ALL objects in a category
>> with the same letters; that's generally redundant (though occasionally
>> useful when you're trying to distinguish between views and tables, etc.).
>> My general preference is to base it around the function of the object.
>> "acct" for account-related tables, "resp" for respondent-related tables,
>> "list" for simple lookup-type tables, etc. Only for objects that don't
>> have a significant inter-relationship with the rest of the database
>> (i.e., localization tables, user preferences, etc.) do I use the generic
>> "tbl", "frm", or whatever.
>>
>> And while "tbl" itself may have first appeared in a Smart Access article
>> in 1993, as I said, Hungarian notation itself pre-dates that. As I said,
>> Simonyi Károly (aka Charles Simonyi) did indeed work at Microsoft, but he
>> started Hungarian Notation back when he was working for Xerox. It's
>> hardly a surprise that it later appeared in a Microsoft product that he
>> worked on. Hell, ignore Hungarian notation for a moment, how long ago did
>> people start using "i" for integer? "For i = " was one of the first
>> constructs I learned almost 30 years ago.
>>
>>
>> Rob
>>
>> "Craig Alexander Morrison" <cam[ at ]microsoft.newsgroups.public.com> wrote in
>> message news:ulTN4sYpGHA.4236[ at ]TK2MSFTNGP03.phx.gbl...
>>>> Oh and just for the record, Hungarian Notation became popular with
>>>> languages like VB/VBA, but actually pre-dates it. The inventor,
>>>> Simonyi
>>>> Károly, was working for Xerox at the time and only much later did he
>>>> move
>>>> to Microsoft.
>>>
>>> For the record "tbl" and other such fripperies first appeared in a 1993
>>> Smart Access article and has subsequently appeared in the ADH books. I
>>> don't
>>> mind one using tags in code but not for database objects. Charles
>>> Simonyi
>>> actually worked on Access 1; I am not sure what he thinks of the
>>> Lesynski/Reddick extensions.
>>>
>>> It is a good sign of an amateur with limited experience of other
>>> products.
>>> Some amateurs are very good programmers though.
>>>
>>> Nearly all formally trained Relational (or SQL) Database designers would
>>> find this "tbl" tag laughable.
>>>
>>> --
>>> Slainte
>>>
>>> Craig Alexander Morrison
>>> Crawbridge Data (Scotland) Limited
>>>
>>> "Robert Morley" <rmorley[ at ]magma.ca.N0.Freak1n.sparn> wrote in message
>>> news:%237AzQEWpGHA.3288[ at ]TK2MSFTNGP03.phx.gbl...
>>>> Like I said, different ways of thinking. I look at most of your points
>>>> and disagree with them either in part or in whole, but frankly, this
>>>> isn't
>>>> the place to get into this kind of discussion. The original post has
>>>> been
>>>> answered with two different solutions, and that's the end of it as far
>>>> as
>>>> I'm concerned. I just bitched someone else out in another NG for
>>>> exactly
>>>> this kind of "mine is bigger than yours" discussion that serves no
>>>> purpose
>>>> but to bicker pointlessly. Everybody's got their favourite apps and
>>>> the
>>>> apps they think are toys, we simply disagree on which ones are which.
>>>>
>>>> :)
>>>>
>>>>
>>>>
>>>> Rob
>>>>
>>>> "Tim Ferguson" <FergusonTG[ at ]softhome.net> wrote in message
>>>> news:Xns97FDE698BF5FFgarbleme4455656[ at ]207.46.248.16...
>>>>> "Robert Morley" <rmorley[ at ]magma.ca.N0.Freak1n.sparn> wrote in
>>>>> news:uu9k#kPpGHA.1140[ at ]TK2MSFTNGP05.phx.gbl:
>>>>>
>>>>>> Obviously someone thought so, or they never would've designed combo
>>>>>> box lookups to work in tables.
>>>>>
>>>>> There are several things in Access that relegate it into the "toy"
>>>>> platform in the eyes of other database developers on "real" systems.
>>>>> The
>>>>> quaint but misguided fashion for putting "tbl" in front of object
>>>>> names
>>>>> is one; the presence of the "look up field" is another. I regret this
>>>>> because when you get up close, Jet is a pretty fine database engine
>>>>> and
>>>>> Access is a flexible and usable rapid development platform, but it
>>>>> will
>>>>> continue to get a rotten press as long as it's aimed at the Janet and
>>>>> John level of user. The type of users, in effect, that get drowned in
>>>>> any
>>>>> case as soon as they step off the dumb-spreadsheet kind of appliction.
>>>>>
>>>>> FWIW, it seems that the Access-as-toy party has won the debate because
>>>>> Jet development is being taken over by the Access UI team. I think
>>>>> it's
>>>>> time to be off to MySQL before they put in the paper clip telling you
>>>>> not
>>>>> to put financial data into an integer field.
>>>>>
>>>>>> What it really comes down to is that each of us has our own opinions
>>>>>> and ways of doing things. Don't get upset with someone just because
>>>>>> they think and work differently than you do.
>>>>>
>>>>> I get upset because of two things. Firstly, posts like yours may be
>>>>> seen
>>>>> by people who know about databases but not much about Access, who will
>>>>> merely have their suspicions confirmed that access is a plaything for
>>>>> people who don't know their way round Codd or Date. The second reason
>>>>> is
>>>>> that they may be seen by people who don't know much about Access or
>>>>> databases, and who will then think this is a good and reasonable way
>>>>> to
>>>>> use it; and whose horizons will forever be shortened.
>>>>>
>>>>> All the best
>>>>>
>>>>>
>>>>> Tim F
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
|
|
Because my professional pride hates being insulted by being called an
amateur even more than I hate being drawn into pointless debates. :)
Rob
"BruceM" <bamoob[ at ]yawwhodawtcalm.not> wrote in message
news:uid3uTcpGHA.2400[ at ]TK2MSFTNGP03.phx.gbl...
[Quoted Text] > If the debates are pointless, why are you adding to them? Name things as
> you choose. For myself it would be confusing if account-related tables,
> queries, forms, and reports all start with the same prefix, but that's
> just my preference.
|
|
Like everything else in the world, to much is like not enough. When writing
some piece of code, you must write it in a way that will convey the maximum
quantity of useful information to the programmer but without cluttering the
whole thing, because at this point the process will become
counter-productive: instead of diminishing the possibility for the
programmer of writing a bug, it will increase it.
« how long ago did people start using "i" for integer? "For i = " was one
of the first constructs I learned almost 30 years ago. »
For those interested, this old notation came from the first commercial
version of Fortran and had then a functional purpose: all variables
beginning with one of the letters i, j, k, l, m and n (taken from the
enumeration i .. n corresponding to the first two letters of the word
INteger) were automatically declared to be of type integer and all others
were dimensionned as float by default.
In fact, in Fortran 4, I'm not even sure if you could dimension a variable
beginning with one of the letters i .. n to *not* be an integer. (Since my
old manual of Fortran 4 is gone since a very long time, I can't no longer
verify this point.) In Fortran 5, you can easily declare one of these
variables to not be an integer but still, if you don't say otherwise, they
will be of type integer by default.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF
"Robert Morley" <rmorley[ at ]magma.ca.N0.Freak1n.sparn> wrote in message
news:uhstMLcpGHA.4912[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text] >I still don't buy that this is either product-specific or amateur-specific.
>I've seen countless numbers of experienced, formally trained (and who
>learned it on their own) database programmers on every platform I've ever
>used who use "tbl" for tables, "vw" for views, "usp" for user stored
>procedures, not to mention "frm" for forms, "rpt" for reports, etc., ad
>nauseum.
>
> Personally, I don't see the point of starting ALL objects in a category
> with the same letters; that's generally redundant (though occasionally
> useful when you're trying to distinguish between views and tables, etc.).
> My general preference is to base it around the function of the object.
> "acct" for account-related tables, "resp" for respondent-related tables,
> "list" for simple lookup-type tables, etc. Only for objects that don't
> have a significant inter-relationship with the rest of the database (i.e.,
> localization tables, user preferences, etc.) do I use the generic "tbl",
> "frm", or whatever.
>
> And while "tbl" itself may have first appeared in a Smart Access article
> in 1993, as I said, Hungarian notation itself pre-dates that. As I said,
> Simonyi Károly (aka Charles Simonyi) did indeed work at Microsoft, but he
> started Hungarian Notation back when he was working for Xerox. It's
> hardly a surprise that it later appeared in a Microsoft product that he
> worked on. Hell, ignore Hungarian notation for a moment, how long ago did
> people start using "i" for integer? "For i = " was one of the first
> constructs I learned almost 30 years ago.
>
>
> Rob
>
> "Craig Alexander Morrison" <cam[ at ]microsoft.newsgroups.public.com> wrote in
> message news:ulTN4sYpGHA.4236[ at ]TK2MSFTNGP03.phx.gbl...
>>> Oh and just for the record, Hungarian Notation became popular with
>>> languages like VB/VBA, but actually pre-dates it. The inventor, Simonyi
>>> Károly, was working for Xerox at the time and only much later did he
>>> move
>>> to Microsoft.
>>
>> For the record "tbl" and other such fripperies first appeared in a 1993
>> Smart Access article and has subsequently appeared in the ADH books. I
>> don't
>> mind one using tags in code but not for database objects. Charles Simonyi
>> actually worked on Access 1; I am not sure what he thinks of the
>> Lesynski/Reddick extensions.
>>
>> It is a good sign of an amateur with limited experience of other
>> products.
>> Some amateurs are very good programmers though.
>>
>> Nearly all formally trained Relational (or SQL) Database designers would
>> find this "tbl" tag laughable.
>>
>> --
>> Slainte
>>
>> Craig Alexander Morrison
>> Crawbridge Data (Scotland) Limited
>>
>> "Robert Morley" <rmorley[ at ]magma.ca.N0.Freak1n.sparn> wrote in message
>> news:%237AzQEWpGHA.3288[ at ]TK2MSFTNGP03.phx.gbl...
>>> Like I said, different ways of thinking. I look at most of your points
>>> and disagree with them either in part or in whole, but frankly, this
>>> isn't
>>> the place to get into this kind of discussion. The original post has
>>> been
>>> answered with two different solutions, and that's the end of it as far
>>> as
>>> I'm concerned. I just bitched someone else out in another NG for
>>> exactly
>>> this kind of "mine is bigger than yours" discussion that serves no
>>> purpose
>>> but to bicker pointlessly. Everybody's got their favourite apps and the
>>> apps they think are toys, we simply disagree on which ones are which.
>>>
>>> :)
>>>
>>>
>>>
>>> Rob
>>>
>>> "Tim Ferguson" <FergusonTG[ at ]softhome.net> wrote in message
>>> news:Xns97FDE698BF5FFgarbleme4455656[ at ]207.46.248.16...
>>>> "Robert Morley" <rmorley[ at ]magma.ca.N0.Freak1n.sparn> wrote in
>>>> news:uu9k#kPpGHA.1140[ at ]TK2MSFTNGP05.phx.gbl:
>>>>
>>>>> Obviously someone thought so, or they never would've designed combo
>>>>> box lookups to work in tables.
>>>>
>>>> There are several things in Access that relegate it into the "toy"
>>>> platform in the eyes of other database developers on "real" systems.
>>>> The
>>>> quaint but misguided fashion for putting "tbl" in front of object names
>>>> is one; the presence of the "look up field" is another. I regret this
>>>> because when you get up close, Jet is a pretty fine database engine and
>>>> Access is a flexible and usable rapid development platform, but it will
>>>> continue to get a rotten press as long as it's aimed at the Janet and
>>>> John level of user. The type of users, in effect, that get drowned in
>>>> any
>>>> case as soon as they step off the dumb-spreadsheet kind of appliction.
>>>>
>>>> FWIW, it seems that the Access-as-toy party has won the debate because
>>>> Jet development is being taken over by the Access UI team. I think it's
>>>> time to be off to MySQL before they put in the paper clip telling you
>>>> not
>>>> to put financial data into an integer field.
>>>>
>>>>> What it really comes down to is that each of us has our own opinions
>>>>> and ways of doing things. Don't get upset with someone just because
>>>>> they think and work differently than you do.
>>>>
>>>> I get upset because of two things. Firstly, posts like yours may be
>>>> seen
>>>> by people who know about databases but not much about Access, who will
>>>> merely have their suspicions confirmed that access is a plaything for
>>>> people who don't know their way round Codd or Date. The second reason
>>>> is
>>>> that they may be seen by people who don't know much about Access or
>>>> databases, and who will then think this is a good and reasonable way to
>>>> use it; and whose horizons will forever be shortened.
>>>>
>>>> All the best
>>>>
>>>>
>>>> Tim F
>>>>
>>>
>>>
>>
>>
>
>
|
|
Is that where we get it from? I never knew! Apparently you've been
programming even longer than I have! ;)
Rob
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:uqvv8fcpGHA.4368[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text] > « how long ago did people start using "i" for integer? "For i = " was > one of the first constructs I learned almost 30 years ago. » > > For those interested, this old notation came from the first commercial > version of Fortran and had then a functional purpose: all variables > beginning with one of the letters i, j, k, l, m and n (taken from the > enumeration i .. n corresponding to the first two letters of the word > INteger) were automatically declared to be of type integer and all others > were dimensionned as float by default. > > In fact, in Fortran 4, I'm not even sure if you could dimension a variable > beginning with one of the letters i .. n to *not* be an integer. (Since > my old manual of Fortran 4 is gone since a very long time, I can't no > longer verify this point.) In Fortran 5, you can easily declare one of > these variables to not be an integer but still, if you don't say > otherwise, they will be of type integer by default. > > -- > Sylvain Lafontaine, ing. > MVP - Technologies Virtual-PC > E-mail: http://cerbermail.com/?QugbLEWINF
|
|
|
[Quoted Text] > Like everything else in the world, to much is like not enough. When
> writing some piece of code, you must write it in a way that will convey
> the maximum quantity of useful information to the programmer but without
> cluttering the whole thing, because at this point the process will become
> counter-productive: instead of diminishing the possibility for the
> programmer of writing a bug, it will increase it.
Actually, I found a hilarious web page about that by yet another Canadian:
http://mindprod.com/jgloss/unmainnaming.html
|
|
I looked through the other thread. I have to say I'm puzzled that a naming
convention would sort of cheapen the program in the view of some. I'm not
clear if those who think poorly of using prefixes for objects would prefer
no naming convention at all, or what exactly, but in any case it seems in
rather a different category than lookup fields in tables.
When I first started learning about Access I was taught to put prefixes onto
fields (txt for a Text field, dat for Date/Time, and like that), but I soon
discovered that I much prefer to use prefixes for controls in particular. I
also use them prefixes objects, so I therefore know that if it does not have
a prefix it is a field. Works for me, even if it offends some.
Best regards.
"Robert Morley" <rmorley[ at ]magma.ca.N0.Freak1n.sparn> wrote in message
news:%231PvFYcpGHA.4812[ at ]TK2MSFTNGP04.phx.gbl...
[Quoted Text] > Because my professional pride hates being insulted by being called an
> amateur even more than I hate being drawn into pointless debates. :)
>
>
> Rob
>
> "BruceM" <bamoob[ at ]yawwhodawtcalm.not> wrote in message
> news:uid3uTcpGHA.2400[ at ]TK2MSFTNGP03.phx.gbl...
>> If the debates are pointless, why are you adding to them? Name things as
>> you choose. For myself it would be confusing if account-related tables,
>> queries, forms, and reports all start with the same prefix, but that's
>> just my preference.
>
>
>
|
|
"Robert Morley" <rmorley[ at ]magma.ca.N0.Freak1n.sparn> wrote in
news:uhstMLcpGHA.4912[ at ]TK2MSFTNGP05.phx.gbl:
[Quoted Text] > And while "tbl" itself may have first appeared in a Smart Access
> article in 1993, as I said, Hungarian notation itself pre-dates that.
> As I said, Simonyi K roly (aka Charles Simonyi) did indeed work at
> Microsoft, but he started Hungarian Notation back when he was working
> for Xerox.
For a good description of the history of "systems Hungarian" and its
misapplication see Joel on Software:
http://www.joelonsoftware.com/articles/Wrong.html
Tim F
|
|
"BruceM" wrote:
[Quoted Text] > If the debates are pointless, why are you adding to them?
Arguing with programmers is like wrestling with a pig in the mud.
After a few hours, you realize that the pig likes it.
|
|
Good article, though I was already aware of the differentiation between
Systems & Apps Hungarian (though I can never remember their formal titles
until I re-read articles such as that one...the names just never made sense
to me).
Going back to the "tbl" concept, though, at some point in this long chain of
messages over multiple threads, I seem to remember stating that I only use
"tbl" for generic tables that have no other logical grouping within my
database (or code, or whatever it is I'm looking at), and that I tend to
group and name tables by logical function ("acct", "resp", etc.)
otherwise...that it seemed a little redundant to name everything of a
certain object type or data type with the same prefix. Isn't that basically
what the article is advocating?
I *do* consider Systems Hungarian to be a perfectly valid alternative for
those that find it's useful to them, though for what I do, I find it a
little limited in its own right. My personal preference is to use a hybrid
of systems & apps when coding, where the first lower-case prefix is
descriptive of the data type (with reasonable exceptions...I don't know
ANYBODY who uses something like lngHWnd), and the first upper-case prefix is
descriptive of the logical grouping, (i.e. strAcctFilename, which is very
obviously a string relating to an account, and is a file name). But there
are those who prefer Systems Hungarian, and as long as they keep it
localized to their own code/database/whatever and don't try to impose it on
mine, that's fine. (As you can imagine, I was NOT best pleased with the Web
developer who went and copied all my stored procedures that started with
"web" to indicate they were used on the Web to a simple "usp" prefix. Who
on earth ever gave System Administrator privileges to a *student* web
developer?!?)
Anyway, all things considered, I think we mostly just misunderstood each
other from the start of this conversation. You know what the say about
assumptions! :)
Rob
"Tim Ferguson" <FergusonTG[ at ]softhome.net> wrote in message
news:Xns97FED3B6FFD22garbleme4455656[ at ]207.46.248.16...
[Quoted Text]
|
|
|
[Quoted Text] > Arguing with programmers is like wrestling with a pig in the mud.
> After a few hours, you realize that the pig likes it.
Dare I ask how you came to this conclusion (about the pigs, that is, not the
programmers)? <grin>
Rob
|
|
"Robert Morley" wrote:
[Quoted Text] > > Arguing with programmers is like wrestling with a pig in the mud.
> > After a few hours, you realize that the pig likes it.
>
> Dare I ask how you came to this conclusion (about the pigs, that is, not the
> programmers)? <grin>
>
>
> Rob
After arguing with programmers, the pig was a nice break . . .
|
|
Hahaha...couldn't agree with you more!
Rob
"mnature" <mnature[ at ]discussions.microsoft.com> wrote in message
news:B07EAAFE-23F2-456A-B5AC-CF04D3C6C969[ at ]microsoft.com...
[Quoted Text] > "Robert Morley" wrote:
>
>> > Arguing with programmers is like wrestling with a pig in the mud.
>> > After a few hours, you realize that the pig likes it.
>>
>> Dare I ask how you came to this conclusion (about the pigs, that is, not
>> the
>> programmers)? <grin>
>>
>>
>> Rob
>
> After arguing with programmers, the pig was a nice break . . .
|
|
Robert Morley wrote:
[Quoted Text] > I've seen countless numbers of experienced, formally trained (and who
> learned it on their own) database programmers on every platform I've ever
> used who use "tbl" for tables, "vw" for views, "usp" for user stored
> procedures, not to mention "frm" for forms, "rpt" for reports, etc., ad
> nauseum.
I think the important word here is 'convention'.
It is an Access convention to prefix tables with 'tbl'. Wannabe Access
MVPs see established Access MVPs using the prefix so they imitate them;
in turn Access MVPs use the prefix because it's what their audience
expects i.e. to do Access things in an Access way.
Bottom line: use the 'tlb' prefix if you want to appear to be a true
blue Access user. How that affects your reputation as an amateur or
otherwise will largely be determined by where you are posting your
reply e.g. contrast the Microsoft.Public.Access.GettingStarted group
with comp.databases.theory.
My advice: if you want to appear as a 'serious' SQL database type
person, take a look at what people do outside of the Access ghetto.
You'll find the debate focuses on whether to pluralize table names
(e.g. Customer or Customers) and that prefixes are not rarely used at
all, other than as a hangover from a port from Access.
Jamie.
--
|
|
Robert Morley wrote:
[Quoted Text] > "tbl" for tables, "vw" for views
Another thought. Could using prefixes encourage the wrong mental model?
For example, using 'tbl' and 'vw' differentiates between a table and a
view (or 'qry for Query, to use the Access conventions). The difference
is physical whereas logically a view is a (virtual) table so why
differentiate at all? If I say SELECT last_name FROM Customers, why
would I care whether the table was virtual or otherwise? What value
does the prefix add?
Likewise the terms 'field' and 'record' which still prevail in the
Access world, rather than the respective terms 'column' and 'row'
preferred in the wider SQL world. Do these terms really encourage
people to think in terms file systems and sequential processing rather
than SQL databases and a set-based mental model?
Jamie.
--
|
|
Many people here will post examples of code using prefixes such as tbl or vw
only because they are writing only a few lines of code instead of a full
database and they need to make these very few lines to be a much clear as
possible; with no other background.
Myself, I often write here things MyTable or MyView; however, I will never
use the names MyTable or MyView in one of MyDatabase.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF
"Jamie Collins" <jamiecollins[ at ]xsmail.com> wrote in message
news:1152784361.148433.325570[ at ]35g2000cwc.googlegroups.com...
[Quoted Text] >
> Robert Morley wrote:
>> I've seen countless numbers of experienced, formally trained (and who
>> learned it on their own) database programmers on every platform I've ever
>> used who use "tbl" for tables, "vw" for views, "usp" for user stored
>> procedures, not to mention "frm" for forms, "rpt" for reports, etc., ad
>> nauseum.
>
> I think the important word here is 'convention'.
>
> It is an Access convention to prefix tables with 'tbl'. Wannabe Access
> MVPs see established Access MVPs using the prefix so they imitate them;
> in turn Access MVPs use the prefix because it's what their audience
> expects i.e. to do Access things in an Access way.
>
> Bottom line: use the 'tlb' prefix if you want to appear to be a true
> blue Access user. How that affects your reputation as an amateur or
> otherwise will largely be determined by where you are posting your
> reply e.g. contrast the Microsoft.Public.Access.GettingStarted group
> with comp.databases.theory.
>
> My advice: if you want to appear as a 'serious' SQL database type
> person, take a look at what people do outside of the Access ghetto.
> You'll find the debate focuses on whether to pluralize table names
> (e.g. Customer or Customers) and that prefixes are not rarely used at
> all, other than as a hangover from a port from Access.
>
> Jamie.
>
> --
>
|
|
Like I said, for myself, I don't generally stick to simply "tbl" or "vw" or
whatever unless there's no other logical prefix, but I can think of at least
one argument in favour of doing it that way: when you're looking at someone
else's code, you know EXACTLY where to go if you need to look at the design
of the table, view, SP, or whatever else.
The record/field vs. row/column discussion is something I've heard before,
and I've always thought that calling them rows & columns to look more
professional or well-educated was "bass-ackwards". To me, spreadsheets have
rows & columns; to apply those terms to a table is to relegate it to the
level of a spreadsheet (or at best, a pre-relational-database table).
But hey, I'll be the first to admit that I started out in Access and
expanded my expertise from there, so maybe my views are a little biased
towards the historical Access ways of doing things. :)
Rob
"Jamie Collins" <jamiecollins[ at ]xsmail.com> wrote in message
news:1152785248.577605.117840[ at ]m73g2000cwd.googlegroups.com...
[Quoted Text] >
> Robert Morley wrote:
>> "tbl" for tables, "vw" for views
>
> Another thought. Could using prefixes encourage the wrong mental model?
> For example, using 'tbl' and 'vw' differentiates between a table and a
> view (or 'qry for Query, to use the Access conventions). The difference
> is physical whereas logically a view is a (virtual) table so why
> differentiate at all? If I say SELECT last_name FROM Customers, why
> would I care whether the table was virtual or otherwise? What value
> does the prefix add?
>
> Likewise the terms 'field' and 'record' which still prevail in the
> Access world, rather than the respective terms 'column' and 'row'
> preferred in the wider SQL world. Do these terms really encourage
> people to think in terms file systems and sequential processing rather
> than SQL databases and a set-based mental model?
>
> Jamie.
>
> --
>
|
|
It's interesting how much of the discussion is about how using one system or
another will appear in the eyes of somebody else. I learned about a naming
convention that makes sense, so I started using it, and found it to be
helpful. It had nothing to do with being a "wannabe". Did you choose the
naming convention you use because you "wannabe" like somebody else? If not,
why do you assume that somebody using another naming convention is driven by
such a motivation?
"Jamie Collins" <jamiecollins[ at ]xsmail.com> wrote in message
news:1152784361.148433.325570[ at ]35g2000cwc.googlegroups.com...
[Quoted Text] >
> Robert Morley wrote:
>> I've seen countless numbers of experienced, formally trained (and who
>> learned it on their own) database programmers on every platform I've ever
>> used who use "tbl" for tables, "vw" for views, "usp" for user stored
>> procedures, not to mention "frm" for forms, "rpt" for reports, etc., ad
>> nauseum.
>
> I think the important word here is 'convention'.
>
> It is an Access convention to prefix tables with 'tbl'. Wannabe Access
> MVPs see established Access MVPs using the prefix so they imitate them;
> in turn Access MVPs use the prefix because it's what their audience
> expects i.e. to do Access things in an Access way.
>
> Bottom line: use the 'tlb' prefix if you want to appear to be a true
> blue Access user. How that affects your reputation as an amateur or
> otherwise will largely be determined by where you are posting your
> reply e.g. contrast the Microsoft.Public.Access.GettingStarted group
> with comp.databases.theory.
>
> My advice: if you want to appear as a 'serious' SQL database type
> person, take a look at what people do outside of the Access ghetto.
> You'll find the debate focuses on whether to pluralize table names
> (e.g. Customer or Customers) and that prefixes are not rarely used at
> all, other than as a hangover from a port from Access.
>
> Jamie.
>
> --
>
|
|
"Robert Morley" <rmorley[ at ]magma.ca.N0.Freak1n.sparn> wrote in
news:#G3EEpppGHA.1548[ at ]TK2MSFTNGP04.phx.gbl:
[Quoted Text] > Like I said, for myself, I don't generally stick to simply "tbl" or
> "vw" or whatever unless there's no other logical prefix, but I can
> think of at least one argument in favour of doing it that way: when
> you're looking at someone else's code, you know EXACTLY where to go if
> you need to look at the design of the table, view, SP, or whatever
> else.
Unless what used to be a table is now a view, (or vice versa, though less
likely). Access does not easily provide the tools to go hunting through
every reference to "tblSomething" and change it to "vwSomething". Nor,
for that matter, "txtDescriptionType" to "cboDescriptionType", but that
is a different argument.
> But hey, I'll be the first to admit that I started out in Access and
> expanded my expertise from there, so maybe my views are a little
> biased towards the historical Access ways of doing things. :)
To be fair, it was Microsoft itself that pushed Hungarian notation as its
own house style. I don't believe that the company ever understood how
good Access was and they don't seem to have cared either. As for the
programming style, they have now reverted completely, and prefixes are
AbsolutelyOut for anything based on the new versions of VisualStudio --
or should that be visualStudio?
All the best
Tim F
|
|
|
[Quoted Text] > Unless what used to be a table is now a view, (or vice versa, though less
> likely). Access does not easily provide the tools to go hunting through
> every reference to "tblSomething" and change it to "vwSomething". Nor,
> for that matter, "txtDescriptionType" to "cboDescriptionType", but that
> is a different argument.
Yes, I've run into that problem. I currently view called "tblPreferences",
which is a hanger-on from when tblPreferences was stored as a local table in
a replicated MDB, but then got upsized to SQL Server and had to be done as a
view based on the current user.
There are a number of good search & replace utilities for Access...for some
reason, I just haven't gotten around to using it on tblPreferences yet! :)
> To be fair, it was Microsoft itself that pushed Hungarian notation as its
> own house style. I don't believe that the company ever understood how
> good Access was and they don't seem to have cared either. As for the
> programming style, they have now reverted completely, and prefixes are
> AbsolutelyOut for anything based on the new versions of VisualStudio --
> or should that be visualStudio?
Yes, so I've heard. Personally, I don't give a rat's ass what's in or
out...as many have said, I use what works best for me (and since my
programming team at work is a whole two people, and I'm the lead programmer,
it pretty much works that way there, too <grin>).
Rob
|
|
|
[Quoted Text] > Yes, I've run into that problem. I currently view called
> "tblPreferences",
Ummm...apparently I'm just randomly dropping words from sentences. That was
supposed to read "I currently have a view", of course. <blush>
Rob
|
|
Robert Morley wrote:
[Quoted Text] > Like I said, for myself, I don't generally stick to simply "tbl" or "vw" or
> whatever unless there's no other logical prefix
He's a idea for you: if there is no *logical* prefix (i.e. the table's
name already conveys meaning) then don't use a prefix that conveys its
*physical* implementation. At best it's redundant, worse it's mixing
logical and physical models.
Jamie.
--
|
|
BruceM wrote:
[Quoted Text] > I learned about a naming
> convention that makes sense, so I started using it, and found it to be
> helpful.
Did you browse the whole 'naming conventions' aisle before making your
choice?
> It's interesting how much of the discussion is about how using one system or
> another will appear in the eyes of somebody else.
> Did you choose the
> naming convention you use because you "wannabe" like somebody else?
Of course. When I started dabbling in WordBasic, I used logical terms
for variable names; I was working in the office of the board of
directors and wore a blazer, slacks and smart shiny shoes to the
office.
I wanted to move into VBA software development so, to be taken
seriously by what I hoped would be my peers, I adopted the naming
convention lng- for Long Integer, str- for String, dtm- for Date, etc.
These prefixes did not add value for me personally: the variable name
told me how I was using it and hence conveyed the data type, the prefix
seemed to be redundant and jar.
Luckily in my SQL career I took the 'standard SQL' path from day one
and never got into the whole 'tbl', 'fields' and other Access
conventions. When I first started using .NET I was very relieved that
the convention has moved away from data type prefixes to logical
variable names; I still use the prefixes in VBA, though sometimes I
can't be bothered and stick with the .NET convention. I was amused the
other day to see an MVP using camelCase for their Access column -
sorry, field - names <g>.
And, yes, I use the standard SQL terms column (in place of 'field'),
VIEW (in place of 'Query'), 'DECIMAL' (in place of 'Currency' <g>), a
relational/industry standard key (in place of 'autonumber' <vbg>) to
encourage others to look outside of the Access ghetto in the hope they
may benefit as I have.
Oh and today I'm wearing a t-shirt and jeans (because sometimes you
need to fit in) with walking boots (because sometimes you need to do
what makes practical sense).
Jamie.
--
|
|
"Tim Ferguson" <FergusonTG[ at ]softhome.net> wrote in message
news:Xns97FFCA55CFDCCgarbleme4455656[ at ]207.46.248.16...
[Quoted Text] > programming style, they have now reverted completely, and prefixes are
> AbsolutelyOut for anything based on the new versions of VisualStudio --
> or should that be visualStudio?
>
I have to do a lot of vb.net work, and I find the new naming convention a
bit awkard. New MS articles insist on dropping the o for object, as
everything is an object now. And cls for class is gone as well, of course.
But there are still some 2003 and older articles amongst the help files,
where they have different naming conventions. But thats not too bad, its
easy enough to get used to.
My old way: Dim oClient as New clsClient
New way: Dim SalesClient as New Client
It does mean thinking of names though! Like having to use SalesClient in
this sample.
What really gets me is the names on forms. So instead of gridClients, its
now ClientsDataGridView. And then theres ClientNameTextBox. Its very hard to
get used to, after years of txtClientName!
In some ways it makes sense. All your Client objects are grouped together.
But I think I'll keep to the old ways in Access. Though I may not be able to
keep up two naming conventions for ever.
Diarmuid
|
|
Furthermore, FORTRAN, the FORmula TRANslation language, was often
used for formulas, where i,j, and k were indexes to an Array. This
was a notation that predated computers.
We got the word 'array' from the same source: if FORTRAN had not
been used by engineers and mathematicians, we probably would have
had a 'table' instead, which is what we now call that construct
when we use Access to save it to disk and read it back again.
(david)
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:uqvv8fcpGHA.4368[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text] > Like everything else in the world, to much is like not enough. When
> writing
|
|
It's a fact that the 'tables' and 'queries' are listed
on separate tabs. If they were all listed together, it
would make sense to totally drop the annotation: but
I share multiple databases with other developers, and
when you are looking for a view, you need to know if you
are in the wrong database, or just on the wrong page.
The terms 'field' and 'record' encourage me to think
in terms of card databases. I know that they were also
applied to file systems and sequential processing, but
they were never any more relevant there than they are
with SQL databases and set-based theory. Even the word
'file' was a barrier to people being introduced to 'file
systems': the concepts were too dissimilar to be helpful.
If they don't help with SQL, it's not because they are
bound to file/tape concepts: they never really worked
there either.
However, to be honest, you can use any sound to refer
to any concept. The real problem is that people use
language to define social groups, and social groups are
defined just as much by who you can exclude as by who
you include.
(david)
"Jamie Collins" <jamiecollins[ at ]xsmail.com> wrote in message
news:1152785248.577605.117840[ at ]m73g2000cwd.googlegroups.com...
[Quoted Text] >
> Robert Morley wrote:
>> "tbl" for tables, "vw" for views
>
> Another thought. Could using prefixes encourage the wrong mental model?
> For example, using 'tbl' and 'vw' differentiates between a table and a
> view (or 'qry for Query, to use the Access conventions). The difference
> is physical whereas logically a view is a (virtual) table so why
> differentiate at all? If I say SELECT last_name FROM Customers, why
> would I care whether the table was virtual or otherwise? What value
> does the prefix add?
>
> Likewise the terms 'field' and 'record' which still prevail in the
> Access world, rather than the respective terms 'column' and 'row'
> preferred in the wider SQL world. Do these terms really encourage
> people to think in terms file systems and sequential processing rather
> than SQL databases and a set-based mental model?
>
> Jamie.
>
> --
>
|
|
BASIC won the war, and lost all the battles: .Net has adopted
all the features that made BASIC - fully memory managed string
class, interpreted library, single basic type, etc - dumped the
ideas like prefix notation that were only there to make up for
defects in the C language definition - and given us a new C
language with all the features they laughed at.
In a language that supports memory management and ByRef variables,
where the most difficult part of programming is not keeping track
of your indirection, stack pointers, and string space, it no
longer makes sense to put the syntax annotations in the high-
visibility space at the front of the variable name.
Now, after a long detour through C, we are back were we were
with Pascal: variable names refer to the logical content of
the variable, rather than the structure of the variable.
I still use postfix notation for variable types: name$, cost%
where it helps. There should be postfix annotations for all
types /where it matters/. Unfortunately, that is one place where
..Net is still caught in the 'real-programmer' fashion. They
can't use language-supported postfix notation because C didn't
do it that way, and because BASIC did.
Instead, when they need to note information about the structure
of the element, they are typing it out, COBOL style. And it's
not that I object to COBOL: I could do object-oriented
programming in COBOL, even though COBOL was not 'object-oriented',
and you can do postfix notation in .NET, even though the language
does not support it, but in the end, it's more efficient to
have language support for features like that rather than doing
it all your self.
(david)
"Vayse" <vayse[ at ]deadspam.com> wrote in message
news:OCaoZ9xpGHA.756[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text] > "Tim Ferguson" <FergusonTG[ at ]softhome.net> wrote in message
> news:Xns97FFCA55CFDCCgarbleme4455656[ at ]207.46.248.16...
>> programming style, they have now reverted completely, and prefixes are
>> AbsolutelyOut for anything based on the new versions of VisualStudio --
>> or should that be visualStudio?
>>
>
> I have to do a lot of vb.net work, and I find the new naming convention a
> bit awkard. New MS articles insist on dropping the o for object, as
> everything is an object now. And cls for class is gone as well, of course.
> But there are still some 2003 and older articles amongst the help files,
> where they have different naming conventions. But thats not too bad, its
> easy enough to get used to.
> My old way: Dim oClient as New clsClient
> New way: Dim SalesClient as New Client
> It does mean thinking of names though! Like having to use SalesClient in
> this sample.
>
> What really gets me is the names on forms. So instead of gridClients, its
> now ClientsDataGridView. And then theres ClientNameTextBox. Its very hard
> to get used to, after years of txtClientName!
> In some ways it makes sense. All your Client objects are grouped together.
> But I think I'll keep to the old ways in Access. Though I may not be able
> to keep up two naming conventions for ever.
> Diarmuid
>
>
|
|
"onedaywhen" <jamiecollins[ at ]xsmail.com> wrote in message
news:1152865021.381826.201260[ at ]s13g2000cwa.googlegroups.com...
[Quoted Text] >
> BruceM wrote:
>> I learned about a naming
>> convention that makes sense, so I started using it, and found it to be
>> helpful.
>
> Did you browse the whole 'naming conventions' aisle before making your
> choice?
I picked one that seemed to be in common use, and turned my attention to the
program.
>
>> It's interesting how much of the discussion is about how using one system
>> or
>> another will appear in the eyes of somebody else.
>> Did you choose the
>> naming convention you use because you "wannabe" like somebody else?
>
> Of course. When I started dabbling in WordBasic, I used logical terms
> for variable names; I was working in the office of the board of
> directors and wore a blazer, slacks and smart shiny shoes to the
> office.
>
> I wanted to move into VBA software development so, to be taken
> seriously by what I hoped would be my peers, I adopted the naming
> convention lng- for Long Integer, str- for String, dtm- for Date, etc.
> These prefixes did not add value for me personally: the variable name
> told me how I was using it and hence conveyed the data type, the prefix
> seemed to be redundant and jar.
When learning something new we tend to adopt methods used by those from whom
we learn. As it happens I learned from people who tended to use a
particular naming convention.
>
> Luckily in my SQL career I took the 'standard SQL' path from day one
> and never got into the whole 'tbl', 'fields' and other Access
> conventions. When I first started using .NET I was very relieved that
> the convention has moved away from data type prefixes to logical
> variable names; I still use the prefixes in VBA, though sometimes I
> can't be bothered and stick with the .NET convention. I was amused the
> other day to see an MVP using camelCase for their Access column -
> sorry, field - names <g>.
>
> And, yes, I use the standard SQL terms column (in place of 'field'),
> VIEW (in place of 'Query'), 'DECIMAL' (in place of 'Currency' <g>), a
> relational/industry standard key (in place of 'autonumber' <vbg>) to
> encourage others to look outside of the Access ghetto in the hope they
> may benefit as I have.
>
> Oh and today I'm wearing a t-shirt and jeans (because sometimes you
> need to fit in) with walking boots (because sometimes you need to do
> what makes practical sense).
Perhaps it is or will be my downfall that I have never had much interest in
"fitting in". My choices are logical and systematic, and they work for me.
If they make me uncool in the eyes of some, so be it.
>
> Jamie.
>
> --
>
|
|
BruceM wrote:
[Quoted Text] > > Did you browse the whole 'naming conventions' aisle before making your
> > choice?
>
> I picked one that seemed to be in common use
>
> Perhaps it is or will be my downfall that I have never had much interest in
> "fitting in". My choices are logical and systematic, and they work for me.
> If they make me uncool in the eyes of some, so be it.
Is there anything more conventional than choosing the convention in
common use <g>?!
Maybe you are less of a rebel than you think ;-)
Jamie.
--
|
|
"onedaywhen" <jamiecollins[ at ]xsmail.com> wrote in message
news:1152877467.324138.203670[ at ]m79g2000cwm.googlegroups.com...
[Quoted Text] >
> BruceM wrote:
>> > Did you browse the whole 'naming conventions' aisle before making your
>> > choice?
>>
>> I picked one that seemed to be in common use
>>
>> Perhaps it is or will be my downfall that I have never had much interest
>> in
>> "fitting in". My choices are logical and systematic, and they work for
>> me.
>> If they make me uncool in the eyes of some, so be it.
>
> Is there anything more conventional than choosing the convention in
> common use <g>?!
To quote from (I think) one of your earlier posts: "If you want to appear
as a 'serious' SQL database type person, take a look at what people do
outside of the Access ghetto". If people are going to evaluate my Access
abilities I hope they will do so based on what I do with the program. If
the convention in common use helps me be understood it has done what I ask
from a convention.
>
> Maybe you are less of a rebel than you think ;-)
Oh, I can fit into a variety of situations. But as always, any choice will
be embraced by some and held at arm's length by others.
Interesting as always to engage in these exchanges with you.
Regards, Bruce
>
> Jamie.
>
> --
>
|
|
[Quoted Text] > And, yes, I use the standard SQL terms column (in place of 'field'),
> VIEW (in place of 'Query'), 'DECIMAL' (in place of 'Currency' <g>), a
> relational/industry standard key (in place of 'autonumber' <vbg>) to
> encourage others to look outside of the Access ghetto in the hope they
> may benefit as I have.
Jamie / onedaywhen,
It looks to me like you are consistently overlooking a simple fact:
these here are ACCESS newsgroups, and people come here with their Access
questions... therefore, the replies are in Access terms. I'll accept,
for the sake of the argument, that "view" is correct, and "query" is
wrong, bad, filthy or whatever else you want it to be... even so, what
makes you so confident that the poster of a question will actually know
what you mean by "view"? How can you be so sure they won't be further
confused instead?
I truly admire the depth of your knowledge of SQL, which is exactly why
I hate to see your energy wasted on pointless arguments. I suppose you
must be enjoying this more than actually helping others!
Nikos
|
|
Nikos Yannacopoulos wrote:
[Quoted Text] > It looks to me like you are consistently overlooking a simple fact:
> these here are ACCESS newsgroups, and people come here with their Access
> questions... therefore, the replies are in Access terms. I'll accept,
> for the sake of the argument, that "view" is correct, and "query" is
> wrong, bad, filthy or whatever else you want it to be...
I'll settle for 'non-standard'.
> even so, what
> makes you so confident that the poster of a question will actually know
> what you mean by "view"? How can you be so sure they won't be further
> confused instead?
I get your point. I'm pretty sure that when I use the term 'view' I
usually say 'Query', 'query object' or similar.
Access-specific terms can similarly be confusing for someone thinking
in standard SQL terms e.g. a 'delete query' would be an oyxmoron.
Surely as a community we can change the prevailing conventions and
bring terminology closer in line with that of the wider SQL world. In
the long run that would reduce confusion, I think.
To use (yet another) example, years ago I was sent on an elementary
Access course. The tutor was trying to teach about relationships 1:1,
1:m and m:m. I came out utterly confused, not knowing whether this
terminology applied to Query objects or Table objects or what. I didn't
use Access after the course and promptly forgot everything. When I
later started using SQL on another platform I quickly encountered
primary keys and foreign keys, of course, and it suddenly struck me
that this is what that tutor had meant! So for me, the SQL syntax made
sense and the Access approach did not. I figure there's got to be
others like me out there who are confused by the Access conventions but
would benefit from seeing the bigger picture; also lots of people for
whom it would be overwhelming, I guess.
> I hate to see your energy wasted on pointless arguments
Touché <g>! I'm only as bad as everyone else posting to a thread with
the phrase 'pointless debate' in the subject line ;-)
Jamie.
--
|
|
"onedaywhen" <jamiecollins[ at ]xsmail.com> wrote in message
news:1152890439.840562.43780[ at ]i42g2000cwa.googlegroups.com...
Nikos Yannacopoulos wrote:
[Quoted Text] > It looks to me like you are consistently overlooking a simple fact:
> these here are ACCESS newsgroups, and people come here with their Access
> questions... therefore, the replies are in Access terms. I'll accept,
> for the sake of the argument, that "view" is correct, and "query" is
> wrong, bad, filthy or whatever else you want it to be...
I'll settle for 'non-standard'.
> even so, what
> makes you so confident that the poster of a question will actually know
> what you mean by "view"? How can you be so sure they won't be further
> confused instead?
I get your point. I'm pretty sure that when I use the term 'view' I
usually say 'Query', 'query object' or similar.
The Access term is widely understood in an Access newsgroup.
Access-specific terms can similarly be confusing for someone thinking
in standard SQL terms e.g. a 'delete query' would be an oyxmoron.
Those people probably won't come to an Access newsgroup.
Surely as a community we can change the prevailing conventions and
bring terminology closer in line with that of the wider SQL world. In
the long run that would reduce confusion, I think.
Most people come here to learn about solving specific problems, and do not
care about the world outside of Access. While you may be correct about
using terminology that is in wide usage, most people posting answers here
probably do not wish to add a terminology tutorial to their responses, nor
are those posting questions likely to be interested in such instruction.
To use (yet another) example, years ago I was sent on an elementary
Access course. The tutor was trying to teach about relationships 1:1,
1:m and m:m. I came out utterly confused, not knowing whether this
terminology applied to Query objects or Table objects or what. I didn't
use Access after the course and promptly forgot everything. When I
later started using SQL on another platform I quickly encountered
primary keys and foreign keys, of course, and it suddenly struck me
that this is what that tutor had meant! So for me, the SQL syntax made
sense and the Access approach did not. I figure there's got to be
others like me out there who are confused by the Access conventions but
would benefit from seeing the bigger picture; also lots of people for
whom it would be overwhelming, I guess.
The problem was, of course, with the instructor. I am aware of your disdain
for Access, but an instructor's competence or lack thereof is not a
reflection of the software. A friend of mine does development work with
Filemaker. He is similarly disdainful of Access (and all things Microsoft),
but I hear about his struggles with problems that could easily be solved
with an After Update event or something of the sort. Still, he won't even
consider any possibility other than that Access is at the bottom of the
database scrap heap.
> I hate to see your energy wasted on pointless arguments
Touché <g>! I'm only as bad as everyone else posting to a thread with
the phrase 'pointless debate' in the subject line ;-)
Yes, quite a number of us like to join the fray, don't we?
Jamie.
--
|
|
While what you say is true, giving it SOME prefix ensures that any table
that are unrelated to anything else at least get lumped together. I
personally find that easier than having them all scattered about when
looking at an alphabetical list. To each his or her own, though.
Rob
"onedaywhen" <jamiecollins[ at ]xsmail.com> wrote in message
news:1152863366.501243.251540[ at ]p79g2000cwp.googlegroups.com...
[Quoted Text] >
> Robert Morley wrote:
>> Like I said, for myself, I don't generally stick to simply "tbl" or "vw"
>> or
>> whatever unless there's no other logical prefix
>
> He's a idea for you: if there is no *logical* prefix (i.e. the table's
> name already conveys meaning) then don't use a prefix that conveys its
> *physical* implementation. At best it's redundant, worse it's mixing
> logical and physical models.
>
> Jamie.
>
> --
>
|
|
I'll try again. My inline replies did not appear as such.
"BruceM" <bamoob[ at ]yawwhodawtcalm.not> wrote in message
news:ugY2121pGHA.516[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text] >
> "onedaywhen" <jamiecollins[ at ]xsmail.com> wrote in message
> news:1152890439.840562.43780[ at ]i42g2000cwa.googlegroups.com...
>
> Nikos Yannacopoulos wrote:
>> It looks to me like you are consistently overlooking a simple fact:
>> these here are ACCESS newsgroups, and people come here with their Access
>> questions... therefore, the replies are in Access terms. I'll accept,
>> for the sake of the argument, that "view" is correct, and "query" is
>> wrong, bad, filthy or whatever else you want it to be...
>
> I'll settle for 'non-standard'.
>
>> even so, what
>> makes you so confident that the poster of a question will actually know
>> what you mean by "view"? How can you be so sure they won't be further
>> confused instead?
>
> I get your point. I'm pretty sure that when I use the term 'view' I
> usually say 'Query', 'query object' or similar.
>
The Access term is widely understood in an Access newsgroup.
>
> Access-specific terms can similarly be confusing for someone thinking
> in standard SQL terms e.g. a 'delete query' would be an oyxmoron.
>
Those people probably won't come to an Access newsgroup.
>
> Surely as a community we can change the prevailing conventions and
> bring terminology closer in line with that of the wider SQL world. In
> the long run that would reduce confusion, I think.
>
> Most people come here to learn about solving specific problems, and do not
> care about the world outside of Access. While you may be correct about
> using terminology that is in wide usage, most people posting answers here
> probably do not wish to add a terminology tutorial to their responses, nor
> are those posting questions likely to be interested in such instruction.
>
> To use (yet another) example, years ago I was sent on an elementary
> Access course. The tutor was trying to teach about relationships 1:1,
> 1:m and m:m. I came out utterly confused, not knowing whether this
> terminology applied to Query objects or Table objects or what. I didn't
> use Access after the course and promptly forgot everything. When I
> later started using SQL on another platform I quickly encountered
> primary keys and foreign keys, of course, and it suddenly struck me
> that this is what that tutor had meant! So for me, the SQL syntax made
> sense and the Access approach did not. I figure there's got to be
> others like me out there who are confused by the Access conventions but
> would benefit from seeing the bigger picture; also lots of people for
> whom it would be overwhelming, I guess.
>
The problem was, of course, with the instructor. I am aware of your disdain
for Access, but an instructor's competence or lack thereof is not a
reflection of the software. A friend of mine does development work with
Filemaker. He is similarly disdainful of Access (and all things Microsoft),
but I hear about his struggles with problems that could easily be solved
with an After Update event or something of the sort. Still, he won't even
consider any possibility other than that Access is at the bottom of the
database scrap heap.
>
>> I hate to see your energy wasted on pointless arguments
>
> Touché <g>! I'm only as bad as everyone else posting to a thread with
> the phrase 'pointless debate' in the subject line ;-)
>
Yes, quite a number of us like to join the fray, don't we?
>
> Jamie.
>
> --
>
>
|
|
|
[Quoted Text] > Those people probably won't come to an Access newsgroup.
While I can hardly argue the point that this is an Access newsgroup ("like,
duh!" <a la stereotypical teenage girl>), one of the groups that this is
being posted to is also geared towards ADP and SQL Server, and so is likely
to attract at least a few so-called "real" database programmers who are
"just trying to help the poor misguided souls who seem to think that Access
is actually worth mentioning".
Typically, the poor misguided souls who seem to think that they're using a
"real" database system and Access users are not fall into one of two
categories: those who believe that Access is not as robust as <insert
Enterprise-level system here>, and those who have an unreasoning prejudice
against anything that isn't their chosen system.
Now, the former group certainly has a point. Access is not as robust of a
back-end as SQL Server (or Oracle or whatever else) is. I know it may
violate your preconceived notions, but not every database needs to be run on
an enterprise-level DBMS. Access is meant to create small, portable
databases on a local computer, or maybe with replication under a limited set
of circumstances, and it does that very well. And as a front-end, frankly,
I've yet to see its match. .NET may give you a lot more programming
options, and make the programming tier very powerful and easy to write, but
have you honestly ever tried designing a form with it? GODS what a
nightmare!
And as to the latter group, there's nothing we can do about them short of
chaining them to a desk with only Access available and forcing them to
actually USE it for more than a few hours and to actually learn how it works
and what it's capable of...not to mention forcing them into learning a
different way of thinking that doesn't involve command-line interfaces for
half the work they do. (Why am I reminded of Linux users?)
Alright, so much of the above is fairly prejudicial, but honestly people,
these are the attitudes you're projecting...why SHOULDN'T I poke fun at you?
Rob
|
|
I have lived from A$ and I%, through deciding suffixes were a "bad thing"
and onto str_A and Int_I .
The word "fashion" comes to mind.
I now try to write my programs for those who are going to read them.
David F. Cox
"Robert Morley" <rmorley[ at ]magma.ca.N0.Freak1n.sparn> wrote in message
news:uhstMLcpGHA.4912[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text] >I still don't buy that this is either product-specific or amateur-specific.
>I've seen countless numbers of experienced, formally trained (and who
>learned it on their own) database programmers on every platform I've ever
>used who use "tbl" for tables, "vw" for views, "usp" for user stored
>procedures, not to mention "frm" for forms, "rpt" for reports, etc., ad
>nauseum.
>
> Personally, I don't see the point of starting ALL objects in a category
> with the same letters; that's generally redundant (though occasionally
> useful when you're trying to distinguish between views and tables, etc.).
> My general preference is to base it around the function of the object.
> "acct" for account-related tables, "resp" for respondent-related tables,
> "list" for simple lookup-type tables, etc. Only for objects that don't
> have a significant inter-relationship with the rest of the database (i.e.,
> localization tables, user preferences, etc.) do I use the generic "tbl",
> "frm", or whatever.
>
> And while "tbl" itself may have first appeared in a Smart Access article
> in 1993, as I said, Hungarian notation itself pre-dates that. As I said,
> Simonyi Károly (aka Charles Simonyi) did indeed work at Microsoft, but he
> started Hungarian Notation back when he was working for Xerox. It's
> hardly a surprise that it later appeared in a Microsoft product that he
> worked on. Hell, ignore Hungarian notation for a moment, how long ago did
> people start using "i" for integer? "For i = " was one of the first
> constructs I learned almost 30 years ago.
>
>
> Rob
>
> "Craig Alexander Morrison" <cam[ at ]microsoft.newsgroups.public.com> wrote in
> message news:ulTN4sYpGHA.4236[ at ]TK2MSFTNGP03.phx.gbl...
>>> Oh and just for the record, Hungarian Notation became popular with
>>> languages like VB/VBA, but actually pre-dates it. The inventor, Simonyi
>>> Károly, was working for Xerox at the time and only much later did he
>>> move
>>> to Microsoft.
>>
>> For the record "tbl" and other such fripperies first appeared in a 1993
>> Smart Access article and has subsequently appeared in the ADH books. I
>> don't
>> mind one using tags in code but not for database objects. Charles Simonyi
>> actually worked on Access 1; I am not sure what he thinks of the
>> Lesynski/Reddick extensions.
>>
>> It is a good sign of an amateur with limited experience of other
>> products.
>> Some amateurs are very good programmers though.
>>
>> Nearly all formally trained Relational (or SQL) Database designers would
>> find this "tbl" tag laughable.
>>
>> --
>> Slainte
>>
>> Craig Alexander Morrison
>> Crawbridge Data (Scotland) Limited
>>
>> "Robert Morley" <rmorley[ at ]magma.ca.N0.Freak1n.sparn> wrote in message
>> news:%237AzQEWpGHA.3288[ at ]TK2MSFTNGP03.phx.gbl...
>>> Like I said, different ways of thinking. I look at most of your points
>>> and disagree with them either in part or in whole, but frankly, this
>>> isn't
>>> the place to get into this kind of discussion. The original post has
>>> been
>>> answered with two different solutions, and that's the end of it as far
>>> as
>>> I'm concerned. I just bitched someone else out in another NG for
>>> exactly
>>> this kind of "mine is bigger than yours" discussion that serves no
>>> purpose
>>> but to bicker pointlessly. Everybody's got their favourite apps and the
>>> apps they think are toys, we simply disagree on which ones are which.
>>>
>>> :)
>>>
>>>
>>>
>>> Rob
>>>
>>> "Tim Ferguson" <FergusonTG[ at ]softhome.net> wrote in message
>>> news:Xns97FDE698BF5FFgarbleme4455656[ at ]207.46.248.16...
>>>> "Robert Morley" <rmorley[ at ]magma.ca.N0.Freak1n.sparn> wrote in
>>>> news:uu9k#kPpGHA.1140[ at ]TK2MSFTNGP05.phx.gbl:
>>>>
>>>>> Obviously someone thought so, or they never would've designed combo
>>>>> box lookups to work in tables.
>>>>
>>>> There are several things in Access that relegate it into the "toy"
>>>> platform in the eyes of other database developers on "real" systems.
>>>> The
>>>> quaint but misguided fashion for putting "tbl" in front of object names
>>>> is one; the presence of the "look up field" is another. I regret this
>>>> because when you get up close, Jet is a pretty fine database engine and
>>>> Access is a flexible and usable rapid development platform, but it will
>>>> continue to get a rotten press as long as it's aimed at the Janet and
>>>> John level of user. The type of users, in effect, that get drowned in
>>>> any
>>>> case as soon as they step off the dumb-spreadsheet kind of appliction.
>>>>
>>>> FWIW, it seems that the Access-as-toy party has won the debate because
>>>> Jet development is being taken over by the Access UI team. I think it's
>>>> time to be off to MySQL before t | | |