That’s the style I’d use, ever since I learned it from Wil Shipley’s blog (Delicious Monster) for reducing nesting and improving readability, as you said. Essentially, set up conditionals to bail out immediately if the there’s nothing to do because of the circumstances not being met. Great suggestion, IMHO.

if (!String.prototype.trim) {
String.prototype.trim = function (chars) {
var that = this.toString();
chars = chars || '\\s';
if (Array.isArray(chars)) {
chars = chars.join('|');
}
var re = new RegExp('^(' + chars + ')+|(' + chars + ')+$','g');
return that.replace(re,'');
}
}



for_own(objects, function (o) {
// ...
});


Where for_own would be something like:


function for_own(obj, fun) {
for (var key in obj) {
if (obj.hasOwnProperty(key)) {
fun(key);
}
}
};


Greets!

It’s just wrong to say that a js Object is not a prop/value hash, should not be used as such, and then go on to implement an alternate hash mechanism. Objects certainly are hashes (dictionaries, key/value pairs), but they don’t behave exactly like hashes in some other languages. Yes, because of prototyping and inheritance a js hash can get additional members. Using hasOwnProperty is a correct way to filter these – that is, it’s a correct way to use an object hash in javascript. Do you really want to write a custom hash object just to avoid the one-line property check? Like so many libraries and toolkits out there, this smacks as an effort to turn javascript into a different language. These efforts usually result in overhead, obfuscation and maintenance challenges.

Ok, the science. I wanted to know the overhead of adding a hasOwnProperty() check. I also timed the alternate (inferior) “typeof obj[key] !== ‘function’” check. Instead of over-burdening this comment with the full results, if you’re interested, the engine is at http://randomous.com/tools/misc/timer.php. The results of timing tests relevant to this article are at the bottom of that page.

Cheers…

var obj = {
Garrett : "monkeybrains"
,borked : "javascript" // transitivity fixed :-)
,toString : function() { return "an enumerable prop"; }
,valueOf : function() { return 2; } // also enumerable.
};

// can this be false for any value of s?
(obj.hasOwnProperty( s ) != obj.propertyIsEnumerable( s ))

Using “in” will check the prototype chain.

This feature can be useful for examining the prototype chain. For example, if you wanted to generically advise each method in a Panel
class, you could iterate through all the functions in the object’s prototype chain.
If you think about it, it can be a useful feature.

In fact, the “flaw” that Doug mentions is intentional behavior of the language. As mentioned in earlier comments, it is a perfectly valid feature (read above).

Sweeney mentioned using propertyIsEnumerable to check an object’s properties in lieu of missing hasOwnProperty.

Interestingly, propertyIsEnumerable is specified such that coforming implementations will have the exact same result as with hasOwnProperty.

Method propertyIsEnumerable does not check the prototype chain (15.2.4.7). Since all programmer-defined properties are enumerable. Therefore, propertyIsEnumerable provides the behavior that Doug so desires.

The fact that propertyIsEnumerable does not check the prototype chain is itself a bug of the spec. David Flanagan pointed this out and Brendan will readily admit that it’s a bug. JScript and SpiderMonkey both implement the spec correctly in this aspect.

The fact that propertyIsEnumerable does not check the prototype chain is, in fact, a bug that

Unfortunately, JScript suffers from another bug that causes propertyIsEnumerable to return false on a user-defined object property.

This happens when the value that is passed to propertyIsEnumerable exists in the instance and overrides a non-enumerable (DontEnum) property in the object’s prototype chain (such as an overridden “toString”)

Matthew Frank provides a tighter version of trim, and there’s nothing wrong with adding trim, however, it should be done conditionally:
if(!String.prototype.trim)
String.prototype.trim = function () {
return this.replace(/^\s+|\s+$/g, '');
};

The conditional check is necessary because future versions of ECMAScript will have String.prototype.trim.

@Andrew Dupont the !== will produce the same result as != when both operands are string values (returns false if the sequence of characters is not an exact match,). I would probably opt for != though.