[R] Best Programming Practices regarding data frames

[Jan T Kim]

On Wed, Aug 01, 2012 at 05:13:01PM -0500, R. Michael Weylandt wrote:
> On Wed, Aug 1, 2012 at 4:19 PM, Ramiro Barrantes
> <ramiro at precisionbioassay.com> wrote:
> > Hello,
> >
> > I come from using different programming languages (C++, Mathematica, Perl) but have been using R extensively for several months.  I see the data frame as a key piece of the language and wanted to inquire people's experience regarding its use.
> >
> > Say you have a data frame D
> >
> > D <- data.frame(some columns)
> >
> > and you define a function that needs the information from this data frame and is supposed to return a calculation based on some columns of such data frame D.
> >
> > func <- function(d) {}
> > #EFFECT: Does calculation X from some columns of d
> >
> > QUESTION: Would you consider better practice to return the same data.frame but expanded, or would you return a small data frame that consists of the newly computed columns?
> 
> I'd say return what you need, no more no less: and if you want to
> reattach it to the input data, do that at the caller level, but don't
> make it required: orthogonality and minimality and all that jazz....

One thing I consider an element of good practice is: Whatever type of
object you return, make sure it contains meaningful names.

So if you return an extended data frame in the example above, make
sure the new columns have reasonable names. If you return a new data
frame with rows corresponding to the data frame passed in, then it's
definitely part of the job of func to do something like

    rownames(returnedFrame) <- rownames(d);

rather than leaving it to its clients to do that.

This is rather basic but I've seen this being neglected sufficiently
many times to write this post...

Regarding whether to return an extended data frame vs just the computed
columns, I'd tend to go with the latter but if I find that clients of
func all merge the columns from the result into the frame passed in,
then doing that might be a responsibility of func as well.

Best regards, Jan

> As Bert points out, note that returning a data.frame is by no means
> necessary -- they aren't "primitive" data structures like (atomic)
> vectors and lists [we are in a Scheme dialect after all!], but they
> are helpful and well supported. Use them liberally but no more than
> necessary ;-)
> 
> Best,
> Michael
> 
> >
> > Some might say, either way, personal preference.  But after using and seeing other's code for some time, I am thinking that returning the result that consists of ONLY the relevant columns is a better practice as it defines the function as only returning what it was intended to return, and leaves it up to the user of the function to do whatever they were intending to do with it (including naming of the new columns, adding them to a data frame, etc.).  This might be a question for a computer programming theory group, but if anybody has any insight from their experience please share.
> >
> > Thanks in advance,
> >
> > Ramiro
> >
> >         [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > R-help at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-help
> > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> > and provide commented, minimal, self-contained, reproducible code.
> 
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

-- 
 +- Jan T. Kim -------------------------------------------------------+
 |             email: jttkim at gmail.com                                |
 |             WWW:   http://www.jtkim.dreamhosters.com/              |
 *-----=<  hierarchical systems are for files, not for humans  >=-----*