Простое, но поддерживаемое повторное использование кода

#r

#r

Вопрос:

Допустим, у меня есть крошечная (3-4 строки) функция, которую я часто использую.

Поскольку он такой маленький, его легко скопировать и вставить в каждый исходный файл, который в нем нуждается, но копирование-вставка не является поддерживаемой формой повторного использования кода.

Вместо этого я хотел бы поместить эту функцию в ее собственный файл и каким-то образом импортировать ее из других исходных файлов по мере необходимости.

Пока я нашел только два способа сделать это:

  1. создайте пакет R для моей функции, установите его в мою библиотеку R и запустите клиентский код, например library(myfunction) ;
  2. пусть клиентский код выполняется source("path/to/my/function.R") .

(Первый вариант кажется мне очень сложным для простого варианта использования, который я имею в виду. На данный момент я не собираюсь отправлять эту функцию в CRAN или даже делиться ею с кем-либо еще. Все, что я хочу сделать, это использовать его из моих одноразовых R-скриптов.)

Есть ли какой-то другой способ сделать это?


Например, в Python я могу поместить крошечную функцию в некоторый файл:

 # hello.py

def hello():
    print "hello, world"
  

… и поместите этот файл в каталог в моей PYTHONPATH переменной. Затем, чтобы использовать функцию в любом скрипте some_script.py , все, что мне нужно сделать, это

 # some_script.py

import hello

hello.hello()
# hello, world
  

Я в основном ищу ближайший эквивалент этого в R.

Ответ №1:

Вы можете добавить его в свой ~/.Rprofile и просто определить его там.

Плюс: одно местоположение, всегда исходное, может даже управлять через if (interactive()) etc pp. Меньше работы, чем в пакете.

Минус: глобальная видимость.

Комментарии:

1. Или поместите это в свой Rprofile: import <- function(func_file)source(paste0("path/to/my/", func_file))

Ответ №2:

Я думаю, вы можете быть приятно удивлены тем, насколько просто может быть создать пакет для вашего личного использования. Имейте в виду, что вы можете собрать и установить пакет, который даже отдаленно не удовлетворяет требованиям CRAN.

Просто из любопытства я создал пакет, который работает на моей машине, и сделал это менее чем за пять минут. Он имеет ровно одну функцию.

Вот что я сделал.

В R я запустил

 package.skeleton(name = "OneFunc", path = [package_path])
  

Затем я создал файл .R в [package_path]/R и поместил в него определение моей функции. Чтобы быть точным, вот именно то, что содержится в моем файле.

 my_useful_function <- function(x){
  x^2
}
  

Затем я вернулся к R и запустил

 devtools::install_local([package_path])
library(OneFunc)
my_useful_function(3)
  

который вернул значение 9 .

Таким образом, вы можете быстро создать грязный пакет, который позволяет очень легко загружать одну (или несколько) функций, не выполняя всю работу по созданию пакета, подходящего для CRAN.

Преимущества:

  1. Ясность — у вас нет недостатка в ответе Дирка, потому что вам все равно нужно писать library(OneFunc) в своем коде. Так что, по крайней мере, есть некоторые признаки того, что вы что-то сделали.
  2. Это едва ли больше работы source , и вам не нужно вызывать каталог каждый раз (только при переустановке пакета)
  3. Это легко расширит загрузку не только одной функции. Все, что вам нужно сделать, чтобы добавить еще одну функцию OneFunc , это поместить файл в подкаталог R и переустановить пакет.

Недостатки:

  1. Нет документации. И что еще хуже, поскольку вы загрузили пакет через library него, другие будут выглядеть так, как будто там должна быть документация. Честно говоря, я бы предпочел это функции, появляющейся из ниоткуда, потому что она у вас /.Rprofile есть, но это вопрос предпочтений.

Но если серьезно, мне потребовалось в три раза больше времени, чтобы написать этот ответ, чем на создание этого пакета bare bones. Я думаю, вам стоит потратить на это время.

Комментарии:

1. Спасибо! Но, смотрите мою ПРАВКУ.

2. Я несколько удивлен, что он работал для меня без указания code_files , но тогда не для вас. Глядя на документацию, кажется, что в моей среде должно было быть что-то, что было подключено и предотвратило ошибку. Извините, я не понял этого раньше.

3. Недостаток легко устраняется. Нетрудно написать краткую документацию (и в любом случае хорошую практику кодирования).