[AccessD] Naming Conventions

Charlotte Foust cfoust at infostatsystems.com
Fri Aug 13 10:59:47 CDT 2004


And LOTS of gotos.

Charlotte Foust


-----Original Message-----
From: DWUTKA at marlow.com [mailto:DWUTKA at marlow.com] 
Sent: Thursday, August 12, 2004 7:58 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Naming Conventions


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
lngSomeLongDrawnOutCompletelyMeaninglessToTheCompilerNameSoThatSomeoneWh
oIsT
ooLazyToReadTheCodeLogicCanImpressAClientThatTheyKnowAParticularVariable
Repr
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
-- 
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



More information about the AccessD mailing list