Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #11201 > unrolled thread

Curious compiler warning

Back to article view | Back to comp.lang.java.programmer

Contents

  Curious compiler warning Novice <novice@example..com> - 2012-01-11 01:51 +0000
    Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-10 18:10 -0800
      Re: Curious compiler warning glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-11 02:36 +0000
        Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-10 19:03 -0800
          Re: Curious compiler warning glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-11 07:50 +0000
            Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-10 23:57 -0800
          Re: Curious compiler warning Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-11 05:47 -0400
            Re: Curious compiler warning glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-11 13:25 +0000
              Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-11 06:58 -0800
                Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-11 07:01 -0800
                Re: Curious compiler warning Patricia Shanahan <pats@acm.org> - 2012-01-11 10:03 -0800
                  Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-11 23:30 -0800
                Re: Curious compiler warning Gene Wirchenko <genew@ocis.net> - 2012-01-11 18:10 -0800
                  Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-11 23:32 -0800
                    Re: Curious compiler warning Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-01-12 01:44 -0600
                      Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-12 07:42 -0800
                        Re: Curious compiler warning Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-01-12 10:51 -0600
                      Re: Curious compiler warning Patricia Shanahan <pats@acm.org> - 2012-01-12 07:50 -0800
                        Re: Curious compiler warning Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-01-12 10:54 -0600
                        Re: Curious compiler warning Wanja Gayk <brixomatic@yahoo.com> - 2012-01-21 12:52 +0100
                    Re: Curious compiler warning Gene Wirchenko <genew@ocis.net> - 2012-01-12 11:51 -0800
                      Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-12 20:58 -0800
          Re: Curious compiler warning "Gavino" <invalid@invalid.invalid> - 2012-01-11 20:05 +0100
            Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-12 07:47 -0800
          Re: Curious compiler warning Wanja Gayk <brixomatic@yahoo.com> - 2012-01-21 12:52 +0100
            Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-21 12:13 -0800
      Re: Curious compiler warning Novice <novice@example..com> - 2012-01-11 04:55 +0000
        Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-10 21:46 -0800
        Re: Curious compiler warning glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-11 07:55 +0000
        Re: Curious compiler warning Roedy Green <see_website@mindprod.com.invalid> - 2012-01-11 01:35 -0800
          Re: Curious compiler warning "Gavino" <invalid@invalid.invalid> - 2012-01-11 20:05 +0100
            Re: Curious compiler warning Gene Wirchenko <genew@ocis.net> - 2012-01-11 18:18 -0800
              Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-12 07:55 -0800
                Re: Curious compiler warning Gene Wirchenko <genew@ocis.net> - 2012-01-12 11:59 -0800
              Re: Curious compiler warning Martin Gregorie <martin@address-in-sig.invalid> - 2012-01-13 00:02 +0000
                Re: Curious compiler warning Patricia Shanahan <pats@acm.org> - 2012-01-12 16:11 -0800
                  Re: Curious compiler warning Martin Gregorie <martin@address-in-sig.invalid> - 2012-01-13 01:31 +0000
            Re: Curious compiler warning Roedy Green <see_website@mindprod.com.invalid> - 2012-01-11 18:26 -0800
              Re: Curious compiler warning Patricia Shanahan <pats@acm.org> - 2012-01-11 19:01 -0800
                Re: Curious compiler warning Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-11 23:23 -0500
                  Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-12 08:00 -0800
              Re: Curious compiler warning Wanja Gayk <brixomatic@yahoo.com> - 2012-01-21 12:52 +0100
            Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-12 07:50 -0800
          Re: Curious compiler warning Gene Wirchenko <genew@ocis.net> - 2012-01-11 18:14 -0800
            Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-12 08:05 -0800
              Re: Curious compiler warning Gene Wirchenko <genew@ocis.net> - 2012-01-12 12:02 -0800
    Re: Curious compiler warning Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-10 21:11 -0500
      Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-10 18:17 -0800
      Re: Curious compiler warning bugbear <bugbear@trim_papermule.co.uk_trim> - 2012-01-11 16:10 +0000
      Re: Curious compiler warning Lars Enderin <lars.enderin@telia.com> - 2012-01-11 20:45 +0100
        Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-12 08:09 -0800
        Re: Curious compiler warning Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2012-01-12 18:14 +0200
        Re: Curious compiler warning Wanja Gayk <brixomatic@yahoo.com> - 2012-01-21 12:52 +0100
        Re: Curious compiler warning David Lamb <dalamb@cs.queensu.ca> - 2012-01-21 09:12 -0500
      Re: Curious compiler warning Gene Wirchenko <genew@ocis.net> - 2012-01-11 18:21 -0800
      Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-12 08:08 -0800
    Re: Eclipse 3.7.1 compiler warning v_borchert@despammed.com (Volker Borchert) - 2012-01-11 21:10 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#11286

On Wed, 11 Jan 2012 23:32:28 -0800, Lew <noone@lewscanon.com> wrote:

>On 01/11/2012 06:10 PM, Gene Wirchenko wrote:
>> On Wed, 11 Jan 2012 06:58:10 -0800, Lew<noone@lewscanon.com>  wrote:
>>
>> [snip]
>>
>>> If you have a hard time understanding that expression and you call yourself a
>>> Java programmer, there's a disconnect.
>>
>>       If I can not see what the expression means almost instantly, then
>> it is a candidate for simplification.
>>
>>       I am not a fan of macho programming.
>>
>>       Sometimes, we are tired.  Sometimes, we are in a hurry.
>> Sometimes, we are not so familiar with the code.  Why ask for trouble?
>> Do it obviously except when an exception to this is clearly warranted.
>
>While I agreed with Patricia's point, your points are sheer hyperbole.  We're 
>talking about autoincrement and autodecrement, for Pete's sake!
>
>Next you'll excoriate += as obscure.  Sheesh.

     No, not hyperbole.  Such a statement does two things.  In a quick
or hurried look through code, it might get missed.  I prefer that
statements do one thing.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#11294

Gene Wirchenko wrote:
>       No, not hyperbole.  Such a statement does two things.  In a quick
> or hurried look through code, it might get missed.  I prefer that
> statements do one thing.

The idea is good, that code should be clear. I should support your view 
because it is motivated by the greater good and works more effectively in the 
real world. I certainly would never support a code standard to prefer 
conversion to the abbreviated form, nor fault the long form in a code review. 
Your logic is compelling and conclusive. I reserve not to comment against the 
short forms in a code review because a professional programmer should not be 
so careless as to miss an op= or autoXcrement op. So I support the populist 
view that reduces risk for overworked and frazzled workaday programmers and 
cuts them some slack and the professional view that assumes fluency in the 
basic idioms.

Thank you for a well-expressed and informative series of posts.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#11235

"Lew" <noone@lewscanon.com> wrote in message
news:jeiu63$es3$1@news.albasani.net...
> I also found an explanation in the Eclipse help of all places for the
> warning:
> "Parameter assignment
> "Assigning a value to a parameter is generally considered poor style
> programming. When this option is enabled, the compiler will signal such
> scenario either as an error or a warning."
>
> Notice that they point out that it's considered poor style.  The
> engineering reason behind this is that parameter assignment goes away at
> the end of the method block.

But that would also apply to any local variables, and it's clearly not
considered poor style to assign to those.

The real engineering reason is surely just that method code is generally
easier to understand and maintain if the parameters are used as constants,
and not changed in the method body.

[toc] | [prev] | [next] | [standalone]

#11266

Gavino wrote:
> Lew wrote ...
>> I also found an explanation in the Eclipse help of all places for the
>> warning:
>> "Parameter assignment
>> "Assigning a value to a parameter is generally considered poor style
>> programming. When this option is enabled, the compiler will signal such
>> scenario either as an error or a warning."
>>
>> Notice that they point out that it's considered poor style.  The
>> engineering reason behind this is that parameter assignment goes away at
>> the end of the method block.
>
> But that would also apply to any local variables, and it's clearly not
> considered poor style to assign to those.

Except that in the method block, the caller still has the arguments, whereas 
in a local block the variable is not referenceable.  That's the difference, 
and the reason why the pundits recommend against parameter assignment.  It's 
too easy for programmers (presumably the same ones who have a problem with ++ 
and +=) might think they're in a pass-by-reference world and wonder what 
happened to their "assignment" to the argument.  That's not a risk with local 
variables.

People asked for an explanation of the principle.  This is an explanation.  If 
you want to say the rule shouldn't exist, you will get no argument from me, 
but if you want to say the reason is bad you'll have to complain to those who 
made the rule.

> The real engineering reason is surely just that method code is generally
> easier to understand and maintain if the parameters are used as constants,
> and not changed in the method body.

That's not an engineering reason, that's a conclusion.  For one thing, your 
explanation doesn't even begin to counter your own objection.  You must go deeper.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#11560

In article <jeiu63$es3$1@news.albasani.net>, noone@lewscanon.com says...

> >> What's exactly wrong is that the assignment to the parameters
> >> is thrown away, and does you no good.
> >
> > Well, not thrown away until after the call to bar.
> 
> Irrelevant.  There's absolutely no value to storing the result because it 
> isn't reused.

One could go a step further and ask if the compiler would not optimize 
that, and then one could ague if it's bad style (what I think)...
...but that's probably not what's hepling the original poster regarding 
his problem (I don't know if that's just a stripped down version of the 
original code and whether the decrements are embedded in some sort of 
loop or so). 
So, maybe it's not worth discussing tha, because the original poster had 
asked for a compiler warning and not if his algorithm was stupid. :-)

My best guess is that the warning to "not assign the parameters" is 
style-check warning, that just gives a hint on the best practice not to 
assign values to the parameters of a method.

So maybe he's rather asking for some change like:

void foo(int x, int y){
 x++;
 ...
}

to 

void foo(int x, int y){
 int start = x+1;
 ...
}

as solution to his warning.

Checkstyle says:

"FinalParameters
Description

 Check that method/constructor/catch block parameters are final. 
Interface and abstract methods are not checked - the final keyword does 
not make sense for interface and abstract method parameters as there is 
no code that could modify the parameter. 

 Rationale: Changing the value of parameters during the execution of the 
method's algorithm can be confusing and should be avoided. A great way 
to let the Java compiler prevent this coding style is to declare 
parameters final."

While Java rockstar Adam Bien says:
> http://www.adam-
bien.com/roller/abien/entry/final_method_parameters_should_generate <

(Which I disagree on and I have made my point in the answers, which you 
might like or not).

Kind regards,
Wanja


-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#11568

Wanja Gayk wrote:
> My best guess is that the warning to "not assign the parameters" is
> style-check warning, that just gives a hint on the best practice not to
> assign values to the parameters of a method.

That is correct.
>
> So maybe he's rather asking for some change like:
>
> void foo(int x, int y){
>   x++;
>   ...
> }
>
> to
>
> void foo(int x, int y){
>   int start = x+1;
>   ...
> }
>
> as solution to his warning.

That's a workaround, but as many in this thread have pointed out, there's 
really nothing wrong with assigning to a parameter variable save that it 
breaks the documentary connection to its parameter-ness. The Checkstyle 
rationale cited /infra/ uses the same weasel-wording one typically encounters: 
passive voice conditional "can be confusing", ducking the questions of to whom 
and under what circumstances.

In the OP's case we've already discussed the option to disable this warning in 
the Eclipse settings.

> Checkstyle says:
>
> "FinalParameters
> Description
>
>   Check that method/constructor/catch block parameters are final.
> Interface and abstract methods are not checked - the final keyword does
> not make sense for interface and abstract method parameters as there is
> no code that could modify the parameter.
>
>   Rationale: Changing the value of parameters during the execution of the
> method's algorithm can be confusing and should be avoided. A great way
> to let the Java compiler prevent this coding style is to declare
> parameters final."
>
> While Java rockstar Adam Bien says:
>> http://www.adam-bien.com/roller/abien/entry/final_method_parameters_should_generate
>
> (Which I disagree on and I have made my point in the answers, which you
> might like or not).

He also makes some factual errors. His example purporting to require the 
'final' keyword would have worked if the anonymous class referred to the outer 
class member instead of the method parameter.

I see no harm in declaring a method parameter 'final', but I'm generally a fan 
of verbosity in Java programming anyway. People who don't like it call it 
"noise", but universally without justifying the epithet in engineering terms. 
Is it "noise" if it enforces non-assignment, which the very critics of 'final' 
seem to find an error?

The impact is low enough that I recommend to code reviewers to enforce 
consistency rather than one practice or the other. If an author's default is 
to declare 'final', let them Javadoc when they omit it, and vice versa.

Even though I might know the right answer, if the cost is low and the benefit 
likewise there's greater reward in cooperation than correctness.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#11214

Lew <noone@lewscanon.com> wrote in news:jeir2s$7v0$3@news.albasani.net:

> On 01/10/2012 05:51 PM, Novice wrote:
>> I'm getting an odd compiler warning that I don't really understand. I
>> wonder if anyone can enlighten me on the meaning of this message.
>> Basically, I'm not sure what the compiler's problem is with what I'm
>> doing or the best way to make it happy.
>>
>> I've got a fairly simply method name foo() that takes two parameters,
>> ints called start and finish. During this method, I decrement start
>> and finish and then calls another method, bar(), passing the
>> decremented versions of start and finish. For some reason, the
>> compiler objects to the statements where I decrement start and finish
>> and says "the parameter should not be assigned". I'm running Eclipse
>> 3.7.1 with a 1.6.18 JDK. 
>>
>> So here's what the code looks like:
>>
>> public static int foo(int start, int finish) {
>>
>> /* Other stuff */
>>
>>    start--;
>>    finish--;
>>
>>    bar(start, finish);
>> }
>>
>> It's the start--; and finish--; lines that are raising the warnings.
>>
>> What exactly is wrong with doing that? And what is the best way to
>> make the compiler happy about that code?
> 
> What's exactly wrong is that the assignment to the parameters is
> thrown away, and does you no good.
> 
How so? My original code says - in my opinion - "thank you very much for 
the value but we need to adjust it a little by subtracting one, aside 
from that, it's perfect". It's not like we're changing start to an 
arbitrary value like 0 or 5 billion regardless of the original value. The 
code in this class basically just does String functions to count the 
number of occurrences of a string in another string but I'm assuming that 
the user will consider the initial character of the string being searched 
as '1' while Java's methods are all 0-based. I'm just subtracting one to 
bring the user's view of the situation in line with Java's view.

I'm just wondering why the compiler is so offended by "start--".... 

>> I modified the code as follows to get rid of the warnings but is it
>> really necessary to create two local variables just to eliminate the
>> warnings? Or is there a better way?
>>
>> public static int foo(int start, int finish) {
>>
>> /* Other stuff */
>>
>>    int myStart = start;
>>    myStart--;
>>
>>    int myFinish = finish;
>>    myFinish--;
>>
>>    bar(myStart, myFinish);
>> }
> 
> Yes, there's a better way; that one is silly.
> 
> public static int foo(int start, int finish) {
> 
> /* Other stuff */
> 
>    bar(start - 1, finish - 1);
> }
> 

Yes, I definitely like that better. Strangely enough, writing 

bar(start--, finish--); 

gives me the same warning as before, presumably for the same reason. 

-- 
Novice

[toc] | [prev] | [next] | [standalone]

#11215

Novice wrote:
> Lew wrote:
>> What's exactly wrong is that the assignment to the parameters is
>> thrown away, and does you no good.
>>
> How so? My original code says - in my opinion - "thank you very much for
> the value but we need to adjust it a little by subtracting one, aside
> from that, it's perfect". It's not like we're changing start to an

Nope.  It says, "Subtract one from the value, extract the old value, then 
store the new value back in the variable."

If all you needed was to subtract one, as is the case here, you'd only 
subtract one and not store the result back.  It's the store back that is 
superfluous.

> arbitrary value like 0 or 5 billion regardless of the original value. The

A change is a change is a change.  Why do you think that the new value has any 
influence on that?

> code in this class basically just does String functions to count the

Your example showed absolutely no 'String' functions.

> number of occurrences of a string in another string but I'm assuming that
> the user will consider the initial character of the string being searched
> as '1' while Java's methods are all 0-based. I'm just subtracting one to
> bring the user's view of the situation in line with Java's view.

The word "just" means "and nothing else".  This is not true in your example. 
Your example *also* does something else, superfluously stores the new value 
back to the variable.  It also superfluously extracts the old value from the 
value and ignores it.

> I'm just wondering why the compiler is so offended by "start--"....

That has been explained upthread.  What remains unclear?  We'll be happy to 
fill in any missing details if you indicate what's missing.

>> public static int foo(int start, int finish) {
>>
>> /* Other stuff */
>>
>>     bar(start - 1, finish - 1);
>> }
>>
>
> Yes, I definitely like that better. Strangely enough, writing
>
> bar(start--, finish--);
>
> gives me the same warning as before, presumably for the same reason.

Yes, the warning is for the same reason, but that code will have a different 
effect.

Let's say you call 'foo(7, 3)'.  The first version will call 'bar(6, 2)' (in 
effect).  The second will call 'bar(7, 3)'.

Do you get the reason for the warning (which you also called an error, of 
which I approve)?

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#11218

Novice <novice@example..com> wrote:

(snip)
>>>    start--;
>>>    finish--;
>>>    bar(start, finish);

(snip, someone wrote)
>> What's exactly wrong is that the assignment to the parameters is
>> thrown away, and does you no good.
 
> How so? My original code says - in my opinion - "thank you very much for 
> the value but we need to adjust it a little by subtracting one, aside 
> from that, it's perfect". 

But, as previously noted, why not bar(start-1, finish-1)?

Now, if you are using the new values 10 times, or maybe even
just two, then it is more obvious to me.

> It's not like we're changing start to an 
> arbitrary value like 0 or 5 billion regardless of the original value. The 
> code in this class basically just does String functions to count the 
> number of occurrences of a string in another string but I'm assuming that 
> the user will consider the initial character of the string being searched 
> as '1' while Java's methods are all 0-based. I'm just subtracting one to 
> bring the user's view of the situation in line with Java's view.

> I'm just wondering why the compiler is so offended by "start--".... 

Personally, there are a few things that I find compilers warning
about that bother me. In this case, there is a claim that the test
is optional, and that the default is off.

I wouldn't turn it on, but others might.

-- glen

[toc] | [prev] | [next] | [standalone]

#11222

On Wed, 11 Jan 2012 04:55:00 +0000 (UTC), Novice <novice@example..com>
wrote, quoted or indirectly quoted someone who said :

>I'm just wondering why the compiler is so offended by "start--".... 

The compiler worries when you compute something and don't use the
result.  If you had said    bar( --start )    it would be happy since
the incremented start is passed to bar.

It thinks perhaps you forgot to use the result, on made a typo and
used the wrong variable.  It figures you are addled in some way or you
would not be computing values you did not need.  If you meant it fine,
that's why it is just a warning. There is no rule in  Java you MUST
use every result.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
If you can't remember the name of some method, 
consider changing it to something you can remember.
 

[toc] | [prev] | [next] | [standalone]

#11236

"Roedy Green" <see_website@mindprod.com.invalid> wrote in message
news:dnlqg711uq7njg5bi19fhu76cc6ploibb9@4ax.com...
> On Wed, 11 Jan 2012 04:55:00 +0000 (UTC), Novice <novice@example..com>
> wrote, quoted or indirectly quoted someone who said :
>
> >I'm just wondering why the compiler is so offended by "start--"....
>
> The compiler worries when you compute something and don't use the
> result.  If you had said    bar( --start )    it would be happy since
> the incremented start is passed to bar.

No. This would produce the same warning.

It's nothing to do with not using the result - in the original example, the
result *was* used. It's simply that assigning to a method parameter value is
considered 'bad style', that's all.

[toc] | [prev] | [next] | [standalone]

#11254

On Wed, 11 Jan 2012 20:05:25 +0100, "Gavino" <invalid@invalid.invalid>
wrote:

>"Roedy Green" <see_website@mindprod.com.invalid> wrote in message
>news:dnlqg711uq7njg5bi19fhu76cc6ploibb9@4ax.com...
>> On Wed, 11 Jan 2012 04:55:00 +0000 (UTC), Novice <novice@example..com>
>> wrote, quoted or indirectly quoted someone who said :
>>
>> >I'm just wondering why the compiler is so offended by "start--"....
>>
>> The compiler worries when you compute something and don't use the
>> result.  If you had said    bar( --start )    it would be happy since
>> the incremented start is passed to bar.
>
>No. This would produce the same warning.
>
>It's nothing to do with not using the result - in the original example, the
>result *was* used. It's simply that assigning to a method parameter value is
>considered 'bad style', that's all.

     Oh, my.  Bad style.  That is bad, isn't it?  I am wearing a dark
grey sweater and medium brown pants.  Is anyone's compiler concerned
about my style?

     "style" and "best practices" get bandied about as if they are
sacred.  Often, they are merely someone's opinion, and not necessarily
a well-thought-out one either.

     If a parameter is call-by-value, it is available for modification
in many languages.  Such code is shorter, too.  I prefer a concise
style.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#11269

On 01/11/2012 06:18 PM, Gene Wirchenko wrote:
>       Oh, my.  Bad style.  That is bad, isn't it?  I am wearing a dark
> grey sweater and medium brown pants.  Is anyone's compiler concerned
> about my style?
>
>       "style" and "best practices" get bandied about as if they are
> sacred.  Often, they are merely someone's opinion, and not necessarily
> a well-thought-out one either.
>
>       If a parameter is call-by-value, it is available for modification
> in many languages.  Such code is shorter, too.  I prefer a concise
> style.

Except perhaps for auto-inc/decrement and op-assignment?

When the pundits call these things "bad style", it's completely unrelated to 
matters of personal taste.  You are stalking a dead horse.  They have 
engineering reasons, in the case of the OP's complaint a perceived risk of 
error from the idiom.  It is the presence of such risk that makes the style 
"bad".  If you can objectively prove such risk exists, the style is bad.  If 
you can objectively prove it does not, the style is good.  If you don't know, 
you can claim one or the other as an hypothesis but not a theory.

So everyone who wants to minimize the risk of error in a program cares about 
your style, and you should, too!  People should feel free to write compilers 
that support such criteria.  Oh, hey!  Eclipse did!  And the issues that are 
not proven to be bad style, but claimed by enough wise people to be, are 
*options* to enforce in that compiler.

Dju better get chyo style toGETHah, yo!

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#11287

On Thu, 12 Jan 2012 07:55:39 -0800, Lew <noone@lewscanon.com> wrote:

>On 01/11/2012 06:18 PM, Gene Wirchenko wrote:
>>       Oh, my.  Bad style.  That is bad, isn't it?  I am wearing a dark
>> grey sweater and medium brown pants.  Is anyone's compiler concerned
>> about my style?
>>
>>       "style" and "best practices" get bandied about as if they are
>> sacred.  Often, they are merely someone's opinion, and not necessarily
>> a well-thought-out one either.
>>
>>       If a parameter is call-by-value, it is available for modification
>> in many languages.  Such code is shorter, too.  I prefer a concise
>> style.
>
>Except perhaps for auto-inc/decrement and op-assignment?

     No.  I rarely have need of such things.  I recognise that I could
miss something like that due to this.  To decrease the risk, I avoid
it except where it is part of the idiom I use.

     Trade-offs are rife in this industry.  You have just found one of
mine.  I am not one-dimensional in my concerns.

>When the pundits call these things "bad style", it's completely unrelated to 
>matters of personal taste.  You are stalking a dead horse.  They have 
>engineering reasons, in the case of the OP's complaint a perceived risk of 
>error from the idiom.  It is the presence of such risk that makes the style 

     They might.  Sometimes, it is just someone's bias.

>"bad".  If you can objectively prove such risk exists, the style is bad.  If 
>you can objectively prove it does not, the style is good.  If you don't know, 
>you can claim one or the other as an hypothesis but not a theory.

     If doing so creates another bigger risk, the style is bad.

>So everyone who wants to minimize the risk of error in a program cares about 
>your style, and you should, too!  People should feel free to write compilers 
>that support such criteria.  Oh, hey!  Eclipse did!  And the issues that are 
>not proven to be bad style, but claimed by enough wise people to be, are 
>*options* to enforce in that compiler.

     Wonderful.  So to use such a compiler, I have to make sure to
configure it just right.  Is there a confgiuration style that is
enforced?

>Dju better get chyo style toGETHah, yo!

     Not the usual style of this newsgroup to be sure.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#11290

On Wed, 11 Jan 2012 18:18:57 -0800, Gene Wirchenko wrote:

>      Oh, my.  Bad style.  That is bad, isn't it?  I am wearing a dark
> grey sweater and medium brown pants.  Is anyone's compiler concerned
> about my style?
>
IMO the only egregiously bad style is not sticking to the style used by 
the original programmer when you're amending the program. In my book this 
is an invariant rule, no matter how obnoxious the original style is 
because doing anything else is sure-fire way to make even very ugly code 
much worse.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#11291

Martin Gregorie wrote:
> On Wed, 11 Jan 2012 18:18:57 -0800, Gene Wirchenko wrote:
> 
>>      Oh, my.  Bad style.  That is bad, isn't it?  I am wearing a dark
>> grey sweater and medium brown pants.  Is anyone's compiler concerned
>> about my style?
>>
> IMO the only egregiously bad style is not sticking to the style used by 
> the original programmer when you're amending the program. In my book this 
> is an invariant rule, no matter how obnoxious the original style is 
> because doing anything else is sure-fire way to make even very ugly code 
> much worse.
> 
> 

I agree. In a few cases, I've kept a shadow copy of some code that was
formatted with reasonable indentation etc. for reading, but still made
my changes in the original code, warts and all.

Patricia

[toc] | [prev] | [next] | [standalone]

#11293

On Thu, 12 Jan 2012 16:11:43 -0800, Patricia Shanahan wrote:

> Martin Gregorie wrote:
>> On Wed, 11 Jan 2012 18:18:57 -0800, Gene Wirchenko wrote:
>> 
>>>      Oh, my.  Bad style.  That is bad, isn't it?  I am wearing a dark
>>> grey sweater and medium brown pants.  Is anyone's compiler concerned
>>> about my style?
>>>
>> IMO the only egregiously bad style is not sticking to the style used by
>> the original programmer when you're amending the program. In my book
>> this is an invariant rule, no matter how obnoxious the original style
>> is because doing anything else is sure-fire way to make even very ugly
>> code much worse.
>> 
>> 
>> 
> I agree. In a few cases, I've kept a shadow copy of some code that was
> formatted with reasonable indentation etc. for reading, but still made
> my changes in the original code, warts and all.
> 
Very bad style (COBOL example - sorry)

- all data names took the form XXnn where, for instance MT01 was the 
  name of the first record in the first file declared and it went on
  MT02, MT03, MT04... through the fields in that record and continued 
  in this fashion through all the fields in all the record definitions 
  in 3 or 4 files. Same for cards (from CD01), printers (from LP01) and
  through working storage (WS01.....)

- Procedure division was similar: all paragraph names were of the form 
  GDnnnnn, were not in numeric sequence, and no sections were used.

...and this was a 5000 line program! 

The same clowns had developed an entire accounting package this way, 
except for a few programs which were written in equally obnoxious 
assembler. That means assembler with almost no comments or labels and an 
obsession with using register-register operations and relative jumps in 
preference to named storage locations and jumps to labels.

To make matters worse, one of our idiot managers had bought the blasted 
package without appraising either the code or the (almost non-existent) 
documentation.

The third axiom of programming being "If a program is useful, it must be 
modified", guess who got lumbered with that....


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#11256

On Wed, 11 Jan 2012 20:05:25 +0100, "Gavino" <invalid@invalid.invalid>
wrote, quoted or indirectly quoted someone who said :

>It's nothing to do with not using the result - in the original example, the
>result *was* used. It's simply that assigning to a method parameter value is
>considered 'bad style', that's all.

Normally I mark my parms final, but have modified them.  I don't
recall ever seeing that warning.  I guess it does not show up in
IntelliJ.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
One of the most useful comments you can put in a program is 
"If you change this, remember to change ?XXX? too".
 

[toc] | [prev] | [next] | [standalone]

#11257

On 1/11/2012 6:26 PM, Roedy Green wrote:
> On Wed, 11 Jan 2012 20:05:25 +0100, "Gavino"<invalid@invalid.invalid>
> wrote, quoted or indirectly quoted someone who said :
>
>> It's nothing to do with not using the result - in the original example, the
>> result *was* used. It's simply that assigning to a method parameter value is
>> considered 'bad style', that's all.
>
> Normally I mark my parms final, but have modified them.  I don't
> recall ever seeing that warning.  I guess it does not show up in
> IntelliJ.

I believe the warning originally came from Eclipse. The Eclipse style
rules are not carved in stone. A programmer who does not agree with the
default settings should change them.

Patricia

[toc] | [prev] | [next] | [standalone]

#11258

On 1/11/2012 10:01 PM, Patricia Shanahan wrote:
> On 1/11/2012 6:26 PM, Roedy Green wrote:
>> On Wed, 11 Jan 2012 20:05:25 +0100, "Gavino"<invalid@invalid.invalid>
>> wrote, quoted or indirectly quoted someone who said :
>>
>>> It's nothing to do with not using the result - in the original
>>> example, the
>>> result *was* used. It's simply that assigning to a method parameter
>>> value is
>>> considered 'bad style', that's all.
>>
>> Normally I mark my parms final, but have modified them. I don't
>> recall ever seeing that warning. I guess it does not show up in
>> IntelliJ.
>
> I believe the warning originally came from Eclipse. The Eclipse style
> rules are not carved in stone. A programmer who does not agree with the
> default settings should change them.

     To my way of thinking, a method (or constructor) parameter is
nothing more nor less than a local variable, taking its initial
value from the caller's argument.  One characteristic of a variable
is that it can vary; that's why we don't call them invariables.  I
can see no reason to preserve a parameter's initial value in bronze
like Baby's first shoes, and Eclipse's assertion that failing to
bronze a parameter "is generally considered poor style" is merely
noise, Proof By Iterated Assertion.  (In the passive voice, which
is generally considered poor style.)

     If anyone, anywhere, anyhow, has evidence that bronzing the
parameters improves them, let the evidence (and not just the PBIA)
be produced.  Until then, I'll leave my parameters unbronzed and
still wearable.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web