In my work the need to explicitly dispose of an object (as opposed to letting the finalizer do the work) using the using() statement is pretty rare. I think excess usage of using() may be a form of premature optimization, but that’s just me. There are some cases such as IO and Database Connections that it’s a good standard to follow, but those should probably be abstracted anyways.

Properties are actually a sort spot on my list. :-) It’s so very difficult to do lots of cool things when people go around writing non-virtual-by-default Properties for everything. And 99% of the time they’re just getters and setters.

I read a post by someone much smarter than me once that basically said that if you’ve got a DataTransferObject on your hands, skip the getters/setters and just use Fields. This was in regards to Java by the way. Being a c# guy I instantly cringed at the idea, but those ThoughtWorks guys are generally a pretty smart bunch so I gave it some consideration and realized that… wow… yes, there’s downsides to the idea, but imagine the upsides. *MUCH* less code (even if it is code-genned by Resharper, it’s still ugly and tedious) and it really simplifies reflective magic since you don’t have to decide between a Property that may have unintended side-effects (since you don’t have knowledge of it until runtime), or a private field that requires a reduced security level.

Sorry for rambling. The point was, if it’s a DTO, use Public Fields. I buy that.

If it’s not a DTO, then Fields should be shy, and Properties rare, so to be honest the setTimeout(300) vs Timeout = 300 doesn’t really bother me much one way or another.

The important part is that neither are Ruby when it comes to getters/setters, so it’s just splitting hairs from that perspective. :-)