Re: Style Police (a rant)
Jan Burse wrote:
Lew schrieb:
Oh - I actually read it wrong and thought you had said, "... did not do=
cument ...",
> and not documenting was what frightened.
Well it would be frightening if life would depend on it,
but since the keyword final either does nothing or
does increase the speed only a little, I focused on
other stuff.
Fair enough, but I thought your thesis was that the 'final' keyword was a g=
ood thing for performance. I apologize for misunderstanding.
While the 'final' keyword "either does nothing or does increase the speed o=
nly a little" from a performance standpoint, as you say, the OP's rant rela=
ted to the semantic impact. In that domain the 'final' keyword does a grea=
t deal.
Whether that impact is good or bad depends on how rigorous you are when you=
write classes. Josh Bloch's advice and the default enforcement by Checkst=
yle are grounded in a rigorous style of class design where you account for =
all corner cases and don't leave much, if anything, to chance for future us=
ers of the API. This is the style that, for example, favors checked except=
ions. Some folks on the receiving side of such decisions get a little peev=
ed - they feel put upon to catch exceptions, "Favor composition over inheri=
tance" or "Design and document for inheritance or else prohibit it" [op cit=
..]. Well, that's why they're paid the big bucks. Such restrictions increa=
se the safety and predictability of the code and systems built with it, whi=
ch is their rationale.
Rigor comes at a cost, that is true. Intelligent design requires that you =
consider the tradeoffs, bearing in mind that you yourself might or might no=
t directly suffer the consequences of your choices. Checkstyle errs on the=
side of rigor in its defaults.
--
Lew
The journeyman knows the rules. The virtuoso knows when to break the rules=
.. The master creates new rules.