IMHO, the two most important design principals go hand in hand.. These are minimalism (a subset of laziness, but also something entirely different (small, compact, decoupled bits)), and robustness (never cut corners. You should design so that the corners are left in tact, even if between them everything is just a stub). I use # FIXME comments a lot, when I don't want to lose my concentration, but I make sure that the places that have to be fixed are really problematic, and can't be worked around more eleganlty instead.

If you design for these two, possibly with the latter being the tie breaker, you usually end up forcing yourself into writing concise, maintainable, reasonably efficient code.

After that, optimise for readability, which implies robustness (due to less errors especially in maintaince), and interface flexibility (use the law of demeter, as well as tests (especially having to do with mocking) to try and find the weak points of your interfaces).

These basic principals are easily enforced by unit testing as both a test for your design, since it is the first real world usage the code gets, and as a measure for robustness (Devel::Cover helps you find edge cases you may have overlooked, and code that shouldn't be there (which should be considered as more room for bugs)).

I usually write two scripts per piece of functionality - an api test, and a real world test. A real world test makes use of as much of real examples as possible, and helps with the design, as well as overall sanity. It does one thing, usaully. The api tests cover every corner, and make extensive use of mocking/white box techniques. I never ever test more than one piece of functionality in a single test, because that confuses stuff. As time goes by regression test files for errors are made, or appended to the api tests, and the critical sections get stress tests, which is a deliberate attempt to try and break the system (usually these are worth a lot once, when you first write them, but not as much afterwords).

Provided you keep things small, and tidy, and well behaved, and always listen to your gut if it tells you you're doing something you don't really like, you should be OK.

Places where I get a bad gut feeling are, for example when the logic knows about special cases having to do with the environment, or when tests jump through hoops to get the job done, or any kind of repitition.

Lastly I'd like to mention that the best sanity check is to get other peoople to help you think, usually about design. Code reviews are hard to get done because usually deadlines don't let them happen as much as they should, but design reviews are really a necessity. And if you can't get design reviews, then try and design as early as possible, but implement as late as possible, so that you can more easily criticise yourself about your design in retrospect.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.