[AccessD] Naming Conventions

Scott Marcus marcus at tsstech.com
Thu Aug 12 10:41:26 CDT 2004


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





More information about the AccessD mailing list