Before you write a major function check on statlib to see if
there is something similar to what you need. (See section Where can I get contributed functions?, for information
on obtaining contributed functions and See section What is the statlib server? How can I access it?, for info on
statlib). A question to the S-news list with a brief
description of what you want (See section Asking questions of the mailing list.,) might elicit useful responses.
Some general guidelines for function writing are given below:
Use full names for arguments and function names; args can be abbreviated, so the full name doesn't hurt. There are lots of functions, so a good name is important.
Provide reasonable defaults for arguments.
Read current S code to see (some) examples of good style.
Start simply, get something working immediately and build capabilities gradually and interactively. Try to think of your computation in "whole data" terms. What is it trying to produce as a final result? Don't rush in to write it as a sequential Fortran algorithm.
Use self-checking computations while doing interactive data analysis with S. Try to think of ways of checking your work. For example,
sum(resid) == 0.
The function, browser(), could be of help in debugging your
functions.
Try to deal with the most general situation if not too ugly. For example, NAs, character data, lists, 0-length args, rather than just numeric vectors. On the other hand, it's easy to get too ugly. It's better to have short simple computation that does 90% of all cases than to try to accommodate all things.
Do appropriate error checks on args if the standard error message is cryptic.
Try to avoid explicit loops if there are suitable primitives available
that can do the job. (Note that some primitives also use
loops, e.g. apply(). They are, however, likely to be written with more
care than you might be willing to give.)
Be especially careful of building up a vector element by element in loops. When necessary, element by element computations should be done by creating an object and then replacing pieces of it rather than having an object grow by gluing together pieces.
Use comments where appropriate but save blocks of text for the online documentation (You are writing online documentation, right?)
Graphics functions should change as little of the graphics state as possible. This allows the user (or function) that calls the graphics function to achieve its own specialization.
Use on.exit() to clean up -- graphical parameter changes, removing
temp files, etc.
Contributed functions are available on statlib.
Check the index on statlib to find out which functions are
available. (See section What is the statlib server? How can I access it?, for info on statlib.
Go to the first, previous, next, last section, table of contents.