RANT: Stop Indicating Type in Variable Name Please
Michael Covington
I hear you. I think the best variable names are those that actually
tell you what the variable does. If the data structures are well
designed, the type of the variable should be fairly obvious from its
function. I use "Hungarian-style" names only for minor variables that
are used briefly or would otherwise conflict, e.g.,
LocalDocumentationStrings and then pLocalDocumentationStrings if
for some reason I also have to have a pointer to it.
I do use rather *long* variable names. For those who hate to type,
these can be typed short, then lengthened by a global change in
the editor.
--
Michael A. Covington, Ph.D. http://www.ai.uga.edu/~mcovingt
Associate Director, Artificial Intelligence Center and
Chairman, Computer Security Incident Handling Team
The University of Georgia, Athens, GA 30602-7415 U.S.A. <><
John Burton
Do you really have so many variable that you can't remember
what they do? I'd suggest doing a bit more design on your
code.
Ell <e...@access2.digex.net> wrote in article
<5saacd$o80$2...@news2.digex.net>...
>
> Here's one vote *for* Hungarian. I can know what a variable is without
> hunting. From context it's often difficult to know, for instance, if a
> number variable is an integer or a float.
>
> I also like the PB convention where even the scope of a variable is
> signified. gVar - global; mVar - member; Var - local function.
>
> Elliott
> --
> "The domain object model is the foundation of OOD."
> "We should seek out proven optimal practices and use them."
> See SW Modeller vs SW Pragmatist Central:
http://www.access.digex.net/~ell
>
>
>
Adrian Milliner
On Wed, 06 Aug 1997 19:58:24 GMT, "John Burton" <j...@mail.com> wrote:
>Do you really have so many variable that you can't remember
>what they do? I'd suggest doing a bit more design on your
>code.
>
It does happen, ever so often, that a large number of variables are
required. Many classes with many member variables. C code with struct
members. Even plain old globals.
In fact, just about every project I've ever worked on had many
hundreds, if not many thousands of variables (member or otherwise).
Occasionally, in really bizarre cases, more than one person works on a
project, so there could be variables that you would have no knowlege
of.
From the comment you made, it sounds like you've never actually worked
on a project bigger than "hello, world".
Of course if you were refering to local(auto) variables, then your
point is well made and I apologise for my sarcasm. But I doubt it,
somehow.
--
Adrian Milliner
adr...@NOSPAMrefine.co.uk
http://www.ftech.net/~refine/
When replying to messages, remove the NOSPAM from the address.
Ell
Ma...@mWilden.com wrote:
:
: I have no problem using nChickens to designate the number of chickens in
: a program, because I usually don't care what its internal representation
: is. At some point, I did, so I made it an unsigned char, unsigned int,
: unsigned short, unsigned long or whatever. But having made that choice,
: the rest of the application doesn't have to cart around this baggage
: every time I use the variable--it just needs to know that nChickens
: counts chickens.
But how about the possibility that you will corrupt the integrity of the
meaning of the data in the variable if you assign for example an
unsigned value to a signed variable?
: And if it turns out that I was wrong about the number of chickens I
: needed to count, I simply change one word in one definition and one
: declaration, instead of having to change uccChickens to ulcChickens
: throughout the entire program. Isn't this the opposite of abstraction?
:
: (But the main reason I don't miss Hungarian is that it makes the code
: ugly. :)
Funny, I find it nice looking, and "reassuring". I've been doing MS
Windows programming since the late '80's, so I'm very used to it.
David Brownell
Ell wrote:
>
> Here's one vote *for* Hungarian.
Bletch ... when I need to change the type of a variable, I need to
change
its name and everywhere I use it? I can't just rely on overloading to
keep
everything straight? I can't just name variables exclusively by
purpose?
I have to capture every bit of potentially relevant data in the name?
.... I need to use a naming convention invented for use in assemblers
with
eight character symbol names, now that languages have full length
symbols?
Where DID that smelly mess come from?
- Dave
Mark Boon
On Wed, 06 Aug 1997 19:58:24 GMT, "John Burton" <j...@mail.com> wrote:
>Do you really have so many variable that you can't remember
>what they do? I'd suggest doing a bit more design on your
>code.
>
Never had to look at someone elses code and wondered "what the #$@% is
going on here"?
And sometimes code I made myself a long time ago looks like it was
made by someone completely different :-)
I usually indicate both type and scope, although not as much in Java
as in C. Java is more strongly typed, and usually everything is an
object of some sort anyway.
D'Arcy Smith
Ell wrote:
>
> Here's one vote *for* Hungarian. I can know what a variable is without
> hunting. From context it's often difficult to know, for instance, if a
> number variable is an integer or a float.
>
> I also like the PB convention where even the scope of a variable is
> signified. gVar - global; mVar - member; Var - local function.
So use a convention (naming / placing) :
I use:
- constants - public, protected, package, private
- variables - public, protected, package, private
- methods - public, protected, package, private
- public members have no prefix
- non-public memeber start with an "_"
- all variables are declared at the start of the block that
they are used in
eg:
public class X
{
public static int CONST = 1;
public int pub;
protected int _pro;
public void f()
{
int j;
pub = 1;
_pro = 2;
j = 3;
{
int k;
}
}
private void _g()
{
}
}
This way you can easily find where everything is so in the cases
where there is an ambiguity (like is this protected or private?)
you can easliy figure out where to look.
Also, this follows the more "usual" OO notations of "aVarName"
rather than "mAVarName"...
Its all religious.
..darcy
--
D'Arcy Smith
Symantec, Internet Tools
Check out http://cafe.symantec.com for JDK 1.1.2 for:
- Cafe 1.8
Check out http://cafe.symantec.com for JDK 1.1 for:
- Visual Cafe 1.1 Prerelease 2
- Visual Cafe Pro 1.1 Prerelease 1
Patrick Doyle
In article <33eab251...@news.xs4all.nl>,
Mark Boon <tes...@xs4all.nl> wrote:
>On Wed, 06 Aug 1997 19:58:24 GMT, "John Burton" <j...@mail.com> wrote:
>
>>Do you really have so many variable that you can't remember
>>what they do? I'd suggest doing a bit more design on your
>>code.
>>
>Never had to look at someone elses code and wondered "what the #$@% is
>going on here"?
And hungarian notation really helps in these situations? I doubt
it. I think code readability would go a lot further towards making
the purpose of a piece of code clear.
-PD
--
--
Patrick Doyle
doy...@ecf.utoronto.ca
Patrick Doyle
In article <5sch5e$ekv$3...@news2.digex.net>, Ell <e...@access5.digex.net> wrote:
>Ma...@mWilden.com wrote:
>:
>: I have no problem using nChickens to designate the number of chickens in
>: a program, because I usually don't care what its internal representation
>: is. At some point, I did, so I made it an unsigned char, unsigned int,
>: unsigned short, unsigned long or whatever. But having made that choice,
>: the rest of the application doesn't have to cart around this baggage
>: every time I use the variable--it just needs to know that nChickens
>: counts chickens.
>
>But how about the possibility that you will corrupt the integrity of the
>meaning of the data in the variable if you assign for example an
>unsigned value to a signed variable?
*Even C* should warn you about that one. And for types that are truly
incompatible, it won't work anyway.
>Funny, I find it nice looking, and "reassuring". I've been doing MS
>Windows programming since the late '80's, so I'm very used to it.
Yes, the aesthetics are subjective. But I think there's little
question that plain english words are easier to read than random
letters.
However, I suppose the human mind has the capability to get used
to just about anything given long enough.
Patrick Doyle
In article <5saacd$o80$2...@news2.digex.net>, Ell <e...@access2.digex.net> wrote:
>
>Here's one vote *for* Hungarian. I can know what a variable is without
>hunting. From context it's often difficult to know, for instance, if a
>number variable is an integer or a float.
I think having to look up a variable's declaration is a small price to
pay for code readability.
Code readability is highly underrated, in my opinion.
Uwe Grensing
Scott Robert Ladd <srl...@frontier.net> schrieb im Beitrag
<01bca287$80231a00$69c9...@animas.frontier.net>...
> Richard J Kucera <kuc...@hhmi.org> wrote in article
> <33E73FDE...@hhmi.org>...
>
> Not only is such notation ugly -- it also makes Java code look like
> Microsoft-style Windows code! Ugh... <grin>
>
Best thing:
Even Microsoft uses (or used) at least 2 different types of Hungarian
Notation:
Sometimes int's are iFoo, sometimes they say, it's an index to something,
then it's nFoo.
Also, in 32-bit, pointers are still long-pointers. Really useless.
But: I think, normally you can quite live without hungarian notation. The
only thing I always do is p for Pointer and h for Handle. This helps a lot
in C++, at least for me.
Yours
Uwe
Dean Roddey
But you are kind of missing the point that people who use HN, do it
because they think it improves readability :-)
--------------------------
Dean Roddey
The CIDLib Class Libraries
'CIDCorp
dro...@netgate.net
http://ng.netgate.net/~droddey/
"Software engineers are, in many ways, similar to normal people"
Robert C. Martin
Patrick Doyle wrote:
>
> Yes, the aesthetics are subjective. But I think there's little
> question that plain english words are easier to read than random
> letters.
>
Granted. But the real problem with variable names that contain
their types is that the type information is redundant. The
compiler knows the type of a variable and will warn, or out and out
prevent misuse of the type. Therefore the type info in the name is
redundant and supplies little benefit. On the other hand, that
info is a rather large liability since if must be changed if the
variable type ever gets changed. The impact of such a change is
so high that often the variable name *will not* be changed even though
the type is.
Thus, the type info becomes a lie. Programmers who have found a few
such lies (and everyone will) will soon realize that they cannot trust
the type info, and will therefore ignore it.
The end result is that the convention will slowly defeat itself. The
project will contains many different varieties of variable names. Some
that don't contain type info; some that do, but lie; and some that do
and tell the truth. In other words, a mess.
--
Robert C. Martin | Design Consulting | Training courses offered:
Object Mentor | rma...@oma.com | Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 | C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
"One of the great commandments of science is:
'Mistrust arguments from authority.'" -- Carl Sagan
Ell
Robert C. Martin (rma...@oma.com) wrote:
:
: ... But the real problem with variable names that contain
: their types is that the type information is redundant. The
: compiler knows the type of a variable and will warn, or out and out
: prevent misuse of the type. Therefore the type info in the name is
: redundant and supplies little benefit.
Hugarian sure helps me as the programmer writing the code which is sent to
the compiler. You being one who is often railing against having to
re-compile, should see that one shouldn't wait for a compile or link to
find an error.
On the other hand, that
: info is a rather large liability since if must be changed if the
: variable type ever gets changed. The impact of such a change is
: so high that often the variable name *will not* be changed even though
: the type is.
What's so hard about using a global search and replace?
Scott Stanchfield
Code should just plain be readable -- if someone uses a name like
numberOfWoozles rather than iNum I'm very happy. I get the idea.
I worked at a place that insisted on their own version of Hungarian.
THAT sentence should say it all -- _their_own_version.
Everyone who worked there knew a different variation on Hungarian.
Sure, several common traits like "p" and "i" existed, but there were all
sorts of variations on more complex data.
One of the biggest points of OO programming is encapsulation -- you
shouldn't _care_ about the details, only the interface, if things are
designed well.
Also, in Java you never have this issue of "if this an object, a
reference or pointer?" Everything is either a reference or a primitive
variable. Besides, haven't tools progressed to the point that if you
want to find out what something is, you just look at a class browser?
IMHO, most of the code I've worked with isn't that hard to figure out
what the variables are, just from previous context.
-- Scott
Doug Frietchen
Jo Grant wrote:
>
> I abhor Hungarian notation. However my preferred technique is unlikely to
> please anyone. Back in good, old Fortran (the only language where a
> Complex Number is one of the basic types) they had this feature where if
> you didn't declare the type for a variable it could be deduced from the
> first character of its name. For example, i and j were always integers.
> When I tend to write my code I use a similar thing where I always use the
> same names for variables of similar functions. Obviously this only works
> for utility variables...
> Jo
IMHO, deducing the type from first char was more dangerous than
useful. If you made a typo, rather than give you an error message,
suddenly you had a new variable set to 0 ! This leads to many hard to
find errors that C,C++, Java, et al... compilers would catch.
I still don't understand why C, C++ and Java don't add Complex numbers
as a basic type?
-----
Doug Frietchen
fri...@erols.com
dbfri...@tasc.com
The views expressed do not necessarily represent
those of TASC, nor the left side of Doug's brain.
If you need instructions on how to reply to me, browse to:
www.clueless.websurfers.com
/************************************************/
David Harmon
On Fri, 08 Aug 1997 23:53:38 -0500, "Robert C. Martin"
<rma...@oma.com> wrote:
>redundant and supplies little benefit. On the other hand, that
>info is a rather large liability since if must be changed if the
>variable type ever gets changed. The impact of such a change is
>so high that often the variable name *will not* be changed even though
>the type is.
The cannonical example being wParam and lParam in MS Windows programs.
In the 16-bit API, wParam was a "word" (16-bit int) and lParam was a
"long" (32-bit int). In the new 32-bit API, they are both 32 bits,
but for some unknown reason, Microsoft overlooked changing the name of
wParam in all their SDKs and documentation. For maximum accuracy and
clarity, they should obviously both be named lParam.
Patrick Doyle
In article <01bca435$4f6b1110$0132a8c0@golliwog>,
Uwe Grensing <gren...@stud-mailer.uni-marburg.de> wrote:
>
>But: I think, normally you can quite live without hungarian notation. The
>only thing I always do is p for Pointer and h for Handle. This helps a lot
>in C++, at least for me.
Yes, mark variables according to usage, not type. That makes sense
to me.
kdlitwak
I first tried using Hyngarian notatin but then abandoned it in favor
of a system that will probably be liked less by others but works for
me. I now apend the type of object to the end of the name. So, for
purposes of unqiue names in my whole file, with no overlap between
classes, I might have
addParmDlgOkButton
It makes for long names but it's very clear to me exactly what the
object belongs to (the AddparmDialog class) and wht object it is within
that. I ned those names because I can't always depend upon a "label"
for getting an action or something like that. I need the name and it
helps me avoid confusion when my file contains a big Frame class and
seveal dialogs. A name like okay or picture1 (the sorts of names that
Cafe creates) isn't going to work when I have an application with thirty
dialogs. Hey, I was a COBOL programmer for five years. I'mused to long
variable names!
Ken Litwak
Daniel F. Savarese
In article <33EAAC1C...@itools.symantec.com>,
D'Arcy Smith <d...@itools.symantec.com> wrote:
> - constants - public, protected, package, private
> - variables - public, protected, package, private
> - methods - public, protected, package, private
>
> - public members have no prefix
> - non-public memeber start with an "_"
>
> - all variables are declared at the start of the block that
> they are used in
At ORO, we think scoping in Java is much more important than typing issues
that lead people to use things like Hungarian notation. We use a convention
similar to the one you mention, but we take it to an extreme:
o public members and local variables have no prefix
o default scope members start with a "_"
o protected members start with a "_" and end with a "_"
(e.g, protected int _foo_;)
o private members start with a "__"
This makes it immediately obvious to a programmer what the scope of a variable
is. We do this only because our own experience is that when creating Java
packages and trying to properly control the level of data encapsulation,
that being aware of variable scope is vastly more important than variable
type.
>Its all religious.
I agree that it definitely comes down to a matter a preference. But I think
the kind of issues people had in C programming that led them to things
like Hungarian notation do not apply so much in Java. Although, I don't
see anything wrong with hand generated GUI code having variable names like
fooPanel or barCanvas which indicate what type of AWT component a variable
is. To each his own. As long as the system you choose is productive for your
organization (i.e., minimizes bugs and code maintenance, etc.), then it
can't be faulted if applied consistently.
daniel
orororororororororororororororororororororororororororororororororororororororo
Daniel F. Savarese email: d...@oroinc.com
ORO, Inc. "Component software for the Internet."tm http://www.oroinc.com/
orororororororororororororororororororororororororororororororororororororororo
Ralph Richard Cook
mcov...@aisun1.ai.uga.edu (Michael Covington) wrote:
>I hear you. I think the best variable names are those that actually
>tell you what the variable does. If the data structures are well
>designed, the type of the variable should be fairly obvious from its
>function. I use "Hungarian-style" names only for minor variables that
>are used briefly or would otherwise conflict, e.g.,
>LocalDocumentationStrings and then pLocalDocumentationStrings if
>for some reason I also have to have a pointer to it.
>
>I do use rather *long* variable names. For those who hate to type,
>these can be typed short, then lengthened by a global change in
>the editor.
In your Java code how are people (or are they) distinguishing object
member variables from local variables, and both from function
parameters. In my own code so far I'm borrowing the "m_" notation from
MFC, but I'd like to use the Java standard, even if it's de facto.
----------------------------------------------
Ralph Richard Cook's Java Opinions and Applets
http://personal.atl.bellsouth.net/atl/r/a/ralphc/java/
Leo Bellew
In math and science, the formal manipulation of a formula is
important, and the rules for finding a solution by manipulating the
formula are independent of the meaning of the variables, except
perhaps for their numerical type. It makes sense that the formula use
short, abstract names to illuminate the formula's essence.
In business programming, the meaning of the variables is more at issue
than the abstract algorithmic manipulations. In this case, the "type"
tends to be the noun: date, amount, quota, ratio, percent, ... These
go at the end of the phrase in English:
SalesDate ExpenseDate
SalesAmount ExpenseAmount
SalesQuota ExpenseRatio
It is always possible to objectify these:
Sales.Date Expense.Date
Sales.Amount.Dollars Expense.Amount.Dollars
Sales.Amount.Marks Expense.Amount.Marks
Sales.Quota Expense.Ratio
In systems programming, the machine properties of the variable are
more important than in either math/science or business. Here it makes
sense to talk about long pointers and abbreviate that as "lp" and put
it at the front of the variable. Here Hungarian seems really helpful.
Leo
On 07 Aug 1997 11:43:22 -0400, Chris Paris <c...@cmu.edu> wrote:
>mcov...@aisun1.ai.uga.edu (Michael Covington) writes:
>
>> I do something similar:
>>
>> i, j, k, m, n are temporary integers or loop counters (note: not l)
>>
>> c, d are temporary chars
>>
>> s, w are temporary strings (how I arrived at w I'm not sure)
>>
>> x, y, z, t, t1, t2... are temporary floats or doubles
>
>Note that such conventions are pervasive in mathematics and physical
>sciences. I'm not sure what to deduce from that, but at least these
>conventions have been around for a long time. Perhaps our problem is
>that every programmer has her own personal conventions for these
>"local" variable names, whereas in other disciplines the short
>symbolic names tend to have a standard meaning.
>
>Chris
Tom Valesky
Patrick Doyle (doy...@ecf.toronto.edu) wrote:
: I think having to look up a variable's declaration is a small price to
: pay for code readability.
: Code readability is highly underrated, in my opinion.
I agree, strongly. Of course, it's possible to write unreadable code even
without Hungarian notation, but variables named, say, glpszName are
guaranteed to be unreadable. It gets really interesting when
organizations start tacking on extra "helpful" information. It gets even
more interesting when combined with an environment like MS Windows, where
the number of types available seems to grow without bound.
I once worked at a shop that was so bitten by the Hungarian bug that the
following code
for (i = 0; i < 10; i++)
wasn't allowed past a walkthrough until it was changed to
for (ii = 0; ii < 10; ii++)
--
===========================================================================
Tom Valesky -- tval...@patriot.net
http://www.patriot.net/users/tvalesky
Patrick Doyle
In article <33EC1699...@scruz.net>,
Scott Stanchfield <the...@scruz.net> wrote:
>
>One of the biggest points of OO programming is encapsulation -- you
>shouldn't _care_ about the details, only the interface, if things are
>designed well.
I agree with what you said, and I don't like Hungarian notation.
But the fact is that types are all about interfaces, so putting
type information in a variable could arguably still be important
in OOP, if it's done properly.
But I don't want to develop this idea any further because I might
just have to start using HN. :-)
Gerry Quinn
I like to use m_Blah for most member variables, but for certain common things
like controls, images or sounds I use but_Blah, gif_Blah, or au_Blah.
Local variables are lowerUpper, and classes are UpperUpper in C++. Java
annoys me a bit when it uses my local variable convention for methods - I
still haven't settled on what I want to do here.
- Gerry
==================================================================
Mailto: ger...@indigo.ie (Gerry Quinn)
Original puzzlers (Windows or Amiga)-> http://indigo.ie/~gerryq
==================================================================
Jeffrey C. Dege
On Sun, 10 Aug 1997 15:13:47 GMT, Patrick Doyle <doy...@ecf.toronto.edu> wrote:
>In article <33EC1699...@scruz.net>,
>But the fact is that types are all about interfaces, so putting
>type information in a variable could arguably still be important
>in OOP, if it's done properly.
Except, of course, that if you are doing OOD correctly, you end up
with a very rich type system. The problem with HN, as implemented
by Microsoft, isn't that they embed type information in their
variables, but that all of their variables are low-level machine
types. They could define a window handle as an instance of
a window handle type, and define wh as a window handle HN prefix.
Seeing whXxxx might then tell me something useful. Instead, of course,
Microsoft defines a window handle as an instance of a long int, and
names window handles as lXxxx, which tells me absolutely nothing.
Can I use an lXxxx anywhere I can use a long? To what purpose?
Can I use any long as a window handle? What will happen if I try?
--
"[I]n fact, I didn't know that cats _could_ grin."
"They all can," said the Duchess; "and most of 'em do."
"I don't know of any that do," Alice said very politely, feeling quite
pleased to have gotten into a conversation.
"You don't know much," said the Duchess; "and that's a fact."
Ell
Doug Frietchen (fri...@erols.com.NOSPAM) wrote:
:
: IMHO, deducing the type from first char was more dangerous than
: useful. If you made a typo, rather than give you an error message,
: suddenly you had a new variable set to 0 !
If I mistype a variable's name in my C++ definition code, I get compile,
or link error.
Dean Roddey
> >
> >One of the biggest points of OO programming is encapsulation -- you
> >shouldn't _care_ about the details, only the interface, if things are
> >designed well.
>
> I agree with what you said, and I don't like Hungarian notation.
> type information in a variable could arguably still be important
> in OOP, if it's done properly.
>
As I pointed out in a previous post on this thread, a 'family prefix' is
exactly what you are talking about and what I use. Every class derived
from the base window class uses 'wnd', every class derived from the base
string class uses 'str'. This provides a lot of self documenting code,
without losing any encapsulation because the prefix represents the same
level of abstraction as is being modelled.
Only if a very few places, where a derived class becomes VERY
specialized and potentially spawns its own family of derivatives will I
give it a new prefix. I've only done that a couple times in my whole
system.
This scheme keeps prefixes down to a quite manageable number, but it
makes it obvious what family of classes an object belongs to (and
therefore what its basic interface and capabilities are.)
Those folks who say "Just use the browser" must not be working on large
scale systems. That browser information generation can add significantly
to the build time of every rebuild if the system is large. Its just not
worth it for me. And, it kind of ignores the fact that often times code
is read outside of any built system, such as code review meetings or on
an airplane to a customer site or whatever.
In general, a lot of the anti HN arguments tend to be reactions to bad
use of it by someone else, which is also a lot of the arguments for why
Java can't do something (because someone misused in C++.) I never find
these arguments very compelling personally. Some people put their own
eyes out with kitchen utensils, but I prefer to use them because they
make it a lot easier for me to eat when used correctly.
John A. Grant
Adrian Milliner <adr...@NOSPAMrefine.co.uk> wrote in article
<33e98a49....@news.ftech.net>...
> On Wed, 06 Aug 1997 19:58:24 GMT, "John Burton" <j...@mail.com> wrote:
>
> >Do you really have so many variable that you can't remember
> >what they do? I'd suggest doing a bit more design on your
> >code.
>
> required. Many classes with many member variables. C code with struct
> members. Even plain old globals.
>
> In fact, just about every project I've ever worked on had many
> hundreds, if not many thousands of variables (member or otherwise).
>
> Occasionally, in really bizarre cases, more than one person works on a
> project, so there could be variables that you would have no knowlege
> of.
>
> From the comment you made, it sounds like you've never actually worked
> on a project bigger than "hello, world".
>
> Of course if you were refering to local(auto) variables, then your
> point is well made and I apologise for my sarcasm. But I doubt it,
> somehow.
I wouldn't say a code redesign is necessary if there is confusion
with the variable names. Usually, all that is required is a little more
common sense in choosing variable names.
Personally, I think Hungarian notation sucks and I work on 100k+ loc
projects, not 'hello world'. Admittedly, I'm the only one writing the code,
so I can get away with it. I'm in the fortunate position of not having
these silly things imposed upon me by 'project standards'. And I don't
think anyone would have any difficulties in understanding my code
because of variable names.
I find it very difficult to believe that people need to use things like
'lpszfilename' (i.e. as in Windows) to indicate that it is a 'long pointer
to a zero-terminated string'. I mean really, could 'filename' be anything
but a 'char pointer' or 'char array'? Nobody in their right mind would
mistake 'filename' for any kind of integer or float or object.
The concept of using an 'n' prefix to indicate an integer:
for(int ncount=0;ncount<...
is absolutely ludicrous. Almost everyone is familiar with math terminology
that routinely uses i,j,k for subscripts of arrays:
n m
---- ----
\ \ X
/ / i j
---- ----
i=0 j=0
and so the direct anology is to use the following
for(i=0;i<n;i++){
for(j=0;j<m;j++)
}
}
If you want to add in a bit of context, you will probably use variables
that are more specific to the application:
for(ifile=0;i<nfile;i++)... //iterating through a table of files
or
for(irow=0;irow<nrow;irow++){
for(jcol=0;jcol<ncol;jcol++){
My point is that i,j,k are traditionally used as subscripts and 'n' is
traditionally used for 'the NUMBER of things'. It makes a lot of sense:
'Nfile' is the 'Number of files', 'Nitem' is the Number of items'. It is
absurd
to use 'n' just to indicate an integer, when it can have a far more useful
role as an indicator of the 'Number' of things.Once you have painted
yourself in a corner because all variables that begin with 'n' are integers,
then you are forced to use absurd names like:
for(nfile=0;nfile<nnfile;nfile++)
or
for(n_file=0;n_file<n_nfile;n_file++)
both of which are just plain silly. Couple that with the 'm_' and 'g_'
prefixes
to indicate their scope and you have unreadable code.
And what about this mixed case variable name nonsense? To me,
constants are UPPERCASE, functions are MixedCase() & variables
are *ALWAYS* lowercase. In my mind, there is a hierarchy of
'importance' and 'volatility'. Variables are the most volatile and the
least important (to the 'flow' of the code) and usually have the
smallest scope, so they are always lowercase. At the other end
are constants, with more global scope and certainly permanency,
so they are always uppercase. Using mixed case variable names
makes it very difficult to scan code and pick out the function
calls because function calls are also MixedCase(), or in the case
of Java, mixedCase(). If you want to be able to see the 'flow' of
your code (i.e. 'active' things like function calls), then use lowercase
for variable names (so they fade into the background) and MixedCase
for function names.
And what about 'the', as in:
PICTURE thePicture=new PICTURE;
TABLE theTable= new TABLE;
URL theUrl= new URL;
DIALOG theDialog= new DIALOG;
Who started this silly practice? It reeks. Are people so lacking in
creativity and imagination that they can't choose a better variable
name? I can think of much more meaningful names:
PICTURE backgroundpic=new PICTURE;
TABLE customers= new TABLE;
URL homepage= new URL;
DIALOG about= new DIALOG;
Well, enough already. The same could be said about many of the other
absurdities I see in Hungarian notation. The unfortunate thing is that
this nonsense has run rampant in the C++ (Windows) world and is
now finding its way into Java code, making it just as unreadable as
Windows code. A common sense choice of variable names will go
a lot farther in making your code readable and understandable than
a lot of extra prefixes. If you think that this:
for(nCount=0;nCount<m_gnFile;nCount++)
TABLE g_theTable=new TABLE;
g_theTable.Add("John Doe");
is more readable or easier to type than:
for(i=0;i<nfile;i++)
TABLE customers=new TABLE;
customers.Add("John Doe");
then you have indeed gone over to the Dark Side and you are lost.
Patrick Doyle
In article <5sk74p$78g$1...@news.indigo.ie>, Gerry Quinn <ger...@indigo.ie> wrote:
>I like to use m_Blah for most member variables, but for certain common things
>like controls, images or sounds I use but_Blah, gif_Blah, or au_Blah.
>
>Local variables are lowerUpper, and classes are UpperUpper in C++. Java
>annoys me a bit when it uses my local variable convention for methods - I
>still haven't settled on what I want to do here.
You can tell methods without a convention. They're the ones with
the parentheses. :-)
Incidentally...
I always thought this was a bit backwards. For example, if I get a
dog and call him Dog, then "dog" is the class and "Dog" is the instance.
The convention you refer to seems to be at odds with regular english
usage.
Matt Kennel (Remove 'NOSPAM' to reply)
On Tue, 05 Aug 1997 10:59:42 -0400, Richard J Kucera <kuc...@hhmi.org> wrote:
:As someone who's actually had to maintain
:and re-use someone else's code fragments, I have to say
:that naming standards practices of indicating type in variable
:name is wasteful and unnecessary.
It *really* sucks when somebody changes the type, which is rather
frequent in a statically typed language, and doesn't bother to change the
variable name since it would be too much of a pain in all the various
pieces of code and documentation.
One of these screwups negates 100 small microwins from the type encoding.
Del Archer
David Harmon wrote:
> ...
> The cannonical example being wParam and lParam in MS Windows programs.
> In the 16-bit API, wParam was a "word" (16-bit int) and lParam was a
> "long" (32-bit int). In the new 32-bit API, they are both 32 bits,
> but for some unknown reason, Microsoft overlooked changing the name of
> wParam in all their SDKs and documentation. For maximum accuracy and
> clarity, they should obviously both be named lParam.
Actually, wParam is declared as type WPARAM, not WORD. WPARAM is defined as
16-bits for Windows 3.x and 32-bits for Win32.
Del.
Chris Quartetti
> What's so hard about using a global search and replace?
Nothing, but you touch more code. If somebody comes along after you and
looks at your changes by diffing the file against the previous version,
s/he'll get a much larger diff for a very small change.
-Chris
Dave Harris
jag...@nrcan.gc.ca (John A. Grant) wrote:
> And what about this mixed case variable name nonsense? To me,
> constants are UPPERCASE, functions are MixedCase() & variables
> are *ALWAYS* lowercase. In my mind, there is a hierarchy of
> 'importance' and 'volatility'. Variables are the most volatile and the
> least important (to the 'flow' of the code) and usually have the
> smallest scope, so they are always lowercase. At the other end
> are constants, with more global scope and certainly permanency,
> so they are always uppercase. Using mixed case variable names
> makes it very difficult to scan code and pick out the function
> calls because function calls are also MixedCase(), or in the case
> of Java, mixedCase(). If you want to be able to see the 'flow' of
> your code (i.e. 'active' things like function calls), then use
> lowercase for variable names (so they fade into the background)
> and MixedCase for function names.
For me the difference between constant and variable is a matter of time
scale, not an absolute. Sometimes I write code using a constant and then a
later change makes it a variable. Or it's a constant that gets fixed at
runtime rather than compile time. Further, I dislike using reassignment:
I'd rather introduce a new variable than change the value of an old one,
if I can. So, once defined, my variables don't vary. The upshot is that I
don't like encoding constantness into the variable name.
My main languages are C++ and Java, and both of them require brackets
after function names so nothing further is needed to distinguish them. I
like Eiffel's convention of putting classname into upper case, though.
Class names carry a lot of information so it's good to make them stand
out. This is especially true for readers who don't know the language very
well (eg when posting code on Usenet). Also, in languages that allow
variables to be declared at the point of first use, the declarations can
get lost in the midst of other code.
I don't really agree about the relationship between global scope and
permanency. I do think that scope is worth distinguishing in names.
Dave Harris, Swansea, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
Alf P. Steinbach
> > constants are UPPERCASE, functions are MixedCase() & variables
> > are *ALWAYS* lowercase. In my mind, there is a hierarchy of
> > 'importance' and 'volatility'. Variables are the most volatile and the
> > least important (to the 'flow' of the code) and usually have the
> > smallest scope, so they are always lowercase. At the other end
> > are constants, with more global scope and certainly permanency,
> > so they are always uppercase. Using mixed case variable names
> > makes it very difficult to scan code and pick out the function
> > calls because function calls are also MixedCase(), or in the case
> > of Java, mixedCase(). If you want to be able to see the 'flow' of
> > your code (i.e. 'active' things like function calls), then use
> > lowercase for variable names (so they fade into the background)
> > and MixedCase for function names.
>
> scale, not an absolute. Sometimes I write code using a constant and then a
> later change makes it a variable. Or it's a constant that gets fixed at
> runtime rather than compile time. Further, I dislike using reassignment:
> I'd rather introduce a new variable than change the value of an old one,
> if I can. So, once defined, my variables don't vary. The upshot is that I
> don't like encoding constantness into the variable name.
I think John was talking about #define constants, e.g. in C. There's a
good reason to always use uppercase for macro names, and only for them:
it partitions the name space so you cannot accidentally write some
non-macro code which a macro (you don't know about) will change. But
the best thing is, of course, to avoid macros where C++ has syntactic
support, e.g. constants. Unfortunately, C'isms won't disappear...
My personal style is like this:
Macro: ALL_UPPERCASE_SO_TO_BETTER_AVOID_USING_THEM
Function: MixedCase,
because functions can and *do* appear
with no argument list, and want to know when.
var, type, const: this_style_is_simply_best
some pointers: p_whatever, pp_whatever
the p_ prefix is sometimes useful, but most often redundant!
loop indices: i, j
The main rationale for this style is that things that can (easily)
change should not be hard-coded in name styles. So no hardcoding of
types etc.
- Alf
Nathan Fiedler
Patrick Doyle wrote:
> Scott Stanchfield <the...@scruz.net> wrote:
> > One of the biggest points of OO programming is encapsulation -- you
> > shouldn't _care_ about the details, only the interface, if things are
> > designed well.
>
> I agree with what you said, and I don't like Hungarian notation.
> But the fact is that types are all about interfaces, so putting
> type information in a variable could arguably still be important
> in OOP, if it's done properly.
>
> just have to start using HN. :-)
I have a question for everyone: Are you basing your choice of naming
convention purely on opinion or have you read a book about this kind of
thing? I agree with Steve McConnell's argument for Hungarian Notation in
"Code Complete" and I've used it myself when writing in C. Now that I'm
writing in Java I've just been naming variables in whatever way makes
sense at the time.
I have yet to be confused about which variables are local, member
variables, methods, or parameters. I suppose it's because, as one
gentleman said, there are so few variables within the scope of any given
method that it would be difficult to lose track of their meaning. At the
same time I agree that Java could use a simple convention for
distinquishing methods from member variables. Currently they are named
using the same lowerUpper convention with no other distinction. In
contrast, GEOS uses a very strict convention for naming instance fields
and message names, making it impossible to mistake what a variable or
message is for.
Nathan Fiedler
Patrick Doyle
In article <5sl66p$dlb$3...@news2.digex.net>, Ell <e...@access2.digex.net> wrote:
>Doug Frietchen (fri...@erols.com.NOSPAM) wrote:
>:
>: IMHO, deducing the type from first char was more dangerous than
>: useful. If you made a typo, rather than give you an error message,
>: suddenly you had a new variable set to 0 !
>
>If I mistype a variable's name in my C++ definition code, I get compile,
>or link error.
Hey, um, do you think that's because C++ doesn't deduce the type
from the first character?
Just a thought.
Jonas Andersson
On Sat, 09 Aug 1997 12:52:44 -0700, kdlitwak <kdli...@concentric.net>
wrote:
I used to append the tyoe of the variable to the name but nowadays I
don't. Instead, I write short methods 20 lines max avg 5 lines(fast
check up is possible with this visibility). I also use 2 prefixes one
for attributes, m, and one for associations, a.
I notice that in 95% of the cases there is never any confusion/need to
know about the type of the object and if it is a need to know then the
object is so important that you should take a look at the object
diagram.
Jonas
---------------------------
Jonas Andersson
E-mail: jonas.a...@adiuvabo.se
Patrick Doyle
In article <memo.19970811...@btinternet.com>,
Dave Harris <bran...@cix.co.uk> wrote:
>
>My main languages are C++ and Java, and both of them require brackets
>after function names so nothing further is needed to distinguish them. I
>like Eiffel's convention of putting classname into upper case, though.
>Class names carry a lot of information so it's good to make them stand
>out. This is especially true for readers who don't know the language very
>well (eg when posting code on Usenet).
I agree with your comments about Eiffel. I didn't like the convention
at first, because there's the problem of finding variable names which
should be the same as the class name. That is, if your CAR class contains
an instance of a STEERING_WHEEL class, why call it anything other
than steering_wheel? It makes no sense to come up with a contrived
name like direction_changer. It's the car's steering wheel, so call
it that.
In C++, typically the class would be CSteeringWheel and the
variable could be SteeringWheel or steeringWheel. In fact, being
case-sensitive, the class could be steeringWheel and the variable
could be SteeringWheel. No problem.
Then I discovered that Eiffel lets you have a variable with the
same name as a class, which I think is fantastic.
Languages that disallow this are IMHO solving a problem
that doesn't exist.
(It seems that every time I learn more about Eiffel, I think to
myself "if I were designing the language, that's how I would
have done it!" Except of course for the total lack of superclass
encapsulation. :-)
Jonas Andersson
On 07 Aug 1997 11:43:22 -0400, Chris Paris <c...@cmu.edu> wrote:
>mcov...@aisun1.ai.uga.edu (Michael Covington) writes:
>
>> I do something similar:
>>
>> i, j, k, m, n are temporary integers or loop counters (note: not l)
>>
>> c, d are temporary chars
>>
>> s, w are temporary strings (how I arrived at w I'm not sure)
>>
>> x, y, z, t, t1, t2... are temporary floats or doubles
>
>Note that such conventions are pervasive in mathematics and physical
>sciences. I'm not sure what to deduce from that, but at least these
>conventions have been around for a long time. Perhaps our problem is
>that every programmer has her own personal conventions for these
>"local" variable names, whereas in other disciplines the short
>symbolic names tend to have a standard meaning.
>
>Chris
Having studied the physics and mathematics, I think that this is a
major problem of respective fields.
You cannot understand a formula without:
1. Prior knowledge about the problem. Familiarity with the common
domain names.
2. Explanatory text.
I think that the main reason for this is historical i,e that
mathematicians used hanwriting and simplifyind formulas. IMHO it
doesn't justify the unclearity of formulas presented in textbooks now.
A simp,le search replace operation in a textbook would add a lot of
clarity.
Jonas Andersson
On 9 Aug 1997 05:35:41 GMT, e...@access1.digex.net (Ell) wrote:
>
>What's so hard about using a global search and replace?
I can by accident have used the same variable name in several places,
local variables, and only changed the type of one.
William Harris
In article <33EF3788...@earthlink.net.remove>,
nfie...@earthlink.net.remove says...
>thing? I agree with Steve McConnell's argument for Hungarian Notation in
>"Code Complete" and I've used it myself when writing in C. Now that I'm
>writing in Java I've just been naming variables in whatever way makes
>sense at the time.
"One benefit to using Hungarian names is that it makes it easier to decipher
pointer expressions." (from Maguire's Writing Solid Code, a book that scares
me as much as it encourages me about Microsoft programming practices. :-)
I tend to agree that in a Windows environment, it can become a lot more
important to tell at a glance whether something is an lpsz, or whether a
particular variable is a hwnd. That, I think, may be the single biggest
reason why so many people adopted it.
But I find it harder to argue for it in a Java environment, for many of the
same reasons others have given.
--
William Harris wil...@carsinfo.com
Check out the NAGS spam filter. http://www.cs.hmc.edu/~ivl/nags/index.html
Michael Davis
In article <5sq7ci$d7h$1...@malgudi.oar.net>,
William Harris <wil...@carsinfo.com> wrote:
>In article <33EF3788...@earthlink.net.remove>,
>nfie...@earthlink.net.remove says...
>>thing? I agree with Steve McConnell's argument for Hungarian Notation in
>>"Code Complete" and I've used it myself when writing in C. Now that I'm
>>writing in Java I've just been naming variables in whatever way makes
>>sense at the time.
>
>"One benefit to using Hungarian names is that it makes it easier to decipher
>pointer expressions." (from Maguire's Writing Solid Code, a book that scares
>me as much as it encourages me about Microsoft programming practices. :-)
>
>I tend to agree that in a Windows environment, it can become a lot more
>important to tell at a glance whether something is an lpsz, or whether a
>particular variable is a hwnd. That, I think, may be the single biggest
>reason why so many people adopted it.
>
>But I find it harder to argue for it in a Java environment, for many of the
>same reasons others have given.
I agree. Hungarian notation was introduced by a Microsoft employee.
If you've ever done Windows programming, and looked at the windows.h file,
you'll see that there are dozens of types defined that mostly all reduce
down to an unsigned integer ( e.g. HWND ), or a pointer to void.
That makes it easy to make mistakes like passing a handle to a palette
to a function that expects a handle to a window, or whatever. The compiler
can't catch such mistakes when everything is typedef'd to an
unsigned int or a void pointer.
In that kind of environment, Hungarian names help prevent some mistakes.
In Java, and in other C++ GUI environments which have truly different
types instead of different names for the same type, Hungarian names
are less useful because the compiler will catch many more type-related
problems.
Regards,
--
// Michael Davis, Programmer/Analyst I don't speak for Multipath. //
// mda...@DELmultipath.com Nor do I speak against them. //
// Toronto The 'DEL' in my address is an anti-spam device. //
Warren Young
sou...@netcom.com (David Harmon) wrote:
>On Fri, 08 Aug 1997 23:53:38 -0500, "Robert C. Martin"
><rma...@oma.com> wrote:
>>redundant and supplies little benefit. On the other hand, that
>>info is a rather large liability since if must be changed if the
>>variable type ever gets changed. The impact of such a change is
>>so high that often the variable name *will not* be changed even though
>>the type is.
>
>The cannonical example being wParam and lParam in MS Windows programs.
>In the 16-bit API, wParam was a "word" (16-bit int) and lParam was a
>"long" (32-bit int). In the new 32-bit API, they are both 32 bits,
>but for some unknown reason, Microsoft overlooked changing the name of
>wParam in all their SDKs and documentation. For maximum accuracy and
>clarity, they should obviously both be named lParam.
This sort of issue is responsible for the latest evolution in my
naming style. Way back when, I started with a milder form of
Hungarian. As time went on, I found what a pain it was to keep
inventing new, nonconflicting, short type abbreviations. I also found
that it didn't help all that much, and that it tended to lower the
level of abstraction in the code.
Recently, I've adopted this form:
p = pointer
a = array
2, 3, etc. = array dimension
c = character
s = string (C++ string type, not char*, which is "pc")
n = numeric type
e = enumerated type
k = constant, usually integral, although kpc is also used.
g = global
and that's it [1]. Notice that the notation avoids primitive types.
Except for "pc" versus "s" (discussed below), this notation is largely
language and platform independent. These prefixes are mostly
modifiers and general classifiers, rather than actual type
information.
As for type information, I find that if you need that at all, you just
need an "abstract" type in the variable name proper. So instead of
pbmpFoo (pointer to bitmap foo), you get pFooBitmap. I make sure to
keep the abstract nature of this form in mind. For example, I never
say FooVector, preferring FooList, because it lets me change the type
(within reason) and not have to rename all of the variables.
The limited "Hungarian" form (I guess I should call it
"Hungarian-American", since it's been so diluted <grin>) I use has
these advantages:
1. It makes it easy to tell what general class of operations are valid
for a particular variable. The "p" and "a" prefixes are especially
useful, because they help keep the dereferences straight -- this is
critical in C++, where a language like Java doesn't have this need.
As an example, consider a 2-D array of pointers to bitmaps. (Yes,
I've used constructs like this!) The variable is a2pFooBitmap.
Without this minimal amount of type encoding, you have to constantly
keep looking up the declaration to make sure everything is consistent.
The notation really proves its value when you begin mixing levels of
indirection.
2. The "n" prefix lets me know that a variable can be manipulated with
arithmetic.
3. The "k" type lets me know that an entity is constant. In a way,
it's my C++ way of saying what I would have said with an ALL-CAPS
#define in C. Also, "k" alone implies "kn", because other types of
constants use modifiers. Also, I only use "k" for global constants,
rather than for constant parameters. I may evolve this quirk out
soon, however.
4. The "e" prefix is similar to "n", but it lets me know that while a
value is basically numeric, it has a strict range of named values that
are legal for it, so it throws red flags when I say something like
"eFoo = nBar;". Also note that the _members_ of the enumerated type
are prefixed with "k", because they are. B-) So, we have "enum Foo {
kBar, kBaz } eQux = kBar;"
5. The "pc" and "s" types let me know what kind of string I'm dealing
with. This is simply a "transitional" C/C++ thing that probably has
no use in other languages. Maybe "pc" will die some day. (No, that's
not a triple entendre. I promise. B->)
6. The "g" type lets me know where a given variable is. If you also
use m_ or a trailing _ for member variables, hunting is largely
eliminated, and this can only be a good thing.
In sum, this to me is just one of those good disciplines that keeps
your mind nicely focused on the task at hand, rather than on the
niggling details of the mechanisms. Once you use this form for a
while, the prefixes become second-nature and comforting. It off-loads
a lot of type mixing anxiety, because it's easy to verify that the
types are interacting properly. "Classic Hungarian", on the other
hand, seems almost exactly opposite to this: you spend all your time
appeasing the notation, rather than thinking about the problem.
[1] I've also been experimenting with a trailing _ for member
variables (m_ looks horrid to me).
= Warren -- http://www.cyberport.com/~tangent/
=
= Remove the SPAMCATCHER to email. -- Finger me!
Jeff Miller
e...@access1.digex.net (Ell) writes:
>Robert C. Martin (rma...@oma.com) wrote:
> On the other hand, that
>: info is a rather large liability since if must be changed if the
>: variable type ever gets changed. The impact of such a change is
>: so high that often the variable name *will not* be changed even though
>: the type is.
>What's so hard about using a global search and replace?
But what if your Hungarian notation is used in the naming of
an element of a structure that is defined in a header file?
You have absolutely no way of knowing who is using that file
in their code. Accordingly, you have no way of knowing what
code to examine with your global search and replace.
Jeff Miller
Terrapin Technologies, Inc.
jmi...@cycletime.com
http://www.cycletime.com
Peter Eddy
This is a multi-part message in MIME format.
--------------3B55D15B811ADC275139E27B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I'm really fond of the m_ notation for member variables myself. I
particularly like how the following code reads:
public void setColor( Color color ) { m_color = color; }
That is to say, you don't have to invent a name for the parameter that
is less descriptive than the member variable name and you don't have to
resort to the clumsy and probably error prone "this.color = color".
My only reserveration is that the '_' is hard to type.
Peter
Ralph Richard Cook wrote:
>
> In your Java code how are people (or are they) distinguishing object
> member variables from local variables, and both from function
> parameters. In my own code so far I'm borrowing the "m_" notation from
> MFC, but I'd like to use the Java standard, even if it's de facto.
--
Peter Eddy
Folding Chair Software
Columbus Ave.
Boston, MA
http://www.ziplink.net/~petere/fcs.html
pet...@bigfoot.com
--------------3B55D15B811ADC275139E27B
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Peter Eddy
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Peter Eddy
n: Eddy;Peter
org: Folding Chair Software
email;internet: pet...@bigfoot.com
title: Contractor
x-mozilla-cpt: ;0
x-mozilla-html: TRUE
end: vcard
--------------3B55D15B811ADC275139E27B--
Ma...@mwilden.com
Aaron D. Wieland wrote:
>
> On Wed, 13 Aug 1997 09:44:03 -0400, Peter Eddy <pet...@bigfoot.com>
> wrote:
> >I'm really fond of the m_ notation for member variables myself. I
> >particularly like how the following code reads:
> >
> >public void setColor( Color color ) { m_color = color; }
> >
> >That is to say, you don't have to invent a name for the parameter that
> >is less descriptive than the member variable name and you don't have to
> >resort to the clumsy and probably error prone "this.color = color".
It does indeed appear to be error prone. :) I gave the m_ notation a try
for a while (together with the rest of Microsoft's pseudo-Hungarian),
but reverted back to natural variable names on my current project, and I
haven't missed it.
> >
> >My only reserveration is that the '_' is hard to type.
>
> Alternately, if you don't use the m_ notation, you can write the code
> as:
>
> public void setColor( Color aColor ) { color = aColor; }
I use
public void setColor(Color color) { this->color = color; }
Yes, it's more typing, but I don't have to think of an artificial
variable name.
In a constructor's base/member init-list, this isn't even necessary,
since you can do
Class::Class(Color color) : color(color) {}
Aaron D. Wieland
On Wed, 13 Aug 1997 09:44:03 -0400, Peter Eddy <pet...@bigfoot.com>
wrote:
>I'm really fond of the m_ notation for member variables myself. I
>particularly like how the following code reads:
>
>public void setColor( Color color ) { m_color = color; }
>
>That is to say, you don't have to invent a name for the parameter that
>is less descriptive than the member variable name and you don't have to
>resort to the clumsy and probably error prone "this.color = color".
>
Alternately, if you don't use the m_ notation, you can write the code
as:
public void setColor( Color aColor ) { color = aColor; }
I.e., you avoid using a less descriptive name by prepending an article
to the parameter. This convention is particularly common among
Smalltalk programmers.
-- Aaron Wieland
Tran Phan Anh
Aaron D. Wieland wrote:
>
> On Wed, 13 Aug 1997 09:44:03 -0400, Peter Eddy <pet...@bigfoot.com>
> wrote:
> >I'm really fond of the m_ notation for member variables myself. I
> >particularly like how the following code reads:
> >
> >public void setColor( Color color ) { m_color = color; }
> >
> >That is to say, you don't have to invent a name for the parameter that
> >is less descriptive than the member variable name and you don't have to
> >resort to the clumsy and probably error prone "this.color = color".
> >
> >My only reserveration is that the '_' is hard to type.
>
> Alternately, if you don't use the m_ notation, you can write the code
> as:
>
> public void setColor( Color aColor ) { color = aColor; }
I use this convention, and I find it to be a very convenient
convention. A quick look, and one knows where the variable came from
right away. That's the only variable name decoration I use. Otherwise,
I find 'type decorations' on variables name to be a really disgusting
practice.
Anh
Jonas Andersson
>On Wed, 13 Aug 1997 09:44:03 -0400, Peter Eddy <pet...@bigfoot.com>
>wrote:
>>I'm really fond of the m_ notation for member variables myself. I
>>particularly like how the following code reads:
>>
>>public void setColor( Color color ) { m_color = color; }
>>
>>That is to say, you don't have to invent a name for the parameter that
>>is less descriptive than the member variable name and you don't have to
>>resort to the clumsy and probably error prone "this.color = color".
>>
>>My only reserveration is that the '_' is hard to type.
>
>Alternately, if you don't use the m_ notation, you can write the code
>as:
>
>public void setColor( Color aColor ) { color = aColor; }
>
>I.e., you avoid using a less descriptive name by prepending an article
>to the parameter. This convention is particularly common among
>Smalltalk programmers.
>
>-- Aaron Wieland
>
I personally think that the aColor, or anObject, convention is a bad
idea. The name as used in Smalltalk usually is a poor substitue for
lack of tye definition. I prefer the use of a meaningful name and the
m prefix as in:
public void setColor(Color newColor) {mColor=newColor;}
Just my point of view.
Ma...@mwilden.com
Patrick Doyle wrote:
>
> In article <5sch5e$ekv$3...@news2.digex.net>, Ell <e...@access5.digex.net> wrote:
> >Ma...@mWilden.com wrote:
> >:
> >: I have no problem using nChickens to designate the number of chickens in
> >: a program, because I usually don't care what its internal representation
> >: is. At some point, I did, so I made it an unsigned char, unsigned int,
> >: unsigned short, unsigned long or whatever. But having made that choice,
> >: the rest of the application doesn't have to cart around this baggage
> >: every time I use the variable--it just needs to know that nChickens
> >: counts chickens.
> >
> >But how about the possibility that you will corrupt the integrity of the
> >meaning of the data in the variable if you assign for example an
> >unsigned value to a signed variable?
>
> *Even C* should warn you about that one. And for types that are truly
> incompatible, it won't work anyway.
Dang. Lately it seems that my newserver has been missing more messages
than it's getting! Anyway, thanks Patrick, for giving the answer I'd
have given.
Also, WRT signed/unsigned, a count (of chickens, e.g.) is by its nature
unsigned. I don't need to specify this in the variable name. I just need
to indicate that the variable holds the number of chickens.
Ma...@mwilden.com
Ell wrote:
>
> Hugarian sure helps me as the programmer writing the code which is sent to
> the compiler. You being one who is often railing against having to
> re-compile, should see that one shouldn't wait for a compile or link to
> find an error.
Frankly, this kind of error doesn't happen that much in my experience.
Certainly not as often as leaving out a paren. :) Maybe it's because
most variables are either data members, whose type and purpose is part
of the design, and hence well understood, or locals/parameters, whose
type I can determine (if it's not obvious, which it usually is) just by
looking a few lines back in the source.
I've given Hungarian a shot, but it didn't catch many errors compared to
the amount of time it takes to implement it for every single variable
name use.
> What's so hard about using a global search and replace?
It's not hard, but it does have drawbacks. For example, let's say I
decide that my unsigned char isn't large enough any more to count the
number of chickens on my farm and I change it to an unsigned int. I
globally search and replace to change the variable name. Now, I'd have
to recompile everything anyway, so that's not the issue. But now every
file in my project appears changed and I can no longer use a directory
listing to see what files I should update my colleagues with. I have to
zip up the whole damn thing.
It gets even worse if I'm using version control on a multiprogrammer
project. I've got to get everyone to check everything in (which means
they have to give me compilable code), then check everything out, do the
s&r, then check everything in. The automatic merging features I've seen
on PC platforms, at least, aren't very good at identifying changed
lines.
So while making massive s&r's on smaller, one-programmer projects is
viable, it doesn't scale up well.
Ell
Ma...@mWilden.com wrote:
:
If you wanted to note the count 3 gigs and expected that a variable would
hold such a count, you'd have a problem with a signed int.
Also if you were making a calculation that went negative and assigned it
to an unsigned int, you'd likely have a problem.
Elliott
--
"The domain object model is the foundation of OOD."
"We should seek out proven optimal practices and use them."
See SW Modeller vs SW Pragmatist Central: http://www.access.digex.net/~ell
Ell
Tom Keane (tke...@cts.com) wrote:
:
: Elliott wrote:
: >
: > Someone wrote:
: > : Also, WRT signed/unsigned, a count (of chickens, e.g.) is by its nature
: > : unsigned. I don't need to specify this in the variable name. I just
: > : need
: > : to indicate that the variable holds the number of chickens.
: > If you wanted to note the count 3 gigs and expected that a variable would
: > hold such a count, you'd have a problem with a signed int.
: >
: > Also if you were making a calculation that went negative and assigned it
: > to an unsigned int, you'd likely have a problem.
: ;-)
I'm really in deep kimshee now aren't I? ;-}
I like dealing with "practical" matters, but:
1) By understanding that there is an objective domain object model (DOM)
for whatever context, or level, is being considered, and
2) By expressing that DOM in OOD (with or without helper classes)
It's fairly easy to avoid being a pragamtist/empiricist.
Cheers,
Tom Keane
> :
> : Also, WRT signed/unsigned, a count (of chickens, e.g.) is by its nature
> : unsigned. I don't need to specify this in the variable name. I just
need
> : to indicate that the variable holds the number of chickens.
>
> If you wanted to note the count 3 gigs and expected that a variable would
> hold such a count, you'd have a problem with a signed int.
>
> Also if you were making a calculation that went negative and assigned it
> to an unsigned int, you'd likely have a problem.
>
> Elliott
> --
> "The domain object model is the foundation of OOD."
> "We should seek out proven optimal practices and use them."
> See SW Modeller vs SW Pragmatist Central:
http://www.access.digex.net/~ell
>
>
I don't know, Elliott, you're almost starting to sound a bit pragmatic....
;-)
Tom Keane
David Brower
ct...@probe.net (Jeff Miller) writes:
>e...@access1.digex.net (Ell) writes:
>>Robert C. Martin (rma...@oma.com) wrote:
>> On the other hand, that
>>: info is a rather large liability since if must be changed if the
>>: variable type ever gets changed. The impact of such a change is
>>: so high that often the variable name *will not* be changed even though
>>: the type is.
>>What's so hard about using a global search and replace?
>But what if your Hungarian notation is used in the naming of
>an element of a structure that is defined in a header file?
>You have absolutely no way of knowing who is using that file
>in their code. Accordingly, you have no way of knowing what
>code to examine with your global search and replace.
Which suggests you probably shouldn't be changing the type signature
of this public interface willy nilly, and ought to reconsider why
you were thinking about changing in the first place...
-dB
--
"It's hard to find a black cat in a dark room. | David Brower
Especially if the cat's not there. | dbr...@oracle.com
But we will!" | da...@acm.org
Tran Phan Anh
Ie. what if you have a newcolor member variable? m_NewColor?
mPreviousColor?
It is a function argument, so let's just append an 'a' as in aColor, and
everyone who is familiar with the convention can immediately recognize a
variable as a pass-in argument. If they are not familiar with the
convention, it will take 2 seconds to introduce them.
Note that 'a' is like 'a' in 'argument' not 'a' like 'a' in the article
'a'.
Another point, member variables and methods are 'intrinsic' to a class,
so why decorate them with fluffs such as 'm' ?
I once ported a 30Kloc C program (small example) from a 32-bit
architecture to a 64-bit power beast, and even though I still mumble
about the use of integer types to store pointer values and the mix of
ints and longs in the code by the original author, I am very glad he did
not use some dumb hungarian notation.
If you design your code properly, use block scoping appropriately, and
comment the code generously, there is never a real need to append
artificial artifacts to variable names. And this is especially true for
C++ and JAVA.
Anh
Ma...@mwilden.com
> > : Also, WRT signed/unsigned, a count (of chickens, e.g.) is by its nature
> > : unsigned. I don't need to specify this in the variable name. I just
> need
> > : to indicate that the variable holds the number of chickens.
> >
> > If you wanted to note the count 3 gigs and expected that a variable would
> > hold such a count, you'd have a problem with a signed int.
As I mentioned, I wouldn't use a signed int (or a float or a string) to
count chickens.
> > Also if you were making a calculation that went negative and assigned it
> > to an unsigned int, you'd likely have a problem.
If that calculation involved the number of chickens I own (assuming I'm
not worried about chickens that I owe to other people), I'd have more
problems than just the type of my variables! A negative chicken is not a
pretty sight. :)
(Dang, there's _another_ post I missed. Good thing people reply to
Elliott's stuff or I'd never see it. :(
Thaddeus L. Olczyk
Ell <e...@access1.digex.net> wrote in article
<5sgvjd$oc8$3...@news2.digex.net>...
> Robert C. Martin (rma...@oma.com) wrote:
> On the other hand, that
> : info is a rather large liability since if must be changed if the
> : variable type ever gets changed. The impact of such a change is
> : so high that often the variable name *will not* be changed even though
> : the type is.
>
> What's so hard about using a global search and replace?
1) The process must be monitored. Otherwise you run the risk of
changing SlipDate to SlirDate, when you change pDate to rDate.
2) Most methods for search and replace ( generally combinations of grep awk
and sed ) on multiple files don't give you much of a chance to monitor
the changes. On anything larger then a small program it can be such a
large job, that it is impossible.
3) I've yet to see anything on a windows platform which allows me to do a
global search and replace on many, many files.
It's obvious you haven't spent much time working on large projects.
--------------------------------------------
Thaddeus L. Olczyk
Dave Harris
a...@gte.net (Tran Phan Anh) wrote:
> Note that 'a' is like 'a' in 'argument' not 'a' like 'a' in the article
> 'a'.
> Another point, member variables and methods are 'intrinsic' to a class,
> so why decorate them with fluffs such as 'm' ?
I have used "myElement" and "anElement" for instance variables and
parameters respectively. This feels nice because I identify with the
object when I'm reading or writing code or comments. So I think of *my*
instance variables, which are mine and belong to me. Where as parameters
could have come from anywhere: an arbitrary element.
> If you design your code properly, use block scoping appropriately, and
> comment the code generously, there is never a real need to append
> artificial artifacts to variable names.
I don't agree about comments. Good variable names should reduce the need
for comments. Very often if you need a comment to explain what a variable
is doing, it's because the name is not vivid enough.
Dave Harris, Swansea, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
Tran Phan Anh
Jonas Andersson wrote:
> >It is a function argument, so let's just append an 'a' as in aColor, and
> >everyone who is familiar with the convention can immediately recognize a
> >variable as a pass-in argument. If they are not familiar with the
> >convention, it will take 2 seconds to introduce them.
>
> Since my functions/methods are max 20-lines(99%), there will not be a
> problem identifying the input parameters to each routine.
> >Note that 'a' is like 'a' in 'argument' not 'a' like 'a' in the article
> >'a'.
>
> This is counter to normal english, readability is lost in the case of
> aEngineer, people will stumble on this each time.
Right, and m_Que? , and mWhatever is normal English?
Bottom line, use whatever standard your employer wants unless you have
the opportunity to form the standard.
> >Another point, member variables and methods are 'intrinsic' to a class,
> >so why decorate them with fluffs such as 'm' ?
>
> Readability and convenience, when I look at another persons class
> I will have difficulty seeing which variables are memeber variables
> and which variables are not. I also use the a-prefix to inicate
Are you not contradicting yourself with the above paragraph?
> >If you design your code properly, use block scoping appropriately, and
> >comment the code generously, there is never a real need to append
> >artificial artifacts to variable names. And this is especially true for
> >C++ and JAVA.
>
> However if you use good names for variables and functions you hardly
> have to write any comments at all. The code is 90% self documenting.
That's definitely a new twist on excuses I've heard for not commenting
code.
Anyway, that's all for me as I do not wish to get too involved in a
"Ellipse is or is not a cirle and vice versa" type of topic :-).
Aaron D. Wieland
On Thu, 14 Aug 1997 07:14:14 GMT, jonas.a...@adiuvabo.se (Jonas
Andersson) wrote:
>I personally think that the aColor, or anObject, convention is a bad
>idea. The name as used in Smalltalk usually is a poor substitue for
>lack of tye definition. I prefer the use of a meaningful name and the
>m prefix as in:
>
>public void setColor(Color newColor) {mColor=newColor;}
>
>Just my point of view.
I tend to agree with you, though I frequently base the variable name
on the type simply because it is the best name (or close enough --
newColor is indeed more accurate than aColor, but the difference is
slight). So, I would name a parameter of type Employee "anEmployee",
but I would *not* name the parameter for the maximum list size
"anInteger" -- it would be named "maxListSize". Depending on the
context, there might be a better name than "anEmployee" (e.g.,
"bestPaidEmployee" or "lastEmployeeHired").
-- Aaron Wieland
Ell
Ma...@mWilden.com wrote:
:
: > Elliott wrote:
: > >
: > > Someone wrote:
: > > :
: > > : unsigned. I don't need to specify this in the variable name. I just
: > > : need
: > > : to indicate that the variable holds the number of chickens.
: > > If you wanted to note the count 3 gigs and expected that a variable would
: > > hold such a count, you'd have a problem with a signed int.
: As I mentioned, I wouldn't use a signed int (or a float or a string) to
: count chickens.
My point is that some one in whatever program might be more apt to make
the mistake of assigning an unsigned int value to a signed int variable
without something like Hungarian.
: > > Also if you were making a calculation that went negative and assigned it
: > > to an unsigned int, you'd likely have a problem.
: If that calculation involved the number of chickens I own (assuming I'm
: not worried about chickens that I owe to other people), I'd have more
: problems than just the type of my variables! A negative chicken is not a
: pretty sight. :)
In whatever program, counting whatever, someone might be more apt to
assign a negative value to an unsigned int, without something like
Hungarian.
Jonas Andersson
On Thu, 14 Aug 1997 09:30:56 -0700, Tran Phan Anh <a...@gte.net> wrote:
>Jonas Andersson wrote:
>>
>> On Wed, 13 Aug 1997 19:43:05 GMT, awie...@turing.scs.carleton.ca
>> (Aaron D. Wieland) wrote:
>>
>> >On Wed, 13 Aug 1997 09:44:03 -0400, Peter Eddy <pet...@bigfoot.com>
>> >wrote:
>> >>I'm really fond of the m_ notation for member variables myself. I
>> >>particularly like how the following code reads:
>> >>
>> >>public void setColor( Color color ) { m_color = color; }
>> >>
>> >>That is to say, you don't have to invent a name for the parameter that
>> >>is less descriptive than the member variable name and you don't have to
>> >>resort to the clumsy and probably error prone "this.color = color".
>> >>
>> >>My only reserveration is that the '_' is hard to type.
>> >
>> >Alternately, if you don't use the m_ notation, you can write the code
>> >as:
>> >
>> >public void setColor( Color aColor ) { color = aColor; }
>> >
>> >I.e., you avoid using a less descriptive name by prepending an article
>> >to the parameter. This convention is particularly common among
>> >Smalltalk programmers.
>> >
>> >-- Aaron Wieland
>> >
>> I personally think that the aColor, or anObject, convention is a bad
>> idea. The name as used in Smalltalk usually is a poor substitue for
>> lack of tye definition. I prefer the use of a meaningful name and the
>> m prefix as in:
>>
>> public void setColor(Color newColor) {mColor=newColor;}
>>
>> Just my point of view.
>
>Ie. what if you have a newcolor member variable? m_NewColor?
>mPreviousColor?
Of course naming is dependent on context, in these cases the above
example may have been a bad example. I didn't mean that you should
always use new, I meant that you should strive for meaningful names
insteand of appending the a/an prefix.
>
>It is a function argument, so let's just append an 'a' as in aColor, and
>everyone who is familiar with the convention can immediately recognize a
>variable as a pass-in argument. If they are not familiar with the
>convention, it will take 2 seconds to introduce them.
Since my functions/methods are max 20-lines(99%), there will not be a
problem identifying the input parameters to each routine.
>
>Note that 'a' is like 'a' in 'argument' not 'a' like 'a' in the article
>'a'.
This is counter to normal english, readability is lost in the case of
aEngineer, people will stumble on this each time.
And I also use a to denote associations.
>
>Another point, member variables and methods are 'intrinsic' to a class,
>so why decorate them with fluffs such as 'm' ?
Readability and convenience, when I look at another persons class
I will have difficulty seeing which variables are memeber variables
and which variables are not. I also use the a-prefix to inicate
associations, this may not have been the best choice of letter (see
the anEnginner argument). Associations are usually memebers of the
class but at another level than member variables.
Of course this is not strictly neccessary but I prefer this as a
courtey to the people who maintain the program.
Just as I like to give meaningful and long names to functions.
>
>I once ported a 30Kloc C program (small example) from a 32-bit
>architecture to a 64-bit power beast, and even though I still mumble
>about the use of integer types to store pointer values and the mix of
>ints and longs in the code by the original author, I am very glad he did
>not use some dumb hungarian notation.
I would agree. Type is bad for hungarian. Maybe stereotypes are good.
>
>If you design your code properly, use block scoping appropriately, and
>comment the code generously, there is never a real need to append
>artificial artifacts to variable names. And this is especially true for
>C++ and JAVA.
However if you use good names for variables and functions you hardly
have to write any comments at all. The code is 90% self documenting.
>
Ma...@mwilden.com
Jonas Andersson wrote:
> However if you use good names for variables and functions you hardly
> have to write any comments at all. The code is 90% self documenting.
I used to feel this way, too, and it gave me a good excuse for not
writing comments. But now I've gone the other way. I feel that every
section of code that's more than a couple of lines long should have a
brief comment explaining what it does. No matter how well the code is
written, sometimes a reader just wants to know what a section of code
does, not how it does it.
I think the best way to do this is to write a function first with all
pseudo-code. Flesh out the pseudo-code, turn each pseudo-code line into
a comment, and there you go.
I also like to put a paragraph or so of comments at the top of each
header, describing the classes it contains.
These are my commenting strategies. I sure wish everyone used them!
Ell
Thaddeus L. Olczyk (olc...@interaccess.com) wrote:
:
:
: Ell <e...@access1.digex.net> wrote in article
: <5sgvjd$oc8$3...@news2.digex.net>...
: > Robert C. Martin (rma...@oma.com) wrote:
: > On the other hand, that
: > : info is a rather large liability since if must be changed if the
: > : variable type ever gets changed. The impact of such a change is
: > : so high that often the variable name *will not* be changed even though
: > : the type is.
: >
: > What's so hard about using a global search and replace?
: 1) The process must be monitored. Otherwise you run the risk of
: changing SlipDate to SlirDate, when you change pDate to rDate.
Use a true programmer's editor that finds whole words.
: 2) Most methods for search and replace ( generally combinations of grep awk
: and sed ) on multiple files don't give you much of a chance to monitor
: the changes. On anything larger then a small program it can be such a
: large job, that it is impossible.
Don't use tools not up to the job.
: 3) I've yet to see anything on a windows platform which allows me to do a
: global search and replace on many, many files.
Use my VB editor, it will process all project files and is capable of
searching and replacing whole words.
: It's obvious you haven't spent much time working on large projects.
It's obvious who's doing what.
Enjoy,
Ma...@mwilden.com
John A. Grant wrote:
>
> I prefer 'this.color=color', because it is the most readable. What
> could be more simple?
How about something that could actually compile? :)
John A. Grant
Peter Eddy <pet...@bigfoot.com> wrote in article
<33F1BA23...@bigfoot.com>...
> Ralph Richard Cook wrote:
> > In your Java code how are people (or are they) distinguishing object
> > member variables from local variables, and both from function
> > parameters. In my own code so far I'm borrowing the "m_" notation from
> > MFC, but I'd like to use the Java standard, even if it's de facto.
> I'm really fond of the m_ notation for member variables myself. I
> particularly like how the following code reads:
>
> public void setColor( Color color ) { m_color = color; }
>
> That is to say, you don't have to invent a name for the parameter that
> is less descriptive than the member variable name and you don't have to
> resort to the clumsy and probably error prone "this.color = color".
>
> My only reserveration is that the '_' is hard to type.
I strongly dislike the clutter of 'm_' for class variables. Here are two
alternative solutions:
class someclass{
Color color; //simple, uncluttered variable name
public void setColor1(Color _color){
color=_color;
}
public void setColor2(Color color){
this.color=color;
}
}
In both cases, the code is very clear and easy to read and neither require
the creation of a new variable name. Well, ok, so '_color' is different from
'color', but it's slight and to me it's significantly less ugly than using
'm_color'
in all of the other code of the class.
I prefer 'this.color=color', because it is the most readable. What could be
more simple?
--
John A. Grant * I speak only for myself * jag...@znrcan.gc.ca (remove 'z')
Airborne Geophysics, Geological Survey of Canada, Ottawa
If you followup, please do NOT e-mail me a copy: I will read it here.
John A. Grant
John A. Grant <jag...@znrcan.gc.ca> wrote in article
<01bcaa9f$f2a590b0$83239c84@jag>...
scrambled - yes, I did see your reference to this.color=color. I
disagree that it's clumsy, but I forgot to ask why you thought it
was 'probably error prone'?
Ma...@mwilden.com
John A. Grant wrote:
>
> This is starting to sound like Monty Python's "The Argument"
No it's not!
> We all have our preferences but the best system is one that
> works for YOU, er ME, I mean YOU. Use your own system...
I don't think personal preferences are based on what sign of the zodiac
you were born under. We have logical reasons for what we do, and
discussing those reasons seems legitimate to me.
John A. Grant
Jonas Andersson <jonas.a...@adiuvabo.se> wrote in article
<33f2afcb...@138.221.200.100>...
> On Wed, 13 Aug 1997 19:43:05 GMT, awie...@turing.scs.carleton.ca
> (Aaron D. Wieland) wrote:
>
> >On Wed, 13 Aug 1997 09:44:03 -0400, Peter Eddy <pet...@bigfoot.com>
> >wrote:
> >>particularly like how the following code reads:
> >>
> >>public void setColor( Color color ) { m_color = color; }
> >>
> >>That is to say, you don't have to invent a name for the parameter that
> >>is less descriptive than the member variable name and you don't have to
> >>resort to the clumsy and probably error prone "this.color = color".
> >>
> >>My only reserveration is that the '_' is hard to type.
> >
> >as:
> >
> >public void setColor( Color aColor ) { color = aColor; }
> >
> >I.e., you avoid using a less descriptive name by prepending an article
> >to the parameter. This convention is particularly common among
> >Smalltalk programmers.
> >
> >-- Aaron Wieland
> >
> I personally think that the aColor, or anObject, convention is a bad
> idea. The name as used in Smalltalk usually is a poor substitue for
> lack of tye definition. I prefer the use of a meaningful name and the
> m prefix as in:
>
> public void setColor(Color newColor) {mColor=newColor;}
>
> Just my point of view.
"Look, this isn't an argument.
Yes it is.
No it's not.
Yes it is.
This is ridiculous.
No it's not...."
We all have our preferences but the best system is one that
works for YOU, er ME, I mean YOU. Use your own system...
Pierre G. Boutquin
> We all have our preferences but the best system is one that
> works for YOU, er ME, I mean YOU. Use your own system...
Fine for individuals, inappropriate for teams/departments, etc. who can
benefit from uniformity.
Dave Harris
jag...@znrcan.gc.ca (John A. Grant) wrote:
> We all have our preferences but the best system is one that
> works for YOU, er ME, I mean YOU. Use your own system...
There have been some studies that claim objective benefits for at least
some details. I don't have references, though. The two that spring to mind
are:
o Lower case is easier to read than upper case.
o Indents are best at 3, 4 or 5 spaces.
Other things being equal.
I have had to decide on a coding standard for my (small) team of
programmers, and I expect other people here will be in the same position
one day, so discussions like this can be useful. Admittedly, I've heard so
many similar ones over the last 13 years that it's now rare for someone to
bring up a new idea.
Jeffrey C. Dege
On Mon, 18 Aug 1997 07:23:00 GMT, Jonas Andersson <jonas.a...@adiuvabo.se> wrote:
>[Snip]
>>That's definitely a new twist on excuses I've heard for not commenting
>>code.
>
Say, rather, "comment where it _does_ add information".
--
From briefcase then there comes a list of things we must revise.
And all but four within the room are taken by surprise.
And all but four are thinking of their last job with remorse:
The customer, the manager, the doggy and the horse.
James Fryer
In article <33f7f74e....@138.221.200.100> Jonas Andersson
Because it's easier to read comments in English than it is to read code?
Because coments document your intentions when you were writing the code?
I used to think like you. Now I comment almost every line of code that I
write. When I come back to my code I can get working on it straight
away, without having to figure anything out. Other people can understand
my code too.
"Self-documenting" code is a myth.
Jim
--
James Fryer / j...@truleigh.demon.co.uk / j...@cix.co.uk
Jonas Andersson
[Snip]
>>
>> This is counter to normal english, readability is lost in the case of
>> aEngineer, people will stumble on this each time.
>
No, but they are not counter to english. I.e. reading a Enginner
disrupts the flow of reading, IMO.
>
>Bottom line, use whatever standard your employer wants unless you have
>the opportunity to form the standard.
Agreed.
>> I will have difficulty seeing which variables are memeber variables
>> and which variables are not. I also use the a-prefix to inicate
>Are you not contradicting yourself with the above paragraph?
Yea, and I said so 3 lines further down. I would like to find another
tag for associations but I cannot find a useful/meaningful letter to
indicate it. Any suggestions are appreciated.
>> However if you use good names for variables and functions you hardly
>> have to write any comments at all. The code is 90% self documenting.
>
>That's definitely a new twist on excuses I've heard for not commenting
>code.
If commenting does not add information, why comment?
Ma...@mwilden.com
Jeffrey C. Dege wrote:
>
> Say, rather, "comment where it _does_ add information".
I'm mistrustful of comments that add information. That indicates there
are dependencies and constraints not inherent in the code that's
commented. While necessary at times, this should be avoided.
A good comment does not have to add information. If I've got a page-long
algorithm, a comment at the top explaining what it does is better than
having to read the whole thing.
Jeff Miller
dbr...@us.oracle.com (David Brower) writes:
>ct...@probe.net (Jeff Miller) writes:
>>e...@access1.digex.net (Ell) writes:
>>>Robert C. Martin (rma...@oma.com) wrote:
>>> On the other hand, that
>>>: info is a rather large liability since if must be changed if the
>>>: variable type ever gets changed. The impact of such a change is
>>>: so high that often the variable name *will not* be changed even though
>>>: the type is.
>>>What's so hard about using a global search and replace?
>>But what if your Hungarian notation is used in the naming of
>>an element of a structure that is defined in a header file?
>>You have absolutely no way of knowing who is using that file
>>in their code. Accordingly, you have no way of knowing what
>>code to examine with your global search and replace.
>Which suggests you probably shouldn't be changing the type signature
>of this public interface willy nilly, and ought to reconsider why
>you were thinking about changing in the first place...
Which goes to my point that embedding type information in
variable names adds needless breadth to the interface.
Jeff Miller
Terrapin Technologies, Inc.
jmi...@cycletime.com
http://www.cycletime.com
Lee Slaughter
In article <01bca9aa$e5f1e120$287b7b7a@tlo2>,
Thaddeus L. Olczyk <olc...@interaccess.com> wrote:
>
>
>Ell <e...@access1.digex.net> wrote in article
><5sgvjd$oc8$3...@news2.digex.net>...
>> On the other hand, that
>> : info is a rather large liability since if must be changed if the
>> : variable type ever gets changed. The impact of such a change is
>> : so high that often the variable name *will not* be changed even though
>> : the type is.
>>
>> What's so hard about using a global search and replace?
>
> changing SlipDate to SlirDate, when you change pDate to rDate.
>
> and sed ) on multiple files don't give you much of a chance to monitor
> the changes. On anything larger then a small program it can be such a
> large job, that it is impossible.
cscope is quite handy for this.
>
>3) I've yet to see anything on a windows platform which allows me to do a
> global search and replace on many, many files.
>
>It's obvious you haven't spent much time working on large projects.
>--------------------------------------------
>Thaddeus L. Olczyk
Jonas Andersson
>>If commenting does not add information, why comment?
>
The difference migh be very very slight.
>
>Because coments document your intentions when you were writing the code?
But I think that I document my intentions in code instead.
>
>I used to think like you. Now I comment almost every line of code that I
>write. When I come back to my code I can get working on it straight
>away, without having to figure anything out. Other people can understand
>my code too.
I have never gotten a complain about my code either, so I guess that
people understand this too.
I also can get back to working with my own code very fast (however
this may not be a good measure of understandability).
>
>"Self-documenting" code is a myth.
Why on earth do people use pseudo-code when describing algorithms.
I used to comment a lot. Almost every line but now I prefer to select
good names and write policy methods. I find that policy methods
usually makes the code very readable and I think that many times
comments seem to be very redundant.
Usually I find that I write a new method instead of writing a comment.
>
>Jim
>--
>James Fryer / j...@truleigh.demon.co.uk / j...@cix.co.uk
Jonas
Frank G. Pitt
In article <memo.19970818...@btinternet.com>,
sc...@btinternet.com (Dave Harris) wrote:
>There have been some studies that claim objective benefits for at least
>some details. I don't have references, though. The two that spring to mind
>are:
>o Lower case is easier to read than upper case.
>o Indents are best at 3, 4 or 5 spaces.
I disagree, indents are better at 2 spaces. Leaves a lot more room
for that deeply nested series of switch statements
:-)
Frankie
Frank G. Pitt | When in doubt, wash | fun: fra...@mundens.gen.nz
Wellington | (Orlando) | fra...@ibm.net
New Zealand | | profit: fp...@nz1.ibm.com
Jay Martin
Frank G. Pitt wrote:
>
> In article <memo.19970818...@btinternet.com>,
> sc...@btinternet.com (Dave Harris) wrote:
>
> >There have been some studies that claim objective benefits for at least
> >some details. I don't have references, though. The two that spring to mind
> >are:
> >o Lower case is easier to read than upper case.
> >o Indents are best at 3, 4 or 5 spaces.
I had heard 2-4 columns myself.
>
> I disagree, indents are better at 2 spaces. Leaves a lot more room
> for that deeply nested series of switch statements
> :-)
But, I actually think this is a logical position. Unless you
nuke the 80 column line limit. You want to minimize spacing
to leave room for long lines. This makes 2 or 3 the logical choice (2
may be
too extreme for some people). I get the feeling that people who would
want 4 or more probably have alot of short identifiers and don't run
off the window. Unfortunately, I am afflicted with obscenely long
identifier disease myself.
So how many shops actual increase the 80 column line limit (thus
forcing everyone to have wide windows) and what do
they go to? As I remember my last job I think they basically
limited it to 80.
Jay
Dave Harris
jaymm...@earthlink.net (Jay Martin) wrote:
> > I disagree, indents are better at 2 spaces. Leaves a lot more room
> > for that deeply nested series of switch statements
> > :-)
>
> But, I actually think this is a logical position. Unless you
> nuke the 80 column line limit. You want to minimize spacing
> to leave room for long lines. This makes 2 or 3 the logical choice (2
> may be too extreme for some people). I get the feeling that people who
> would want 4 or more probably have alot of short identifiers and don't
> run off the window. Unfortunately, I am afflicted with obscenely long
> identifier disease myself.
A quick check of my code suggests that I rarely indent more than 5 levels,
or 20 spaces at 4 per level. This is in Java, so a couple of levels get
stuck in before you get to the actual code. For example:
class AAAA
method BBB
for CCC
if DDD
if EEEE
On the occasions I do go deeper than that, I sorta wish I hadn't. There
are usually other ways to write it, eg moving stuff into another routine
that would be smaller and simpler. Deeply nested code gets hard to read;
nesting can be over-used, as someone was telling me on
comp.lang.java.advocacy recently.
So, 20 spaces. If I used 3 spaces per level as you suggest, I'd save 5
characters. Identifier names are things like getFontMetrics or
ByteArrayInputStream, often 15 or 20 characters long. If I have 3 or 4 of
them on a line, I'm going to go over the 80 character limit whether or not
I save those 5 spaces.
Leo Bellew
In addition to what you noted:
1. Comments are not correct when written. If people cannot write
correct code without being surprised by their errors, why correct
comments?
(OTOH, one can always blame a comment processing error on the next
reader != the writer. :-)
2. Comments are not tested to the same degree as code. They cannot be
trusted.
3. Comments age faster than the code because there is no requirement
that they be updated when the code is.
4. Comments have no standardized, validated syntax and semantics. They
are extremely brittle in the face of change.
With all that said, I am always thankful for comments in, say, the MS
SDKs and Borland source. Particularly in terms of what the authors
though they were trying to do and at "What the heck?" points in the
code.
Leo
On Tue, 19 Aug 1997 06:37:40 GMT, jonas.a...@adiuvabo.se (Jonas
Andersson) wrote:
snip
F.Baube
The problem with underbars is that they disappear
on most dot matrix printers ! And may not do too
well when your laser tober is low, either.
Just MHO
fr...@kirjasto.kaarina.fi.screw.spam
In comp.lang.java.programmer John A. Grant <jag...@znrcan.gc.ca> wrote:
> public void setColor1(Color _color){
> color=_color;
> }
> In both cases, the code is very clear and easy to read and neither require