Software development, .Net, SQL Server, TDD, Agile, Community and other Odds and Sods
Mitch Wheat has been working as a professional programmer since 1984, graduating with a honours degree in Mathematics from Warwick University, UK in 1986. He moved to Perth in 1995, having worked in software houses in London and Rotterdam. He has worked in the areas of mining, electronics, research, defence, financial, GIS, telecommunications, engineering, and information management. Mitch has worked mainly with Microsoft technologies (since Windows version 3.0) but has also used UNIX. He holds the following Microsoft certifications: MCPD (Web and Windows) using C# and SQL Server MCITP (Admin and Developer). His preferred development environment is C#, .Net Framework and SQL Server. Mitch has worked as an independent consultant for the last 10 years, and is currently involved with helping teams improve their Software Development Life Cycle. His areas of special interest lie in performance tuning
Sunday, September 24, 2006
Elements of Composition
Here are just a few of the principles espoused in the “Elements of Style” (see my previous post) which I have taken liberty with and made a few OO analogies:
Choose a suitable design and adhere to it. This pretty much stands alone as good advice in the context of writing or coding. Spend time on the design before you start coding. Don’t hastily start coding to one design, then change it, and then change it again.
Make the paragraph the unit of composition. As a general rule, start each paragraph either with a sentence that suggests the topic or with a sentence that provides a transition. This is similar to grouping like behavior into classes. A class should contain a well-defined set of related methods, not just a random collection of unrelated functionality.
Keep related words together. The principle means of showing the relationship of words to one another is their position. The intent is to give clear meaning, and not to confuse the reader by making sentences ambiguous. The analogy I tenuously liken this to is name your methods accurately, preferably with verb-noun pairing.
Use the active voice. The analogy here is objects being asked to perform a particular behaviour rather than being used in functional coordinated approach.
Put statements in positive form. This is akin to avoiding the double negative in poorly named methods.
Use definite, specific, concrete language. Put truly common behaviour into abstract base classes, place specific behaviour in concrete classes.
Omit needless words. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences. This could be restated as: A class should contain no unnecessary methods, a method no unnecessary lines of code.
Avoid a succession of loose sentences. Do not place inappropriate behaviour in classes. If things get too complicated, make more types.
MSN, Email: mitch døt wheat at gmail.com