Roedy style observation ;-/
VisionSet
ouch!
took me about 2 mins to solve but could have been soooooo much longer!
could be a good reason to do
void setIsCalcRows(boolean boo) {isCalcRows = boo;}
shame, I liked the 'this' way, seems more descriptive of intent.
--
Mike W
Thomas G. Marshall
The /boo/ formalism you speak of need not be so strict.
What of this:
void setIsCalcRows(boolean _isCalcRows)
{
isCalcRows = _isCalcRows;
...
}
Or this /convention/ :
void setIsCalcRows(boolean _isCalcRows)
{
this.isCalcRows = _isCalcRows;
...
}
...to drive the point home. Could be good for you. I am used to what you
were originally talking about, but hate things like the following:
void setIsCalcRows(boolean isCalcRows)
{
this.isCalcRows = isCalcRows;
isCalcRows++;
}
Roedy Green
<tgm2tothe...@hotmail.replaceTextWithNumber.com> wrote or quoted
:
> void setIsCalcRows(boolean _isCalcRows)
> {
> isCalcRows = _isCalcRows;
> ...
> }
or the reverse convention. No need to confuse the clients.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Chris Uppal
> void setIsCalcRows(boolean iscalcRows) {this.isCalcRows = isCalcRows;}
>
> ouch!
For years I have used (and, in one life, even imposed) the convention
"borrowed" from C++ of naming all member variables with an "m_" prefix and
static variables (except capitalised constants) with an "s_" prefix.
It's the only variable naming convention I use ("hungarian" makes my teeth
ache), but I find it worth-while.
I'd rather just use "this." or "<Classname>." to signal these things, but since
the compiler doesn't enforce those conventions, they aren't as *reliably"
informative as I'd wish.
-- chris
Peter Kirk
"VisionSet" <sp...@ntlworld.com> wrote in message
news:eKmbb.1192$jJ3....@newsfep4-glfd.server.ntli.net...
> void setIsCalcRows(boolean iscalcRows) {this.isCalcRows = isCalcRows;}
This is another reason I like using an IDE like Eclipse. It highlights such
things, to suggest you may want to look more closely at that line of code as
it has no reasonable effect.
Peter
Andrew S.
This mucks up the class definition and makes bean notation awkward.
private String m_LastName;
String getM_LastName() { ... }
void setM_LastName(String lastName) { ... }
Instead I use a prefix for all incoming parameters and an m prefix for
all local objects within a method.
private String lastName;
String getLastName() { ... }
void setLastName(String pLastName)
{
this.lastName = pLastName
String mLastName = "junk";
}
Using this dot along with some kind of convetion at the method level
leaves a clean class definition and obvious scope and obnject origin
within a method.
For everybody's benefit, these type of things should be enforced.
Besides, code reviews are so much fun!
Andrew
Thomas G. Marshall
Which is, IMO, another argument for getting away from ASCII as the root
formalism for code. Static's should never be compiled as such unless they
were perhaps in bold or italicied, for example.
This doesn't mean using a fancy IDE syntax coloring however. Nor does it
require going so far as to use a database driven non-source ide.
I'd argue that all source should be in a formalism above ascii. Like html,
or display postscript.
Roedy Green
wrote or quoted :
>private String m_LastName;
>String getM_LastName() { ... }
I think you would hide the warts in the names, e.g.
getLastName();
Drew Volpe
> void setIsCalcRows(boolean iscalcRows) {this.isCalcRows = isCalcRows;}
>
> ouch!
a good IDE will warn you about this (IDEA calls it "silly assignment").
dv
--
--------------------------------------------------------------------------
The geographical center of Boston is in Roxbury. Due north of the
center we find the South End. This is not to be confused with South
Boston which lies directly east from the South End. North of the South
End is East Boston and southwest of East Boston is the North End.
Drew Volpe, mylastname at hcs o harvard o edu
Thomas G. Marshall
"Drew Volpe" <vo...@hcs.harvard.edu> wrote in message
news:slrnbmutv...@hcs.harvard.edu...
> Last time we met, VisionSet <sp...@ntlworld.com> had said:
> > void setIsCalcRows(boolean iscalcRows) {this.isCalcRows = isCalcRows;}
> >
> > ouch!
>
> a good IDE will warn you about this (IDEA calls it "silly assignment").
I may have mised what you mean: warn about which part? That the isCalcRows
doesn't match the iscalcRows (lower-c), or that
this.x = x
was even attempted?
I would have thought that they'd use the term "silly assignment" for
somthing more like
x = this.x
...which is squashing the formal parameter.
Peter Kirk
wrote in message news:Y8Obb.13886$Uv2....@nwrdny02.gnilink.net...
>
> "Drew Volpe" <vo...@hcs.harvard.edu> wrote in message
> news:slrnbmutv...@hcs.harvard.edu...
> > Last time we met, VisionSet <sp...@ntlworld.com> had said:
> > > void setIsCalcRows(boolean iscalcRows) {this.isCalcRows =
isCalcRows;}
> > >
> > > ouch!
> >
> > a good IDE will warn you about this (IDEA calls it "silly assignment").
>
> I may have mised what you mean: warn about which part? That the
isCalcRows
> doesn't match the iscalcRows (lower-c),
It is warning that you are assigning the instance variable isCalcRows to
itself. This has no effect as far as I am aware (is there some esoteric
thread/cpu-synchronisation issue that may involve this?)
The parameter iscalcRows is not actually used in the method. The IDE may
even warn about an unused parameter as well.
Peter
Chris Uppal
> This mucks up the class definition and makes bean notation awkward.
> private String m_LastName;
> String getM_LastName() { ... }
> void setM_LastName(String lastName) { ... }
Not the way I do it. I belong in the "accessor methods are evil" camp, so --
as far as I am concerned -- the relationship between a method name (or the name
of a getter/setter pair -- which is not the same as accessors) and the name of
any instance variable, is a matter of coincidence rather than convention.
So, in this case, I'd have methods:
getLastName() { return m_lastName; }
setLastName(String lastName) { m_lastName = lastName; }
OTOH I'd be just as happy with
getLastName() { return m_names[m_names.length-1]; }
setLastName(String lastName) { m_names[m_names.length-1] = lastName; }
Still, for those who do subscribe to the concept of "accessors", I see no
reason why the convention shouldn't allow one to drop the "m_" or "s_".
> Instead I use a prefix for all incoming parameters and an m prefix for
> all local objects within a method.
I don't like that at all, and I don't like reading code that does that. The
prefixes are mucking up the readability of the most used variables. Of
course, my "m_" prefix similarly mucks up the readability of the instance
variables, but since they are less "local" I think it's a worthwhile bargain.
BTW. the "_" in the prefix makes a big difference to my eyes --- I wouldn't
even *consider* using a prefix that wasn't set off in some way from the name
that it prefixed.
> For everybody's benefit, these type of things should be enforced.
> Besides, code reviews are so much fun!
Better than a paintball session for building team spirit...
-- chris
Chris Uppal
> > I'd rather just use "this." or "<Classname>." to signal these things,
> > but since the compiler doesn't enforce those conventions, they aren't
> > as *reliably" informative as I'd wish.
>
> Which is, IMO, another argument for getting away from ASCII as the root
> formalism for code. Static's should never be compiled as such unless they
> were perhaps in bold or italicied, for example.
>
> This doesn't mean using a fancy IDE syntax coloring however. Nor does it
> require going so far as to use a database driven non-source ide.
>
> I'd argue that all source should be in a formalism above ascii. Like
> html, or display postscript.
There is much in what you say. (Though the XML weenies would probably jump on
it as another opportunity for XML-abuse...)
My main reservation is that it would be putting still more emphasis on the
*code* rather than on the *behaviour of the objects*, and that is a tendency
that I'd rather reverse than encourage.
IMO, Java IDEs (with the probable exception of BlueJ), and, in fact, the design
of Java itself*, foster a code-centric rather than object-centric way of
thinking. That seems to lead some programmers to come up with very non-OO
designs; whereas, if they'd thinking objects rather than code, they would
likely have found much better designs. (The purpose of OO being to achieve
good design, of course, not the other way around ;-).
(E.g: the recent thread about returning multiple objects from one method.)
-- chris
[*] and it's going to get worse....
Tim Tyler
: For years I have used (and, in one life, even imposed) the convention
: "borrowed" from C++ of naming all member variables with an "m_" prefix and
: static variables (except capitalised constants) with an "s_" prefix.
: It's the only variable naming convention I use ("hungarian" makes my teeth
: ache), but I find it worth-while.
: I'd rather just use "this." or "<Classname>." to signal these things,
: but since the compiler doesn't enforce those conventions, they aren't
: as *reliably" informative as I'd wish.
The solution to that is (or will be) to use a lint tool that /does/
enforce the practice.
Using "this." seems to have few drawbacks (besides verbosity) -
and several benefits.
However, using the name of the class to refer to static objects
within the class from itself isn't so neat.
It (typically) results in even more verbosity than using "this" - and
wires the name of the class in at multiple locations.
OK - refactoring tools mean that they can all be changed at once -
but it is still a bit inelegant.
--
__________
|im |yler http://timtyler.org/ t...@tt1.org
xarax
Just don't use method parameters that match field names. Use
an obvious prefix on the method parameter. I use "the":
void setIsCalcRows(final boolean theIsCalcRows) {isCalcRows = theIsCalcRows;}
Very easy to distinguish, and I never use "this." at all. I also
specify every method parameter as "final", so I can catch attempts
to modify the parm (when my intent is to modify the field).
Problem solved.
VisionSet
news:306d5c8f.03092...@posting.google.com...
Yes easy to solve, just struck me, and you always see example code written
like this.
--
Mike W
Thomas G. Marshall
> On Mon, 22 Sep 2003 02:12:03 GMT, "Thomas G. Marshall"
> <tgm2tothe...@hotmail.replaceTextWithNumber.com> wrote or quoted
>>
>
>> void setIsCalcRows(boolean _isCalcRows)
>> {
>> isCalcRows = _isCalcRows;
>> ...
>> }
>
> or the reverse convention. No need to confuse the clients.
No, I find the reverse convention far more confusing. The "_" mutates the
parameter into something temporary.
Thomas G. Marshall
> Thomas G. Marshall wrote:
...[gash]...
Oh sure, but that opinion is in no way orthogonal to mine.
My desires for a better low level formalism for the code need not remove any
implementation of non-code driven ide's.
That, and remember that html, or DPS would work well with /all/ code
constructs: perl, C, fortran, java, etc.
Thomas G. Marshall
> "xarax" <xa...@email.com> wrote in message
Sure, but isn't it clearer with a non-alphanumeric?
isCalcRows = _isCalcRows; // oooooo
vs.
isCalcRows = theisCalcRows; // bleahhhhhh
:)
Jezuch
> It is warning that you are assigning the instance variable isCalcRows to
> itself. This has no effect as far as I am aware (is there some esoteric
> thread/cpu-synchronisation issue that may involve this?)
Fortunately in Java this code really (AFAIK) does nothing. In Micro$oft's
laguages however such "silly assignment" is very meaningful with
"properties". I don't write much JavaScript code so I don't know if this is
a standard (it works in IE), but quite common code to reload a page is:
document.location.href=document.location.href;
;)
--
Ecce Jezuch
"In a dream I cannot see; tangled abstract fallacy
Random turmoil builds in me; I'm addicted to chaos" - D. Mustaine
Thomas G. Marshall
...[gash]...
Am I the only one that see's this encoding as grossly oversized text? Even
this reply is sucked into it.
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Yuck.
Tim Tyler
: Just don't use method parameters that match field names. Use
: an obvious prefix on the method parameter. I use "the":
: void setIsCalcRows(final boolean theIsCalcRows) {isCalcRows = theIsCalcRows;}
: Very easy to distinguish, and I never use "this." at all. I also
: specify every method parameter as "final", so I can catch attempts
: to modify the parm (when my intent is to modify the field).
: Problem solved.
A problem with this solution is that you wind up with "the"s all
over the place in your method parameters - and those are typically
exposed in your public interface.
Because of this I think the prefix should go on the field.
I think the correct prefix is "this." - and that using it
should be enforced by lint tools.
Drew Volpe
> "Thomas G. Marshall" <tgm2tothe...@hotmail.replaceTextWithNumber.com>
> wrote in message news:Y8Obb.13886$Uv2....@nwrdny02.gnilink.net...
> >
> > "Drew Volpe" <vo...@hcs.harvard.edu> wrote in message
> > news:slrnbmutv...@hcs.harvard.edu...
> > > Last time we met, VisionSet <sp...@ntlworld.com> had said:
> > > > void setIsCalcRows(boolean iscalcRows) {this.isCalcRows =
> isCalcRows;}
> > > >
> > > > ouch!
> > >
> > > a good IDE will warn you about this (IDEA calls it "silly assignment").
> >
> > I may have mised what you mean: warn about which part? That the
> isCalcRows
> > doesn't match the iscalcRows (lower-c),
>
> It is warning that you are assigning the instance variable isCalcRows to
> itself. This has no effect as far as I am aware (is there some esoteric
> thread/cpu-synchronisation issue that may involve this?)
yeh, this. That line doesn't do anything, so the IDE (at least IDEA)
will mark it with a warning.
Michael Borgwardt
> ...[gash]...
>
>
> Am I the only one that see's this encoding as grossly oversized text? Even
> this reply is sucked into it.
Nothing like that here. Reconfigure Outlook to use a more sensibe font size or
(preferably) switch to a newsreader that isn't a complete POS.
Mark Meyer
> void setIsCalcRows(boolean iscalcRows) {
> this.isCalcRows = isCalcRows;
> }
"Drew Volpe" <vo...@hcs.harvard.edu> wrote in message
news:slrnbmutv...@hcs.harvard.edu...
>> > a good IDE will warn you about this (IDEA calls it "silly assignment").
"Thomas G. Marshall"
<tgm2tothe...@hotmail.replaceTextWithNumber.com>
wrote in message news:Y8Obb.13886$Uv2....@nwrdny02.gnilink.net...
>> I may have mised what you mean: warn about which part? That the
>isCalcRows
>> doesn't match the iscalcRows (lower-c),
On Tue, 23 Sep 2003 09:50:32 +0200, "Peter Kirk"
<peter...@alpha-gruppen.dk> wrote:
>It is warning that you are assigning the instance variable isCalcRows to
>itself. This has no effect as far as I am aware (is there some esoteric
>thread/cpu-synchronisation issue that may involve this?)
>
>The parameter iscalcRows is not actually used in the method. The IDE may
>even warn about an unused parameter as well.
So the answer to Thomas' question is: yes, because the case in the
parameter name was erroneous, forcing the compiler to treat
this.isCalcRows and isCalcRows as the same entity, the instance
variable. If the parameter name were isCalcRows, the method would
work just fine.
Mark Meyer mme...@raytheon.com
Raytheon Voice (972)344-0830 Fax (972)344-6840
Thomas G. Marshall
> "Thomas G. Marshall"
> <tgm2tothe...@hotmail.replaceTextWithNumber.com> wrote:
>
>> No, I find the reverse convention far more confusing. The "_"
>> mutates the parameter into something temporary.
>
> But when you do the reverse of the commonly accepted idiom, you are
> obfuscating your intent.
That's only if you declare that the commonly accepted idiomatic rule is to
have a prefix.
The commonly accepted idiom DOES happen to have a prefix:
this.(something)
But that's not the idiom itself. The current idiom itself is to have name
scope make the differentiation. (the non-this vs. this). (The local
parameter vs. the member variable).
The idiom I'm proposing is the same: have name scope make the
differentiation. When a variable has a _, then it's local.
IN BOTH CASES, the member variable stays /without/ the prefix for the rest
of the class, using my method. Going the other way puts a prefix on the
member variable, which is gross.
Peter Kirk
"Mark Meyer" <mme...@raytheon.com> wrote in message
news:dr49nvkfpd49sleuo...@4ax.com...
> "Thomas G. Marshall"
> <tgm2tothe...@hotmail.replaceTextWithNumber.com>
> wrote in message news:Y8Obb.13886$Uv2....@nwrdny02.gnilink.net...
> >> I may have mised what you mean: warn about which part? That the
> >isCalcRows
> >> doesn't match the iscalcRows (lower-c),
>
> On Tue, 23 Sep 2003 09:50:32 +0200, "Peter Kirk"
> <peter...@alpha-gruppen.dk> wrote:
> >It is warning that you are assigning the instance variable isCalcRows to
> >itself. This has no effect as far as I am aware (is there some esoteric
> >thread/cpu-synchronisation issue that may involve this?)
> >
> >The parameter iscalcRows is not actually used in the method. The IDE may
> >even warn about an unused parameter as well.
>
> So the answer to Thomas' question is: yes, because the case in the
> parameter name was erroneous, forcing the compiler to treat
> this.isCalcRows and isCalcRows as the same entity, the instance
> variable. If the parameter name were isCalcRows, the method would
> work just fine.
No. The warning is not saying that the parameter name and the instance
variable name are different. It is saying that the line of code has no
effect - assigning a variable to itself.
If the warning were saying that the parameter name and the instance variable
name were not the same, then one would in general receive a lot of warnings
when compiling code: quite often there are instance variables, and quite
often there are parameters, and quite often the parameter names are
different form instance variable names.
Peter
Thomas G. Marshall
> In our last episode, VisionSet <sp...@ntlworld.com> had said:
>> void setIsCalcRows(boolean iscalcRows) {
>> this.isCalcRows = isCalcRows;
>> }
>
> "Drew Volpe" <vo...@hcs.harvard.edu> wrote in message
> news:slrnbmutv...@hcs.harvard.edu...
>>>> a good IDE will warn you about this (IDEA calls it "silly
>>>> assignment").
>
> "Thomas G. Marshall"
> <tgm2tothe...@hotmail.replaceTextWithNumber.com>
> wrote in message news:Y8Obb.13886$Uv2....@nwrdny02.gnilink.net...
>>> I may have mised what you mean: warn about which part? That the
>>> isCalcRows doesn't match the iscalcRows (lower-c),
>
> On Tue, 23 Sep 2003 09:50:32 +0200, "Peter Kirk"
> <peter...@alpha-gruppen.dk> wrote:
>> It is warning that you are assigning the instance variable
>> isCalcRows to itself. This has no effect as far as I am aware (is
>> there some esoteric thread/cpu-synchronisation issue that may
>> involve this?)
>>
>> The parameter iscalcRows is not actually used in the method. The IDE
>> may even warn about an unused parameter as well.
>
>
> So the answer to Thomas' question is:
I was not questioning what was happening; I was questioning which way his
explanation was going. I was worried that he was making the wrong point.
...[snip]...
Mark Meyer
<peter_kirk@PLEASE_DONT_SPAM_ME_ANYMORE_alpha-gruppen.NO_MORE_dk_ARGGGGH>
wrote:
>No. The warning is not saying that the parameter name and the instance
>variable name are different. It is saying that the line of code has no
Yes, the warning merely says the assignment is useless. The warning
is the _effect_. I felt it useful to clarify the _cause_, which is
what I thought Thomas was getting at.
Thomas G. Marshall
> In our last episode, "Peter Kirk"
> <peter_kirk@PLEASE_DONT_SPAM_ME_ANYMORE_alpha-gruppen.NO_MORE_dk_ARGGGGH>
> wrote:
>> No. The warning is not saying that the parameter name and the
>> instance variable name are different. It is saying that the line of
>> code has no effect - assigning a variable to itself. ...
>
> Yes, the warning merely says the assignment is useless. The warning
> is the _effect_. I felt it useful to clarify the _cause_, which is
> what I thought Thomas was getting at.
It was my fault---I carelessly said
Did you mean A or B?
without regard to the fact that it /looked/ like I was saying:
Which is it? A or B?
Which I was not. And that spawned this mini thread.