Literate Programming - Before we discuss the acronyms.....

submitted by dcarr 2 months, 4 days ago

literateprogramming.com — All to often (as it is far easier) people relish the technical discussions without digging into the 'how and why does this fundamentally help me' at a few levels of abstraction higher. I for one think code comments are the exception not the rule. Why? 1) If you need to comment it you likely need to refactor it. THis is why ReSharper is so mandatory. It's the practice not the tool. Why refactor? 90% of most cost is in maintenance. 2) Code comments are as often as node misleading and incorrect as they are not kept up to date. 3) Improvements in automated developer generated API docs are sufficient in most cases. This leaves the 'domain-specific' or 'contextual' documentation as the mandate. Here your focus is not on the how, but the why and the what. If you discuss the abstraction's rationale, and reason for existence, not how it internally works, you're safe. There are always exceptions to any rule however this is just to get the ideas flowing. For example, CruiseControl.NET is a fantastic tool. However it's not about the tool, it's about the practice. The fact that Microsoft 'patterns and Practices' has no ' and tools' at the end is because tools change quickly and their abilities dramatically but the concepts from 10 years ago are still not used if there is in general no easy 'tool support'. People don;t like to think this iway in general and if there was perhaps one reason some evolve into 'architects' or whatever you want to call them, it is this. The site listed helps.. DAmon

add a comment | category: Architecture | Views: 8 | Get KickIt image code