False-positive warnings for checks: Unused parameter, Null assignment, Variable shadowing, While true loop, Empty if expression

[Stardust1225]

I use scapegoat in project akka/akka, and find more than 90% of warnings from this five checks are not what I need.
1. Unused parameter
when the code is like:

case class A{
    def method(a: String, b: Int) = {
        a = "hello world in method 1"
    }

    def method(a: String) = {
        a = "hello world in method 2"
    }
}

Check Unused parameter would throw warning for parameter b in method. However, I think that b serves as a chooser for the two methods.

2. Null assignment
I think that if assign null to a var, it would not be warned for the var cannot be modified.

3. Variable shadowing
When the code is like:

case class A(a: String){
    def method(a: String) = {}
}

this check would throw warning for var a. But in this situation, a in method would not cover the class variable a, which can be distinguished by a and this.a.

4. While true loop
If there exists return statement in a while true loop, there exists a path to end this loop, and .

5. Empty if expression
If code is like:

if( bool expresion ){}
else{}

and else block is not empty, I think that the empty if block just serves to skip condition judgment, or it is easy to write conditions in if part.

[mccartney]

(Edited your text for formatting, I hope you don't mind)

[mccartney]

As to the actual suggestions:

• re 1 - I think the standard solution to this is to avoid overloading in such case, i.e. name the methods differently. What is the real-life use-case for sticking to overloading? Can you give a more realistic example?
• re 2 - I am not fully sure I understand. I observe a lot of these null assignments false-positives (or matter of taste) myself. I am not fully sure if the same is meant though. "My" usages are around passing null as arguments to Java methods or methods which interface with Java deeper in the stack.
• re 3 - I don't agree to be honest. a is shadowing a, the name a is ambiguous. The fact there's a way to point to the class-one doesn't make the a reference unambiguous.
• re 4 - I suppose you are missing some text at the end of the entry
• re 5 - that arguably makes sense. I think people suggest that negating the original condition in most of the cases is not much of a pain. Thus:

if (even || a && complicated.boolean.condition()) {
// no code
} else {
// a lot of code
}

is convertable to

if (!(even || a && complicated.boolean.condition())) {
// a lot of code
}

[Stardust1225]

I miss some description in While True loop

while( true ){
    // wait for a thread to return value.
    if( some condition )
        return // or break 
    else
        thread.sleep(5000)
}

If the code serves as polling, and has return or break in the loop, I don't think it should be warned.``