DWUTKA at marlow.com
DWUTKA at marlow.com
Wed Aug 11 17:02:54 CDT 2004
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