Great habits

jplindstrom on 2003-06-11T18:43:09

I don't do XP, but I try to hang around that crowd. They seem like such a super smart bunch of people with such clear and useful ideas and such nifty sayings. This is one:

I'm not a great programmer; I'm just a good programmer with great habits --Kent Beck

So, what are your great habits? Big and small. In your own journal or Comment here.

I'll start:

API-driven development

If you don't do test-driven development, at least do API-driven development.

When writing a method or sub, don't start coding right away. Start by describing what you are gonna code (hello POD). That way you a) get a documented API, especially return values are nice to know without exploring the implementation three method calls deep b) think things through one more time before coding c) tend to think about (and possibly state) edge cases, assumptions and error conditions

Example I =head2 raHistoryFromText($text)

Return array ref with hash refs (keys: version, user, date, time, datetime, action, comment) with history information in $text.

Return undef on errors.

=cut
Example II =head2 parse(SQL::Map::Parser $oParser, SQL::Map::Database $oDatabase)

Parse the source text using $oParser, and modify this and referencing objects in $oDatabase.

Return 1 on succes, else 0.

Abstract.

=cut


pragmatic habits

inkdroid on 2003-06-11T20:13:04

For a great list of programming habits check out the reference card that comes with the Pragmatic Programmer. It has 70 of them. Here are some of my favorites:

  • Always use source code control: source code control is a time machine for your work--you can go back.
  • Fix the problem, not the blame: It doesn't really matter whether the bug is your fault or someone else's--it is still your problem, and it still needs to be fixed.
  • select isn't broken: It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application.
  • Separate views from models: Gain flexibility at low cost by designing your application in terms of models and views.
  • Don't gather requirements--dig for them: Requirements rarely lie on the surface. They're buried deep beneath layers of assumptions, misconceptions, and politics.
  • Crash Early: A dead program normally does a lot less damage than a crippled one.
  • Invest regularly in your knowledge portofolio: Make learning a habit.
  • Don't use manual procedures: A shell script or batch file will execute the same instructions, in the same order, time after time.