Although I did not write this book (I wish I
did), you might check out Steve McConnell's Code
Complete. While the coding conventions in that book are for C/C++
they are applicable to Java and the concepts are
applicable to all development. Naming and Coding
Conventions are about as varried as there are programmers.
What I like is not what my bosses like, so I follow
their coding conventions. I like the Hungarian
nomenclature described in Code Complete, but not many people I
know follow it and it confuses people who
don't. A few guidelines, however: 1) Don't abreviate...
Java will take names as long as you want, so make your
names as descriptive and uncryptic as possible. 2)
Class Names Always begin with a Capital letter and each
new word in the name begins with a capital. The name
should be descriptive of what the class is. If it is a
domain class (representing business objects) it should
be made of nouns. ie. PayrollAccount If
it is a "helper" class, it should be
verbs. ie ReconcileCheckbookHelper Utility classes should follow
the
same: CollectionFactory 3) Your objects could actually be
descriptive... PayrollAccount payrollAccount = new
PayrollAccount(); If
you are using a collection Vector
payrollAccounts = new Vector(); Use plural.... 4)
Different people use different techniques to differentiate
between local and instance varables. First, your
methods should not be so large that you can't see the
whole thing in one glance. When you define local
variables in your method, you can then see that you can
easally see that you have defined it within your method.
This will help if determining if you have a local or a
class (instance variable/object). The
objects/variables always begin in a lower case. You can go
on and on... but these are just a few conventions
for starters. Check out Code Complete; and that will
help you on your way further.

I'll check it out. The
guidelines you listed are ones I agree with and regularly
adhere to. The part I'm wrestling with has to do with a
tendency of some people to include something in the name
to indicate the type such as strFirstName, intAge,
blnActive, btnOK etc. I seems to me that this could work if
a program sticks to the basics but with object
oriented programming and the limitless supply of classes
that are out there, trying to come up with meaningful
abbreviations could prove frustrating. I suppose we could
include the complete name of the class in the name of the
object but sheesh!<br><br>What's the advantages of
including the type in the name? So you don't have to seek
out the declaration in the code to find out the type?
One convention that I have seen (and used) that seems
helpful is prefixes of "m_" or "l_" to indicate the scope
of member  or local variables.<br><br>Thank you for
the book recommendation

Including "type" in the definition of an object
is what is described in the Hungarian notation in
Code Complete... he has a large discussion on it and a
couple of tables....<br><br>I've used the underscore
infront of a member  variable to indicate an instance
variable and nothing to describe the local... Sometimes
this is an "overformalization" but if you can get
everyone on the team (and these conventions are mainly
used for code in a team environment or if you drop
dead tomorrow, someone ELSE might have to maintain) to
follow the convention, more power to you... Young kids
coming out of college have never worked in a team
environment and have never had to maintain someone else's
cryptic spagetti code; and just don't understand the need
for standardization. They also don't understand that
if they change code to get their section to work;
and yet break everyone else's functionality that it's
THEIR problem not everyone else's.<br><br>I guess it's
just my prior military need for standardization that
drives me...<br><br>Stephen
McConnell<br>http://www.crosslogic.com

Cool. Downloaded the ambysoft pdf and it looks
great. I've seen the Java Style book, but didn't
purchase it. Seems like a good investment.<br><br>You'r
right. If you are doing good general OOAD practices,
prefacing your variables with scope and type is not that
necessary. Your methods should be small enough to obviate
that. <br><br>If the code review practice is good
enough (used as an education process as well as QC),
good programming style should begin to permiate the
team.<br><br>However, most team environments view that practice as
overhead and not really important (which I think is a
mistake). Not all programmers on a team are at the same
level, or develop the same way (this is a good thing,
though). <br><br>Thanks for the links.<br><br><br>Stephen
McConnell<br>http://www.crosslogic.com