Re: toward null-safe cookie cutter Comparators
On 11/25/11 6:44 PM, Arne Vajh?j wrote:
On 11/21/2011 2:25 PM, Daniel Pitts wrote:
On 11/21/11 4:39 AM, Brixomatic wrote:
On 20 Nov., 17:23, Lew<lewbl...@gmail.com> wrote:
A 'NullPointerException', like other runtime exception, evidences a
programming error.
You just spoke up in favor of deliberately programming bugs into the
code.. Stupid, stupid
idea. Please do not work on any project I care about.
Reality is that I dislike to deliberately introduce a bug to my code,
but that sometimes people get forced to do so. That said: A bug is a
bug, whether it's an NPE or another kind of failure in the program.
NPEs are often easier to track down, that's why I favor them. Alas it
is not always my decision.
It is often easier to beg forgiveness than beg permission. "It wasn't my
decision to code this bug" is a cop-out. Yes, in the past I've had to
code things differently than I thought best. I was very junior. Once I
got over that and started doing things *my* way (disobeying direct
orders), I began to rise in the ranks.
Note, I did things my way, not because I didn't understand why they
wanted it the other way, but because I understood the consequences of
both approaches.
I will not recommend that strategy as a career move.
In a lot of places developers disobeying direct orders because
they think they know better will be kicked out immediately.
Perhaps, it depends on the project of course, and how many others depend
on you doing your work the way you were told. If you're developing a
library for others to use, and don't do it the way it was designed, then
you've caused problems for many others who were expecting to design
their application one way. On the other hand, if you're developing an
internal tool without interfacing with anyone else, then as long as you
meet the functional requirements, your "internal improvements" shouldn't
be a concern, as long as they are *real* improvements.
It can be a difficult judgement call, but it is sometimes better to
start with the way you think it should be done (especially if it takes
less time to do that), and then "build the bridge" to the way they
wanted it to be done. Building an ugly facade in front of good code is
better than building a pretty facade in front of bad code. Especially
if you're maintaining the code more than the facade.