Aula Prática 1 – Primeiros Passos com o R

Gonçalo Ferraz

Introdução

O R é várias coisas ao mesmo tempo: é um pacote de estatística, é uma linguagem

de programação e é também um ambiente de trabalho. Esse texto aborda alguns
aspetos do ambiente de trabalho e da linguagem de programação que são
fundamentais para a compreensão dos exercícios de estimativa de parâmetros
que você vai fazer no curso. O objetivo não é dar um curso sobre o R, mas sim
fornecer o estritamente necessário para usar a linguagem do R como uma
ferramenta de simulação e análise de dados.
A primeira coisa que você precisa saber sobre o R como um ambiente de
trabalho é que ele tem muitas caras. No essencial, o R pode funcionar apenas com
uma linha de comando—sem interface gráfica—ou seja, sem uma tela animada
onde você clica com o mouse para fazer aparecer listas de opções clicáveis. Na
sua versão mais austera, e com o mesmo poder de computação que qualquer
outra versão, a animação do R é somente o texto que você escreve na linha de
comando e o texto que o R mostra para você em resposta. No entanto, existe uma
variedade de programas que acrescentam uma interface gráfica sobre o R e cada
um dá ao R uma cara diferente. Você pode trabalhar com o interface gráfico (ou
GUI, de Graphical User Interface) que vem com o instalador oficial disponível no
Comprehensive R Archive Network (CRAN), mas também pode buscar um pouco
mais de sofisticação e conveniência prática em GUIs como o RStudio ou o R
Commander. Se você gosta de UNIX, também pode procurar flexibilidade sem
sofisticação gráfica em uma solução como o Emacs Speaks Statistics, ou ESS. A
escolha é sua.

Agora, tal como todas as caras têm olhos, nariz e boca, existem algumas
características recorrentes em qualquer interface do R. O seu ambiente de
trabalho no R terá sempre, no mínimo, duas coisas: uma janela de comando e
uma janela de script. A diferença mais evidente entre as duas é que a janela de
comando sempre tem uma linha de comando com um cursor piscando, enquanto
a janela do script é só um espaço em branco onde você pode escrever. Quando
você escreve alguma coisa na linha de comando e dá ‘enter’, o R dá uma resposta
para você; quando você escreve alguma coisa na janela do script e dá ‘enter’, você

1
pula para a próxima linha. Na janela de comando você está em contato direto
com o R. Já na janela do script, você escreve comandos e outras anotações que
pode ou não enviar mais tarde para o R. Mas note bem: até você decidir enviar
um comando para o R, o conteúdo da janela do script é só seu, ele não é parte de
um diálogo com o programa. Então, metaforicamente, quando você tem alguma
coisa para dizer para o R, escrever essa coisa na janela de comando é como falar
diretamente com o programa. Em contrapartida, escrever na janela do script é
como escrever uma mensagem que você guarda para entregar depois. Cultive o
habito de comunicar diretamente com o programa na janela de comando. Isso vai
permitir você resolver pequenas dúvidas com mais rapidez e produzir scripts
mais limpos. Se quiser recuperar comandos que você deu no R durante uma
sessão de trabalho, é só carregar na ‘setinha pra cima’ e o R vai mostrando para
você todos os comandos anteriores.

Aquilo que você escreve num script, no entanto, têm uma particularidade muito
especial: você pode selecionar qual parte do script o R vai ler. Qual é a vantagem?
É que você vai poder usar duas linguagens ao mesmo tempo, uma que o R
entende e outra, a sua linguagem, que o R não entende, mas que ajuda você a
entender o que escreveu na linguagem dele. Então, quando você escreve na
janela de comando precisa sempre usar a linguagem de programação que o R
entende. Já quando escreve no script (literalmente, um ‘roteiro’) você tem a
liberdade de escrever na linguagem do R ou em qualquer outra linguagem do seu
agrado, que para efeitos práticos podemos chamar de ‘vernáculo’. Como evitar
confusão entre as duas linguagens? Simples, a própria linguagem do R tem um
sinal que ajuda a estabelecer a diferença. Quando você escrever no seu script
algum comentário em vernáculo para ajudar a entender o que você escreveu na
língua do R, é só colocar no início da linha um sinal de jogo da velha ‘#’ e feito! O
R entende que tudo o que está para a frente do sinal é comentário e não código de
R. Comente generosamente os seus scripts, para que no futuro você e outras
pessoas possam entender a intenção e a metodologia do seu código.

Culinária e Programação

Um lugar pensado para preparar grandes quantidades de comida, como uma

cozinha industrial, funciona em torno de três espaços essenciais: a despensa, a
copa e a cozinha. A despensa, serve para guardar ingredientes e produtos finais
da cozinha; a copa, é um espaço para organizar os ingredientes necessários para
cozinhar ou para arrumar o que vem da cozinha; e finalmente, a cozinha é um
espaço para processar os ingredientes, onde se faz o trabalho físico e químico de
transformação da farinha em farofa e do feijão em feijoada.

Se nos permitirmos um paralelismo entre cozinhar e analisar dados, o R é muito

parecido à cozinha. O lugar onde guardamos dados e produtos finais do
trabalho—a despensa do R—é uma pasta do computador. Sempre que pedimos
para o R gravar um resultado ou buscar um arquivo de dados, ele vai olhar para
essa ‘pasta de trabalho’, ou working directory. Por isso, é importante estar
sempre consciente de qual é a pasta na árvore de diretórios do nosso
computador para onde o R está olhando. O R nos permite definir e redefinir essa

2
pasta quantas vezes quisermos através do comando setwd(), que significa ‘set
working directory’. Para saber qual pasta está definida em qualquer momento
como pasta de trabalho, use o comando getwd(). Tudo o que gravamos na pasta
de trabalho permanece gravado, mesmo depois de encerrar o R ou de desligar o
computador.

O espaço do R comparável à copa é a ‘área de trabalho’, também conhecida por

‘workspace’. A área de trabalho é um espaço de uso menos permanente que a
pasta. Salvo instruções em contrário, ao abrir o R você encontrará uma área de
trabalho vazia e quando encerrar o R o conteúdo da área de trabalho é limpo. De
certa forma, o que acontece na área de trabalho fica na área de trabalho. Tal
como na culinária, é importante começar a trabalhar com uma copa (ou área de
trabalho) limpa e limpar a copa quando o serviço estiver terminado. O comando
ls(), de list, mostra o conteúdo da área de trabalho sob a forma de uma lista de
objetos. Você tem pelo menos três opções para colocar objetos dentro da área de
trabalho. A primeira é através de comandos que você pode escrever diretamente
na linha de comando. Por exemplo, o comando:

> x <- 7

cria o objeto de nome ‘x’, contendo o valor numérico 7. Experimente dar o

comando acima seguido do comando ‘ls()’. Como resultado, você deverá ver uma
lista onde o ‘x’ aparece como conteúdo da área de trabalho. Note que o comando
de atribuição de um valor a um objeto tem três partes: o nome do objeto (x), o
símbolo de atribuição (<-), e o valor (7), ou conteúdo do objeto, que neste caso é
um número inteiro, mas poderia ser uma variedade de coisas. Algumas pessoas
usam o símbolo ‘=’ em vez de ‘<-’ para designar a atribuição. Também funciona,
mas não é uma boa ideia porque a igualdade tem um significado matemático
muito preciso, que é diferente da atribuição. Para evitar confusões de notação é
recomendável manter a setinha ‘<-’ como símbolo de atribuição de um valor a
um objeto. Note que o comando ‘x <- 7’ também pode ser dado no sentido oposto,
como ‘7 -> x’ sem qualquer alteração do seu significado. Já o comando ‘7 = x’,
resulta em uma mensagem de erro.

Outra forma de trazer objetos para dentro da área de trabalho é importando, da

pasta de trabalho, tabelas de dados em formato txt ou similar. Dois comandos
que permitem fazer essa importação são read.table() e read.csv(). Sempre que
der esse comando, você precisa atribuir o resultado a um objeto que você nomeia
a seu gosto. A terceira opção para colocar objetos dentro da área de trabalho é
carregar o conteúdo de um arquivo .RData. Por convenção, os arquivos com
terminação ‘RData’ guardam conteúdos de uma área de trabalho. No final de uma
sessão do R, você pode gravar o conteúdo da sua área de trabalho num arquivo
.RData com o comando save.image(). Por exemplo, você pode escrever:

> save.image(file=”Millor.RData”)

Se fizer isso, o R gravará na sua pasta de trabalho um arquivo chamado

‘Millor.RData’ com o conteúdo que estava na área de trabalho imediatamente
antes do comando. Você não vai encontrar arquivos RData com o nome

3
Millor.RData muito frequentemente, mas o nome serve para ilustrar que você
pode chamar o artigo do que você quiser. Na próxima sessão de trabalho do R, se
você quiser trazer para a área de trabalho o conteúdo de Millor.RData, basta
carregar o conteúdo com o comando:

> load(”Millor.RData”)

Como resultado, aparecerão na sua área de trabalho todos os objetos que foram
gravados anteriormente. Note aqui uma diferença de terminologia importante: a
gente ‘grava’ um script e ‘grava’ um arquivo RData com objetos do R na pasta de
trabalho. No entanto, a gente ‘carrega’ (tradução de load, em inglês) o conteúdo
de um arquivo RData para a área de trabalho. Tudo o que a gente traz para a área
de trabalho é ‘carregado’, tudo o que a gente salva na pasta é ‘gravado’. Se em
algum momento você precisar limpar a sua área de trabalho, pode fazê-lo com o
comando:

> rm(list=ls())

que em português significa ‘remova uma lista correspondente à lista de todos os

objetos que estão na área de trabalho’. E feito! Agora você já sabe como por e
como tirar coisas da área de trabalho.

O terceiro e último espaço na analogia do R com a culinária é a cozinha. A

cozinha do R corresponde grosseiramente à memória RAM do computador.
‘RAM’ significa ‘random access memory’ e não vem aqui ao caso explicar a origem
desse nome. O que importa é que existe um espaço físico no computador onde
acontece o processamento de dados ou, por outras palavras, a execução dos
comandos que a gente dá ao R. Esse espaço não tem o mesmo conteúdo que a
área de trabalho e inclusive é possível que durante a execução de comandos o R
crie objetos que nós nunca veremos listados como conteúdo de uma área de
trabalho. Metafóricamente, é como se a nossa esfera de ação como usuários do R
estivesse limitada à copa. Podemos ir buscar ingredientes à despensa e dar
instruções sobre o que deve ser feito com eles na cozinha, mas não podemos
entrar na cozinha. A consciência dessa separação entre a área de trabalho e o
lugar onde acontece o processamento é muito importante para a gente entender
como limpar (ou ‘depurar’) o código de uma função. Vamos voltar ao assunto da
‘depuração’ mais a frente. Para já, lembre só que os três espaços de pasta de
trabalho, área de trabalho e memória RAM do computador correspondem aos
lugares onde vamos, respetivamente, guardar, organizar e processar a
informação relevante para o nosso trabalho com o R.

Comandos são funções?

Vamos levar a analogia da culinária um pouco mais adiante e olhar para o script
de uma função como uma receita de cozinha. Mas primeiro, é bom clarificar a
diferença entre um comando e uma função. Vamos operar com a seguinte
distinção prática: um comando é a uma linha de instruções passadas para o R e
uma função é uma sequência especial de comandos. O que é significa uma ‘linha’?
Uma ‘linha’ é qualquer sequência de instruções em linguagem R que retorna um

4
resultado (diferente de uma mensagem de erro) após o usuário apertar a tecla
‘enter’. Por exemplo, a linha:

>3+

não merece o nome de comando porque se eu apertar a tecla ‘enter’ depois de

digitar a linha o R me diz:

Ou seja, não recebo um resultado, o programa fica à espera que eu digite algo
mais para completar a instrução de somar os valores de dois números. Já a linha:

>3+4

merece o nome de comando porque após apertar ‘enter’ eu vejo o resultado:

[1] 7

E porquê o número ‘1’ entre colchetes? O que aconteceu é que a gente deu um
comando de soma para o R, mas não especificou o que o R deve fazer com o
resultado. Sendo assim, o R executa o comando e apresenta uma descrição visual
do resultado para você na janela de comando. O ‘1’ entre colchetes significa algo
como “Ó aqui ó, esse comando resultou em um vetor numérico de comprimento
igual a 1 cujo primeiro (e único) elemento tem o valor 7. Como você não me disse
o que fazer com o resultado eu vou só jogá-lo aqui na janela de comando, não vou
nem guardar na área de trabalho. Beleza?” (e sim, o R usa sufixos hifenizados no
final das palavras!) Parece que o R ficou um tanto incomodado por a gente não
ter dito o que ele deveria fazer com o resultado. Como contornar a situação? Uma
possibilidade é dar o comando na forma:

> x <- 3 + 4

Aqui a coisa muda de figura. Primeiro, quando apertarmos ‘enter’ após o

comando parece que não aconteceu absolutamente nada. Tudo o que o R nos
mostra é uma linha de comando que não diz nada:

>

Mas o silêncio é bom sinal. Aconteceu tudo o que tinha de acontecer. Dessa vez o
que nós dissemos para o R foi mais do que ‘some 3 com 4’. O comando agora foi
‘crie o objeto de nome ‘x’ e coloque lá dentro o resultado da soma de 3 com 4’. Foi
isso que aconteceu? Claro que sim. Experimente pedir a lista dos objetos que
estão na área de trabalho:

> ls()

e você obterá a resposta:

[1] "x"

5
Isso significa: ‘existe um objeto de nome ‘x’ dentro da sua área de trabalho’.
Agora, se você digitar o nome do objeto:

>x

receberá em resposta a mesma descrição apresentada acima, do 1 entre

colchetes seguido de um 7. É a descrição do que o R guardou dentro do objeto x.

Agora que você já sabe o que é um comando, chegámos ao ponto de perguntar

porque é que uma função do R é mais do que uma simples sequência de
comandos. O que é que há de especial na sequência de comandos que constitui
uma função? A resposta curta é que a função é uma sequência de comandos
genérica, que aplica os mesmos comandos a uma variedade de objetos,
produzindo resultados diferentes consoante os objetos sobre os quais ela é
aplicada. Exatamente como uma receita de cozinha! Uma salada de tomate com
cebola é uma salada de tomate com cebola em toda a parte, mas dependendo da
qualidade do tomate ou da espessura das rodelas de cebola as experiências de
comer a salada podem variar como do dia para a noite. Vamos seguir com o
exemplo da soma para ver primeiro o que poderia ser uma simples sequência de
comandos e depois, para apresentar o primeiro exemplo de uma função, o que
seria uma sequência de comandos especial.

Limpe novamente a sua área de trabalho e vamos começar a trabalhar na janela

do script, para guardar um registro do que vai acontecer em seguida. Abra uma
janela de script e escreva lá dentro:

## Exemplo de uma sequencia simples de comandos

s <- 3 + 4
qs <- s*s

Grave o seu script (na pasta de trabalho) e em seguida execute os comandos que
você escreveu nele. A combinação de teclas que faz executar comandos do script
varia de GUI para GUI, você precisa procurar o que se aplica ao seu caso,
geralmente ctrl-enter ou espaço-enter. Lembre só que existem combinações de
teclas para executar só um comando de cada vez ou um conjunto de comandos
selecionados previamente. Após executar estes comandos, veja os objetos que
estão na sua área de trabalho:

> ls()
[1] "s" "qs"

Como era de esperar, o conteúdo da área de trabalho são os dois objetos que
você acabou de criar: s, contendo a soma de 3 com 4 e qs, contendo o quadrado
dessa soma. Muitas pessoas usam o R somente como você acabou de usar. Para
qualquer tarefa executável no R—mais ou menos complicada que obter o
quadrado da soma de dois números—vai existir uma sequência de comandos
que resolve o problema. Porque não ficar só por aí? Porque você pode tirar muito
mais partido do mesmo trabalho de programação se organizar os comandos de
forma a que eles possam ser usados de uma forma genérica, repetidamente, para
execuções diferentes de tarefas semelhantes à tarefa específica que você quer

6
executar. Mais concretamente, no exemplo acima você calculou o quadrado da
soma de 3 com 4, mas com o mesmo esforço você poderia escrever uma função
que retorna o quadrado da soma de quaisquer dois números. Vamos voltar à
janela do script para fazer isso mesmo.

## Função qsoma, que retorna o quadrado da soma de dois numeros

qsoma <- function(a,b) {
s <- a + b ## Somar os argumentos
qs <- s*s ## Obter o quadrado da soma
return(qs) ## Especificar o resultado final
}

Antes de executar qualquer comando, vamos dar uma olhada no código para ver
o que há de especial nessa sequência. Aparecem aqui quatro elementos que se
repetem em todas as funções:
1) Primeiro, damos um nome à função atribuindo ao objeto ‘qsoma’ o valor
de função. A atribuição é expressada pelo pedaço de código ‘qsoma <-
function’. Na analogia culinária, essa parte do código indica que a palavra à
esquerda da seta de atribuição representa uma receita de cozinha.
2) O segundo elemento é a especificação dos argumentos da função,
‘function(a,b)’, ou seja, dos valores de entrada (ou ingredientes da receita)
que serão transformados para dar origem a um produto final. Neste caso,
os argumentos da função são ‘a’ e ‘b’ , mas eles poderiam ser qualquer
lista de objetos.
3) O terceiro elemento, que aparece nas várias linhas escritas entre chaves, é
o código da função propriamente dito. O código obviamente varia entre
funções, assim como os detalhes da preparação de um prato variam entre
receitas. Mas esse código sempre aparece entre chaves e sempre indica o
que deve ser feito como os argumentos identificados entre parentes na
primeira linha.
4) Finalmente, o último elemento essencial é a especificação d o resultado
final que a função vai retornar para o usuário. Essa especificação é feita
pelo código ‘return(qs)’. Neste caso, a função retorna o valor de ‘qs’ mas o
valor retornado pode ser qualquer coisa, ou lista de coisas, produzida nos
comandos anteriores, dentro das chaves.

O pulo do gato na ideia de escrever sequências de comandos sob a forma de uma

função é montar uma espécie de máquina que produz um resultado final com
base em uma matéria prima tantas vezes quantas for necessário. Imagine que a
sua função é uma máquina de fazer linguiça (Figura 1).

7
Figura 1. Uma função do R é como uma máquina de fazer linguiça. Os argumentos são a matéria prima e o
resultado final é a linguiça. A função é como uma máquina que pode ser usada repetidamente com matérias
primas do mesmo tipo mas variáveis. No exemplo da figura, a máquina só funciona se usarmos um porco,
mas o porco pode ser cinza ou rosa, baixo ou alto, gordo ou magro. Como na analogia com a receita de
cozinha, a função pode ser usada muitas vezes para executar os mesmos comandos com argumentos e com
resultados variáveis, mas sempre do mesmo tipo.

Agora vamos testar a função e você vai já ver outra diferença importante entre
uma função e uma lista de comandos. É a seguinte: para testar uma lista de
comandos gravados no seu script, tudo o que você precisa fazer é colocar o
cursor na linha correspondente a cada comando e ir executando. Simples assim.
Quando você está em dúvida sobre o funcionamento dos comandos é bom ir
checando quais foram os objetos que foram aparecendo na área de trabalho e o
seu conteúdo. Mas o processo de testar os comandos para ver se eles estão
cumprindo corretamente a sua intenção é tão simples como executar cada
comando e ir olhando os resultados. Com as funções é diferente, porque a
sequência de comandos ‘especial’ que você está usando vem envolta numa
‘casca’. Função tem casca?? Repare bem. Toda a função vem na forma:

nome <- function(argumentos) {

... ## Sequencia de commandos que produzem resultado
## com base nos argumentos
return(resultado)
}

O que significa que a parte:

nome <- function(argumentos) { ... }

pode ser vista como um invólucro, ou uma casca, da sequência de comandos. O

motivo que impede você de testar uma função simplesmente executando os
comandos do código um por um é que o comando da casca se sobrepõe a todos
os outros comandos. O que a casca diz para o R, em português, é: “os comandos
que vão aparecer em seguida, dentro da chave, não são para executar. Eles são
para guardar como uma receita de bolo. Esses comandos formam a função de
nome <nome>, que opera sobre os argumentos <argumentos>”. Ou seja, se você
mandar executar o comando da casca, o R não executa os comandos de dentro da
chave. Ele simplesmente guarda esses comandos dentro do objeto ‘nome’.

8
Há duas maneiras complementares de testar o código de uma função. A primeira
é a que se designa em inglês como ‘debugging’ ou depuração. A depuração de
código é o nível de teste mais detalhado e deve ser o primeiro a ser usado. Ela
consiste em testar os comandos que estão dentro da casca da função. Para fazer
isso você precisa colocar na área de trabalho objetos com os mesmos nomes que
os argumentos da função (no caso ‘a’ e ‘b’). Uma vez criados esses objetos, você
pula para dentro da chave sem dar o comando da casca e testa os comandos um
por um, checando após cada comando se obteve ou não obteve o resultado
pretendido.

A segunda maneira de testar o código de uma função é executando a função. Mas

para isso você precisa carregar a função na sua área de trabalho. Mais uma vez,
note a terminologia: uma coisa é ‘carregar’ a função e outra coisa é ‘executar’.
Para carregar, você seleciona todo o código da função que está no script,
incluindo a casca, e executa esse código. Ai?! Como é que é? Carrega executando?
Precisamente! É que uma coisa é executar os comandos de criação da função, que
permitem você carregar a função na área de trabalho. Outra coisa bem diferente
é executar a função propriamente dita. Então vamos voltar ao exemplo prático.
Limpe novamente a sua área de trabalho e se certifique que ela está vazia. Em
seguida, selecione o código da função ‘qsoma’ e execute esse código. Aconteceu
alguma coisa? O que deve ter acontecido é aparecer o código da função na sua
janela de comando, como se você tivesse dados os comandos de criação da
função na janela de comando. Agora, para verificar se realmente carregou a
função na sua área de trabalho, dê o comando:

> ls()

O resultado deveria ser:

[1] "qsoma"

indicando que o único objeto na sua área de trabalho é a função soma. Agora
estamos prontos para testar a execução da função. Vamos ver se ela calcula
corretamente o quadrado da soma de 2 com 3, que deveria ser 25. Para isso,
digite o comando:

> qsoma(a=2,b=3)

Após apertar ‘enter’ você deveria ver o resultado:

[1] 25

que é a resposta correta. Nesse primeiro teste de execução, listamos os

argumentos no formato mais longo, especificando exatamente ‘a=2’ e
‘b=3’. Mas como o R sabe a ordem dos argumentos de cada função, podemos
também usar a forma mais compacta que seria apenas: ‘qsoma(2,3)’.

Agora vamos olhar um detalhe que vai deixar mais claro porque é que tem
atividades do R que acontecem fora do alcance da área de trabalho, na ‘cozinha’
do computador. Volte à janela de comando e peça novamente o conteúdo da área

9
de trabalho. Tem lá os objetos s e qs que apareceram durante o depuramento do
código? Nada. Eles não estão lá! Porquê? Porque eles foram criados na ‘cozinha’,
fora do seu alcance, sem a necessidade de colocar objetos dentro da sua área de
trabalho. Para entender o alcance dessa praticidade, pense que, sempre que você
coloca uma sequência de comandos dentro de uma chave, você está mandando o
computador executar uma tarefa na cozinha, fora do alcance da sua área de
trabalho. A vantagem é rapidez e facilidade de organização, que não são pouca
coisa.

Porque há comandos do R que se dão com um parênteses vazio?

Na última seção, você experimentou executar uma função através de um

comando composto pelo nome da função e seus argumentos. Agora deveria ficar
mais claro porque é que outros comandos se escrevem com parênteses e às
vezes com parênteses vazios na frente. A regra geral é que se você escrever um
nome de um objeto na linha de comando e der ‘enter’, o R vai mostrar para você
o conteúdo desse objeto. Mas se esse objeto for uma função e você quiser mandar
executar a função, você precisa colocar na frente do nome da função um
parênteses com a especificação dos argumentos lá dentro. O que acontece é que
há muitas funções que fazem o seu serviço sem necessitar da especificação de
argumentos, como a função ls, por exemplo. Nesses casos, o que a gente faz é dar
o comando com o nome da função seguido de um parênteses vazio. Isso significa
que o R tem uma reserva de funções que estão guardadas no computador mas
não aparecem na sua área de trabalho. A ideia é que sua área de trabalho só terá
coisas que você criou (i.e. que você quis trazer para a copa). Mas na verdade,
todas as palavras que você encontra seguidas de parênteses em comandos do R.
Se você escrever essas palavras sem o parênteses e der ‘enter’ na linha de
comando, o R mostrará o código da respetiva função.

Muitas classes de objetos

Você deve ter notado que até aqui falámos de ‘tipos’ de argumentos e ‘tipos’ de
resultados de uma forma um pouco ambígua. Vamos clarificar o que são esses
‘tipos’. Tudo o que você encontra dentro da sua área de trabalho são objetos. E o
interessante do R é que você pode usar uma enorme variedade de objetos. Para
saber que tipo de objeto você tem em mãos você deve usar o comando class, que
busca a classe do objeto em causa. Por exemplo, o objeto qsoma que está na sua
área de trabalho é da classe função, portanto, se você der o comando:

> class(qsoma)

a resposta será:

[1] "function"

10
Para além da classe função existem muitas outras, pelo menos 24 listadas na
página do CRAN1. Mas também mais, porque um usuário, em caso de
necessidade, pode criar a sua própria classe de objeto. Citando só alguns
exemplos: existem objetos numéricos da classe integer, que são números
inteiros; existem objetos numéricos da classe double, que são números reais;
existem objetos que contém matrizes, da classe matrix; e existem objetos de
texto, da classe character. É importante estar sempre ciente da classe dos objetos
que você usa porque as operações executadas pelas funções só são válidas com
determinados tipos de objeto. Por exemplo, você não pode somar duas palavras e
não deve tratar matrizes como se elas fossem escalares. Muitos erros que
aparecem durante o processo de depuração se devem a confusões de classe de
objeto, em que um objeto da classe errada é passado para uma função como um
argumento que deveria ser de outra classe. À medida que for se familiarizando
com o R você vai se apercebendo da variedade e utilidade das múltiplas classes
de objeto.

Cuidados Básicos de Rotina

Para encerrar este texto introdutório vamos combinar algumas regras básicas de
‘culinária’ que a gente deve usar no R e que vão facilitar o seu trabalho e o
trabalho dos monitores que vão corrigir o seu código. Pense nestas regras como
medidas básicas de higiene, como limpar a bancada, não pegar nas facas pela
lamina, ou separar o lixo orgânico do lixo reciclável. São três medidas principais
que você precisa tomar:

1) Comente generosamente o código da sua função. Inclusive, existem

vantagens em escrever comentários antes de começar a escrever código,
porque eles ajudam você a planejar os passos que você precisa codificar.
A parte mais desafiante e interessante da programação é a criação de
sequências de comandos que resolvem um problema com eficácia e
clareza. Esse desafio é algo que se resolve em grande parte através de um
plano verbal (ou algoritmo verbal) da sua função. Depois de ter o
algoritmo em mãos você começa a codificar e aí entra o seu conhecimento
sobre a linguagem. O essencial, no entanto, é ter um bom plano de
trabalho e esse plano de trabalho deveria ser compreensível pela leitura
dos comentários que você deve incluir no seu script.
2) Não grave informação supérflua no script. Há muitos detalhes do
processo de redação de código que devem acontecer diretamente na linha
de comando. Da mesma forma, na cozinha, nem tudo o que eu faço para
cozinhar uma farofa tem de aparecer na receita da farofa. A receita (leia-
se ‘o código da função’) deve ser enxuta e informativa. Se você em algum
momento, por exemplo, tem dúvidas sobre quais são os objetos que estão
na sua área de trabalho, o comando ‘ls()’ não deve ficar gravado no seu
script. Tenha cuidado, porque a acumulação de comandos acessórios no

1 https://cran.r-project.org/doc/manuals/r-release/R-lang.html#Objects

11
 script confunde os monitores e confundirá você no futuro, quando você
precisar usar a código.
3) Finalmente, tome cuidado com a indentação das chaves. Cada vez que
você abre chave num script você está mandando o computador operar em
uma outra esfera, em que os objetos criados não vão mais aparecer na
área de trabalho. Na hora de depurar código é absolutamente essencial
que você tenha facilidade em se localizar relativamente às chaves. Para
isso, usamos a convenção de mudar para a próxima linha após a abertura
de uma chave e começar a escrever quatro espaços mais à frente do que o
início da linha em que a chave foi aberta. Na hora de fechar a chave,
escrevemos a chave numa linha só para ela e alinhamos a dita com o início
da linha onde a chave abriu.

Diferentes pessoas têm diferentes estilos de edição de código, mas para o nosso
trabalho neste curso, tudo será mais fácil se você atender cuidadosamente a
esses três cuidados básicos de rotina.

Bom trabalho!

12