SCJD - Code Conventions using logs and assertions

[Marcelo Ruiz]

Hi,

I'm having a little problem applying the Sun's Code Conentions, and I will really appreciate your views on it.
I decided to provide logging for my application, and also use assertions to check preconditions and postconditions. The problem I have is decide the order I should use them withing the method.
According to Sun's code conventions the first thing in the method body should be the variables' declarations, but what happens for example if I want to log the parameters to the method (maybe using log.entering), perform assertions about the state of my class and declare variables too?
I have Andrew's book, and in page 141 he logs first and then declares a List<DVD>. Is this a violation to the Code Conventions?
Thanks a lot,

Marcelo.

[Mike Simmons]

Technically, yes, that's a violation of Sun's coding conventions. I tend to doubt it's terribly important in this particular case, as that's always seemed a very poor rule, and I rarely see people follow it in the real world. But if you want to be as safe as possible, you may want to follow the rule exactly. In which case you can't put logging before variable declarations.

Remember, too, you don't necessarily have to put all local variable declarations at the beginning of the method. The rule is to put them at the beginning of the block that they're declared in. So you could do something like this:

public int myMethod(int a, int b) {
    int result = 0;
    log.entering("MyClass", "myMethod", new Object[] { a, b});
    {
        Foo foo = new Foo();
        Bar bar = new Bar();
        Baz baz = new Baz();
        result = foo.combineWith(bar).thenApply(baz).getResult();
    }
    log.exiting("MyClass", "myMethod", result);
    return result;
}

Here we've got an anonymous block, for no other purpose than to circumvent a really silly rule.

[Marcelo Ruiz]

Mike,

Thanks a lot for your reply.
The anonymous block to circumvent the rule was something I didn't think about. It's nice to know the trick!
In case you wanted to add one initial assertion to check that the class is ready to accept requests, where would you add it? What I read says that it should be before any other statement, and of course I read the same for logging entering.
Thanks again,

Marcelo

[Alecsandru Cocarla]

I'd say that creating a useless block whenever you need a declaration is even worse than declaring in the middle of the method.

I for one do not follow this "declare all variables at the beginning" because I think it's silly and less readable than declaring what you need where you need it. If you use something only in the last part of your method, you have to scroll back to the beginning to see what that was... How's that helpful?

So, in my opinion, you can forget about this rule alltogether. Or at least, don't let it mess up your assertions and logging, which is far more important than this silly rule.

[Mike Simmons]

I agree - making an anonymous block like that is unusual enough that it could be considered to hamper readability for most people. And the SCJD is not a good place to invent a new style. I was just playing around with ways to obey the letter of the rule. But I agree that it's probably best to just ignore it - it's a silly rule.

[Alecsandru Cocarla]

Regarding the second question, where should the assertions be added, before or after the logging, I'd say after. This way, you get the logs and the assertion. Otherwise, the error will pop up before logging and you won't have it anymore.

Anyway, about assertions - should they really be used? I haven't used them so far. Should I? Any good reasons to do so, and some guidelines about what and when to check?

[Marcelo Ruiz]

Hi,
Regarding the assertions, I followed Sierra and Bates' advice (in the Study Guide to the SCJP certification) to use assertions in production code.
I used them to check preconditions, to verify arguments in private and package-default methods, and to verify that some postconditions are met when exiting the method.
I think every argument that has some restrictions should be validated somehow. If they're public or protected methods I check them and throw an IllegalArgumentException or NullPointerException when they don't meet the requirements.