If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#21
|
|||
|
|||
Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)
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 |
#22
|
|||
|
|||
Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)
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 |
#23
|
|||
|
|||
Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)
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. -- |
#24
|
|||
|
|||
Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)
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? 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. -- |
#25
|
|||
|
|||
Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)
"Tim Ferguson" wrote in message
... 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 |
#26
|
|||
|
|||
Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)
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 ... Like everything else in the world, to much is like not enough. When writing |
#27
|
|||
|
|||
Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)
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" wrote in message oups.com... 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. -- |
#28
|
|||
|
|||
Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)
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" wrote in message ... "Tim Ferguson" wrote in message ... 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 |
#29
|
|||
|
|||
Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)
"onedaywhen" wrote in message oups.com... 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. -- |
#30
|
|||
|
|||
Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)
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?! Maybe you are less of a rebel than you think ;-) Jamie. -- |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Update combo box in subform (After Update event) | Karl | Using Forms | 10 | April 4th, 2006 07:45 PM |
Looking for a recent thread on multple combo boxes | potter | Using Forms | 7 | February 28th, 2006 03:31 AM |
Requery Combobox | MJ | Running & Setting Up Queries | 7 | May 25th, 2004 11:01 AM |