Comments on: Writing Self-Confident Code

By: Assertive Code | Virtuous Code

Assertive Code | Virtuous Code — Wed, 18 Nov 2009 21:56:48 +0000

[...] Self-confident code does not ask questions about the data given to it. It enforces validity, asserts that its expectations are met, or ignores data which isn’t up to its standards. Previously we’ve looked at some methods for enforcement, using fetch() and Array(). Today I want to talk about the second tactic, assertions. [...]

By: MrProper: Cleaner blocks in Ruby | Teambox

MrProper: Cleaner blocks in Ruby | Teambox — Sun, 01 Nov 2009 17:27:46 +0000

[...] are better alternatives to this, like andand. I enjoyed the posst about Array-ifying values and Self confident code, [...]

By: Array-ifying Values | Virtuous Code

Array-ifying Values | Virtuous Code — Thu, 22 Oct 2009 00:06:47 +0000

[...] Now go forth, and write self-confident code!tweetcount_url=’http://avdi.org/devblog/2009/10/21/array-ifying-values/’;tweetcount_title=’Array-ifying Values’;tweetcount_short_url=’http://bit.ly/4s6jg2′;tweetcount_cnt=1;tweetcount_size=’small’;tweetcount_api_key=’R_350d7294f25ec925b86f310039d41d2f’;SHARETHIS.addEntry({ title: “Array-ifying Values”, url: “http://avdi.org/devblog/2009/10/21/array-ifying-values/” }); This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License. [...]

By: Mark Wilden

Mark Wilden — Mon, 03 Nov 2008 13:50:29 +0000

I don't think “something went wrong somewhere” is ever a valid value. In fact, I think that's the real usefulness of this article: Don't code defensively, assuming that you might have screwed up somewhere and therefore need to put up safety nets. Just do it right in the first place (and use automated testing to define “right”).

As for using one representation for two concepts, that's a valid argument, which is behind the anti-NULL-ers like Chris Date. I'm on the other side of that argument (the Codd side) and have no problem with the idea that nil represents a “non-value,” especially in favor of fabrications like 9/9/99. That's what nil was designed to do. I've used languages without it (e.g. C) and I'm glad to have it. But as I indicated above, this isn't an argument that's going to get won any time soon.

By: Captain Hammer

Captain Hammer — Mon, 03 Nov 2008 12:17:10 +0000

Mark — representing missing information is an important topic. There's nothing wrong (to my mind) with using 'nil' to represent a missing birth date. The problem is that nil is also a perfectly valid value for 'something went wrong somewhere'. So now we have a value with two meanings. It doesn't matter how you choose to represent a missing value — as long as that representation isn't already in use.

By: Mark Wilden

Mark Wilden — Fri, 31 Oct 2008 17:25:04 +0000

This has been an issue in the database community for a long time. The essential question is, how do you represent missing information? Take birth date, for example. Do you refuse to allow people without birth dates in your code? Do you give them a default birthdate (??). Or do you recognize that nil is a perfectly valid value for a variable that holds a birth date, and deal with it accordingly?

By: Shannon -jj Behrens

Shannon -jj Behrens — Fri, 31 Oct 2008 17:11:18 +0000

> Code that constantly checks if things are null has an insecurity complex, always second-guessing itself. Make your code self-confident. Eliminate null checks wherever you can.

I agree 100%

By: Sammy Larbi

Sammy Larbi — Fri, 31 Oct 2008 11:34:18 +0000

I've always called the code with tons of null checks “paranoid code.” I like that you've called the opposite “self confident.” That's a good phrase for it.

By: avdi

avdi — Thu, 30 Oct 2008 19:45:16 +0000

On a second reading I think we're mostly on the same page. I don't really have a problem with using assert() a lot. assert() isn't a conditional – it says “I never, EVER expect this to be null”. I don't have to write a unit test to test that my code handles the null and non-null cases correctly, because the null case will always crash. What I'm advocating against is code that tries to handle nulls as an expected case.

By: avdi

avdi — Thu, 30 Oct 2008 19:40:08 +0000

In Rails, if I have something that may or may not be displayed I like to wrap that in a helper rather than put a conditional in the view.

But Rails views are smelly in general, because as the least-OO part of Rails they are the hardest part to apply conventional OO patterns and idioms to.