Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jplindstrom (594)

jplindstrom
  (email not shown publicly)

Journal of jplindstrom (594)

Wednesday June 11, 2003
01:43 PM

Great habits

[ #12753 ]

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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • For a great list of programming habits check out the reference card that comes with the Pragmatic Programmer [pragmaticprogrammer.com]. 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