在R中的编码实践：不同风格的优点和缺点是什么？ [英] Coding practice in R : what are the advantages and disadvantages of different styles?

问题描述

最近有关使用require和::的问题是关于在R中编程时使用哪些编程风格的问题，以及它们的优点/缺点。浏览源代码或浏览网络，您会看到很多不同的样式显示。

The recent questions regarding the use of require versus :: raised the question about which programming styles are used when programming in R, and what their advantages/disadvantages are. Browsing through the source code or browsing on the net, you see a lot of different styles displayed.

我的代码的主要趋势：

• 我在索引（和嵌套索引）上玩了很多，有时会导致模糊的代码，但通常比其他解决方案快很多。
  例如： x [x < 5] < - 0 而不是 x <-ifelse（x <5，x，0）

我倾向于嵌套函数，以避免使用临时对象重载内存，我需要清理。特别是对于处理大型数据集的函数，这可能是一个真正的负担。例如： y <-cbind（x，as.numeric（factor（x）））而不是 y < - as.numeric （X）） ; z <-cbind（x，y）

I tend to nest functions to avoid overloading the memory with temporary objects that I need to clean up. Especially with functions manipulating large datasets this can be a real burden. eg : y <- cbind(x,as.numeric(factor(x))) instead of y <- as.numeric(factor(x)) ; z <- cbind(x,y)

我写了很多自定义函数，一次在例如。一个sapply。

I write a lot of custom functions, even if I use the code only once in eg. an sapply. I believe it keeps it more readible without creating objects that can remain lying around.

我不惜一切代价避免循环，因为我认为矢量化是一个很干净的（和更快）

I avoid loops at all costs, as I consider vectorization to be a lot cleaner (and faster)

但是，我注意到对此的意见不同，有些人倾向于从他们所谓的Perl编程方式（甚至是Lisp，所有这些括号在我的代码中飞来飞去，我不会走那么远）。

Yet, I've noticed that opinions on this differ, and some people tend to back away from what they would call my "Perl" way of programming (or even "Lisp", with all those brackets flying around in my code. I wouldn't go that far though).

你认为R中的良好编码实践是什么？

What do you consider good coding practice in R?

你的编程风格是什么，看到它的优点和缺点？

What is your programming style, and how do you see its advantages and disadvantages?

推荐答案

我会做什么取决于为什么我在写代码。如果我为我的研究（白天工作）写一个数据分析脚本，我想要的东西，工作，但是可读和可理解的几个月甚至几年后。我不在乎太多计算时间。向量化 lapply 等。

What I do will depend on why I am writing the code. If I am writing a data analysis script for my research (day job), I want something that works but that is readable and understandable months or even years later. I don't care too much about compute times. Vectorizing with lapply et al. can lead to obfuscation, which I would like to avoid.

在这种情况下，如果 lapply 让我跳过箍来构造适当的匿名函数。我会在第一个项目符号中使用 ifelse（），因为至少在我看来，该呼叫的意图更容易理解比子集+替换版本。有了我的数据分析，我更关心的事情正确的必然与计算时间---有总是周末和晚上，当我不在办公室，当我可以运行大工作。

In such cases, I would use loops for a repetitive process if lapply made me jump through hoops to construct the appropriate anonymous function for example. I would use the ifelse() in your first bullet because, to my mind at least, the intention of that call is easier to comprehend than the subset+replacement version. With my data analysis I am more concerned with getting things correct than necessarily with compute time --- there are always the weekends and nights when I'm not in the office when I can run big jobs.

为您的其他项目符号;我会倾向不内嵌/嵌套电话，除非它们非常微不足道。如果我明确地说明这些步骤，我发现代码更容易阅读，因此不太可能包含错误。

For your other bullets; I would tend not to inline/nest calls unless they were very trivial. If I spell out the steps explicitly, I find the code easier to read and therefore less likely to contain bugs.

我一直写自定义函数，特别是如果我将在循环中重复地调用函数的代码等价物等。这样，我将主数据分析脚本中的代码封装到自己的 .R 文件中，这有助于保持分析的意图与分析的完成方式分离。如果函数是有用的，我有它用于其他项目等。

I write custom functions all the time, especially if I am going to be calling the code equivalent of the function repeatedly in a loop or similar. That way I have encapsulated the code out of the main data analysis script into it's own .R file which helps keep the intention of the analysis separate from how the analysis is done. And if the function is useful I have it for use in other projects etc.

如果我正在写一个包的代码，我可能开始与我的数据相同的态度分析（熟悉）来获得我认识的东西，只有当我想提高计算时间时才进行优化。

If I am writing code for a package, I might start with the same attitude as my data analysis (familiarity) to get something I know works, and only then go for the optimisation if I want to improve compute times.

我试图避免这样做，正在太聪明，当我编码，无论我编码。最后，我从来没有像我认为我有时那么聪明，如果我保持简单，我不会像我想要聪明时那样频繁地落在我的脸上。

The one thing I try to avoid doing, is being too clever when I code, whatever I am coding for. Ultimately I am never as clever as I think I am at times and if I keep things simple, I tend not to fall on my face as often as I might if I were trying to be clever.

这篇关于在R中的编码实践：不同风格的优点和缺点是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！