8 советов по стилю кодирования для программирования на R
R - это язык программирования с открытым исходным кодом, который широко используется в качестве статистического программного обеспечения и инструмента анализа данных. R обычно поставляется с интерфейсом командной строки. R доступен на широко используемых платформах, таких как Windows, Linux и macOS. Кроме того, язык программирования R - это новейший передовой инструмент. Программная инженерия - это не только изучение языка и создание программного обеспечения. Ожидается, что вы, как инженер-программист или разработчик программного обеспечения, напишете хорошее программное обеспечение . О хорошем программном обеспечении можно судить, прочитав какой-нибудь фрагмент кода, написанный в проекте.
Если код легко понять и легко изменить, то это определенно хорошее программное обеспечение, и разработчики любят над этим работать. Для начинающего программиста на языке R будет хорошей идеей освоить передовой опыт программирования и начать его использовать. У Google и R-гуру Хэдли Уикхема есть отличные советы по руководству по стилю кодирования R. Список содержит то, что делать и чего не делать при программировании на R. Итак, в этой статье мы обсудим шесть советов по стилю кодирования, которые помогут вам стать лучше программистом на языке R.
1. Комментирование
Часто разработчики используют комментарии, чтобы указать цель строки в своем коде. Это правда, что комментарии действительно помогают объяснить код, что он делает, но они также требуют более тщательного обслуживания кода. Иногда это очень важно, например ... если вы имеете дело со сторонним API, где вам нужно объяснить какое-то поведение, можно использовать комментарии для объяснения кода, но не писать комментарии там, где это не нужно. Поэтому в программировании на R всегда начинайте комментировать строку с символа комментария # и одного пробела . Хэдли Уикхэм предлагает использовать оставшиеся закомментированные строки с помощью - и =, чтобы разбить файл на легко читаемые фрагменты. Пожалуйста, обратитесь к приведенному ниже фрагменту кода:
р
# Read table ----------------------------------# Read table ================================== |
2. Переуступка
R имеет необычный оператор присваивания «<-» вместо знака «=». Поэтому рекомендуется использовать знак «<-» вместо знака «=» . Пожалуйста, обратитесь к приведенному ниже фрагменту кода:
Хорошая практика:
р
# Good Practicex <- 10 |
Плохая практика:
р
# Bad Practicex = 10 |
3. Имена файлов
Имя файла должно быть значимым и заканчиваться на '.R' . Пожалуйста, обратитесь к приведенному ниже фрагменту кода:
Хорошая практика:
R
# Good Practicefit-models.Rlinear-regression.R |
Плохая практика:
р
# Bad Practicemodels.Rstuff.R |
Если файлы необходимо запускать по порядку, поставьте перед ними номера, как показано ниже:
р
0-fit-models.R1-linear-regression.R2-neural-network.R |
4. Имена объектов
“There are only two hard things in Computer Science: cache invalidation and naming things.”
— Phil Karlton
Имена переменных и функций должны быть в нижнем регистре . Используйте знак подчеркивания «_» для разделения слов в имени. Как правило, имена переменных должны быть существительными, а имена функций - глаголами. Пожалуйста, обратитесь к приведенному ниже фрагменту кода:
Хорошая практика:
р
# Good Practicenumber_of_studentsget_price |
Плохая практика:
р
# Bad PracticeGetPricegetprice |
5. Интервал
Поместите пробелы вокруг всех инфиксных операторов ( =, +, -, <- и т . Д.). То же правило реализуется при использовании = в вызовах функций. Всегда ставьте пробел после запятой и никогда раньше. Пожалуйста, обратитесь к приведенному ниже фрагменту кода:
Хорошая практика:
р
# Good Practiceperimeter_of_rectangle = 2 (length + width), na.rm = TRUE ) |
Плохая практика:
р
# Bad Practiceperimeter_of_rectangle= 2 (length+width),na.rm= TRUE ) |
Есть небольшое исключение из этого правила, например, в случае, если :, :: и ::: не нужны пробелы вокруг них. Пожалуйста, обратитесь к приведенному ниже фрагменту кода:
Хорошая практика:
р
# Good Practicex <- 1:20value::real |
Плохая практика:
р
# Bad Practicex <- 1 : 20value :: real |
Перед левыми скобками ставьте пробел, за исключением вызова функции. Пожалуйста, обратитесь к приведенному ниже фрагменту кода:
Хорошая практика:
р
# Good Practiceif (yes) do (x)run (x, y) |
Плохая практика:
р
# Bad Practiceif (yes) do (x)run (x, y) |
Не помещайте пробелы вокруг кода в круглые или квадратные скобки, кроме запятой. Пожалуйста, обратитесь к приведенному ниже фрагменту кода:
Хорошая практика:
р
# Good Practicestudent[1, ] |
Плохая практика:
р
# Bad Practice # Needs a space after the commastudent[1,] # Put space after comma not beforestudent[1 ,] |
6. Фигурные скобки
Открывающая фигурная скобка никогда не должна выходить на отдельную строку, и за ней всегда должна следовать новая строка. Закрывающая фигурная скобка всегда должна располагаться на отдельной строке, если за ней не следует else. Всегда заключайте код в фигурные скобки. Пожалуйста, обратитесь к приведенному ниже фрагменту кода:
Хорошая практика:
р
# Good Practiceif (x > 0 && foo) { cat ( "X is positive" )} if (x == 0) { log (a)} else { a ^ x} |
Плохая практика:
р
# Bad Practice if (x > 0 && foo)cat ( "X is positive" ) if (x == 0) { log (a)}else { a ^ x} |
Можно писать очень короткие операторы в одной строке, как показано ниже:
р
# Good Practiceif (x > 0 && foo) cat ( "X is positive" ) |
7. Длина линии
Попробуйте ограничить код до 80 символов в строке. Это удобно разместить на печатной странице с помощью шрифта разумного размера.
8. Отступ
Делая отступ в коде, используйте два пробела . Никогда не используйте табуляции и не смешивайте табуляции и пробелы. Единственное исключение - если определение функции занимает несколько строк. В этом случае сделайте отступ во второй строке до начала определения. Пожалуйста, обратитесь к приведенному ниже фрагменту кода:
Хорошая практика:
р
# Good Practicefunction_name <- function (a = "a long argument" , b = "another argument" , c = "another long argument" ) { # As usual code is indented by two spaces} |