By Topic

Before clarity [software design]

Sign In

Cookies must be enabled to login.After enabling cookies , please use refresh or reload or ctrl+f5 on the browser for the login options.

Formats Non-Member Member
$31 $13
Learn how you can qualify for the best price for this item!
Become an IEEE Member or Subscribe to
IEEE Xplore for exclusive pricing!
close button

puzzle piece

IEEE membership options for an individual and IEEE Xplore subscriptions for an organization offer the most affordable access to essential journal articles, conference papers, standards, eBooks, and eLearning courses.

Learn more about:

IEEE membership

IEEE Xplore subscriptions

1 Author(s)

Most software developers become preoccupied with the question of what makes good design at some point in their careers, usually after witnessing the effects of bad design first hand. At that point, we start to reflect. We go through a stage where we feel we know what good design is but can't really define it. Then we learn various design principles and rules of thumb that make it easier to judge what constitutes good design. But when these principles and rules conflict, we have to make trade-offs and decide what's most important in each situation. The blanket rule of thumb: Keep design as clear as possible. Regardless of the trade-offs, the most important thing was clarity. If a system uses a straightforward coding style - the classes and methods are well named and small enough to be clearly understood, and the system isn't littered with snarls of obscure code - then you can do just about anything. You can change the system with impunity, write tests for it, make adjustments, and add features, all with relative ease. So "clear design is good design" seemed like a reasonable rule of thumb because so much of what makes code impossible to maintain comes down to a lack of clarity. If you can understand your system, you can change it effectively.

Published in:

Software, IEEE  (Volume:21 ,  Issue: 6 )