The Evil of Implicitness

I really dislike things that are implicit. Okay, it doesn’t help that I’m the most forgetful person I know, but still.

I’m a believer that if you want something done, you should do it. Use a framework if you like as a tool, but explicitly ask that tool to perform the task. Things shouldn’t be hidden away, doing as they please.


Post build steps
I’ve mentioned it before, but I really do like my build process to explicitly do everything I need, in one place.

My boss gave me a tip yesterday. He says that for things like this:

insert into a_table (id, the_value) values (1, 11)

He sometimes cheats and does this:

insert into a_table select 1, 11

I think that’s dead clever (because I thought you had to specify the columns you want to insert into), although I’d personally never run it on a production database, and it would only be for quick and dirty test code on a database I control. The problem is (and to be fair he admitted this), if someone changes the schema of that table, things can get messy very quickly. I’m more anal so my first thought was that I just like to know what columns I’m editing without having to investigate that table schema before I run it.

Of course we all know the evils of:

select * from a_table_that_might_have_columns_added

Which speaks for itself, so let’s not dwell on that.

Attack of the Scheduled Job
I personally dislike any kind of scheduled task. It makes me nervous to think that there’s an unknown cloud of processes that I don’t know about that might be editing my data without me knowing.  Also, you lose a bit of the “realtimeness” of information with scheduled jobs. Of course sometimes this is necessary, as in the case of maintenance tasks.

So I like to do things by hand a lot of the time. I don’t like to write classes that do work in constructors, I prefer instead to use factory methods or create static methods called “Load” which create the object and populate it for me. Right or wrong is tough to decide, and is probably a religious issue as much as anything else. But “better safe than sorry” and “keep it simple, stupid” are principles that make applications easier to maintain, because you avoid more issues from happening, and make it easier to find and fix those that do appear.

2 thoughts on “The Evil of Implicitness

  1. I suppose you’d also dislike nullable columns, column defaults and triggers. They have their place as db schema features, but tend to happen by mistake rather than by design.

    I love scheduled tasks. Just need to have a good notification, logging and scheduling architecture to support it, which not all scheduling environments have. With notifications and logging there isn’t anything invisible about a scheduled task.

  2. It’s funny, I’m not a fan of nullable columns (except for dates, which I don’t mind) defaults or triggers. The only triggers I don’t mind are those in Oracle, when you need one to get the next value from a sequence.

    You make a good point on the scheduled tasks. If they are well-documented in terms of purpose (what, not how) etc then I can live with that.

    Thanks for your comment, btw. Hope to hear from you again.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s