DWUTKA at marlow.com
DWUTKA at marlow.com
Thu Aug 12 10:58:12 CDT 2004
Actually, when I was a kid, I did program in Basic.....good ol' DOS. No naming convention at all, no classes, just ABC, and XYZ. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Scott Marcus Sent: Thursday, August 12, 2004 10:41 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Naming Conventions I'm just saying that you probably were not programming when no one used naming conventions. Not a dig at your experience/ability at all. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of DWUTKA at marlow.com Sent: Thursday, August 12, 2004 11:11 AM To: accessd at databaseadvisors.com Subject: RE: [AccessD] Naming Conventions About 5 years (give or take a bit, depending on what system we are talking about). Just out of curiousity, what does this prove? When someone with this vast programming experience has a networking issue, shouldn't they have all that experience working with computers, to just figure out what is wrong? Should I ask them how long they have been using computers for? Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Scott Marcus Sent: Thursday, August 12, 2004 6:32 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Naming Conventions >From this response, I take it that you have not been a programmer for a long time. John, and I (and others) are speaking from experience. I have had to maintain code that use single letter variables (or seemingly meaningless names) as well as code that uses some type of naming convention with good naming structure. I much prefer the latter, it is way easier to maintain/debug. Sure, some of this stuff was taught to me. That does not make it a reason to use it. My experience has just reinforced what someone already told me. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of DWUTKA at marlow.com Sent: Wednesday, August 11, 2004 6:03 PM To: accessd at databaseadvisors.com Subject: RE: [AccessD] Naming Conventions You're right, this does hit close to home. I have always railed against the 'we do it because that is how I was taught', or 'we do it because that's the way we do it'. For example, JC brought up a ventilator company he does work for. They have set practices, guidelines to work processes. On paper, and even a little below the surface, the system looks great. JC writes a procedure in code. 3 guys go over every line of code. All of the code is compared to various standards and guidelines. Wow, with a system like that, a ventilator couldn't POSSIBLY fail from coding! WRONG! Sure, it looks good, it sounds solid, but there is a catch. It's structured. It's a rule system designed around a specific set of circumstances. The problem is that the real world changes, and usually without warning. One anomoly that can't fit into the rule system, and it all falls apart! With this particular debate, there have been three arguments to using Hungarian. #1. It's the way I was taught, or It's how I have always done it. Completely invalid argument. It doesn't invalidate the method, but it invalidates the reason someone else should use the same method. #2. It makes it easier for maintenance developers. Wrong. JC proved this himself, by saying that not everyone uses the same convention. Therefore, it only makes it easier for maintenance developers that use that convention, no more no less. Another convention has the same chances of being easier to maintain. #3. A client wants it done with a particular convention. The only valid argument made. And one I am in complete agreement with. If a client wants a particular naming convention, they get a particular naming convention. This still does not invalidate other conventions used for projects not done for that particular client. What REALLY kills me is that this debate is functionally identical to the NaturalKey/SurrogateKey debate. We are all relational database developers. We have no problem relating an AutoNumber value of 5, to a particular User/Item/Piece of data, but we have a problem relating ii as a variable representing an InventoryItem Class Object? Um....why? When I look at code, I look at what is declared, and if I saw rs as a recordset, I would not have a problem 'thinking' recordset, everytime I ran across rs. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Scott Marcus Sent: Wednesday, August 11, 2004 2:36 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Naming Conventions Drew, Why do you take the extreme point of view like this? The name you gave the variable implies that I'm to lazy to read code, can't interpret logic, and that I write extremely long variable names. None of which is true. I don't care how the compiler interprets my variable name, I care how those who maintain my code (including me) interprets it's purpose. I think this is hitting a little too close to home for you. It is true that I want to impress the client in a positive way. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of DWUTKA at marlow.com Sent: Tuesday, August 10, 2004 5:16 PM To: accessd at databaseadvisors.com Subject: RE: [AccessD] Naming Conventions Actually, I find it easier to remember that I'm using i, then it is to remember that I am using lngSomeLongDrawnOutCompletelyMeaninglessToTheCompilerNameSoThatSomeoneWhoIsT ooLazyToReadTheCodeLogicCanImpressAClientThatTheyKnowAParticularVariableRepr esentsXYZ Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Scott Marcus Sent: Tuesday, August 10, 2004 6:12 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Naming Conventions There are plenty of other things that I would rather fill my mind with when developing and debugging code than remembering in each line of code(in the loop) that 'i' is the employee type and 'j' is the employee counter. Wouldn't you agree that it is hard enough sometimes just to follow the logic of the code you are working on let alone remembering these variable interpretations? -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Susan Harkins Sent: Monday, August 09, 2004 9:39 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Naming Conventions Just a slight aside here, but you're gonna have to read the rest of the statement anyway -- if you're counting something, you still need the rest of the statement to figure out the rest -- the variable name itself is NOT going to give you all the information you need. You still need the rest of the statement. Not a for or an against, just thought I'd mention it... Susan H. Even 'intI' means little more than 'i'. Like you said, something like 'intEmployeeCounter' is easy to understand. Just to be even more clear, take the following into consideration... -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com