Simbolo Colorido

Todos nós, sereLepes, já passamos ou estamos passando pelo processo inicial de aprender uma nova linguagem ou um novo programa e durante esse momento nos deparamos com alguns dilemas: faço um código rápido de fazer porém, repetitivo e de difícil manutenção ou faço um código mais robusto que me demande mais tempo porém, com uma manutenção mais fácil. Faço um código rápido e que só eu consigo entender e depois traduzo-o ou faço desde o início um código comentado e legível por terceiros mas que me demandará mais tempo.

Ainda, quem que nunca precisou consultar ou “rodar” novamente um código feito no passado por uma pessoa que não é possível mais consultá-la e ficou horas tentando decifrar este código? Ou até mesmo um código feito por você mesmo no passado?

Figura 1 - Como escrever um bom código

Essas dificuldades podem ser minimizadas com a construção de um bom código e este guia foi criado com o intuito de reduzir esses problemas e padronizar os códigos do Lepes, para que os atuais e futuros sereLepes possam dar continuidade ao trabalho desenvolvido no Lepes.

Assim, este guia será dividido em três partes. A primeira definindo o que é um bom código. A segunda e a terceira são referentes a boas práticas em programação aplicadas ao software RStudio1 e Stata2.

Um bom código

Figura 2 - Qualidade de um código

O que é um bom código? Um bom código é aquele que gera resultados corretos e é facilmente lido, replicado e adaptado por terceiros. Ou seja, para construir um bom código é preciso aplicar técnicas simples visando a fácil compreensão e que esta revele o objetivo do código (Bjarkefur et al. 2020)(Martin 2009).

Características de um bom código: correto, fácil de ler, replicável, útil e compreensível por terceiros.

Por que devo desenvolver um bom código? Primeiro se pergunte: “alguma vez um código ruim já lhe atrasou consideravelmente?” A produtividade de um projeto de pesquisa está diretamente ligada a organização do projeto e a qualidade dos códigos utilizados neste. Por isso, desenvolver um código em que seja possível entender o que está sendo feito e o porque é fundamental. Caso contrário, informações são perdidas e erros são passados a frente e para corrigi-los você cairá na pergunta inicial “alguma vez um código ruim já lhe atrasou consideravelmente?”

Adote o pensamento que outras pessoas no futuro vão precisar do seu código e você não estará presente para ajudá-las. Então, se pergunte se o seu código é compreensível?

Sempre peça para alguém revisar o seu código: Durante a construção do seu código ou assim que terminá-lo, é de suma importância que uma outra pessoa veja o que foi feito. Primeiro pois, erros são humanos e frequentes e, também, pela garantia que o código esteja compreensível por terceiros.

Inclusive você, sereLepe, crie o costume também de revisar os códigos dos colegas. Essa é uma excelente prática para melhorar sua habilidade com a linguagem ou programa utilizado.

Boas práticas aplicada ao RStudio

Um bom código perpassa por duas áreas: estilo e sintaxe. O estilo corresponde aos elementos não funcionais como, por exemplo, espaçamento, indentação e nomeação. Já a sintaxe corresponde a linguagem do seu código e como ele é legível. Essas áreas aplicadas ao RStudio são abordadas nessa sessão.

Estilo

Estilo de programação é uma forma de descrever o esforço que deve ser feito para tornar seu código fácil de ler e entender. Uma boa organização do código e o uso de comentários podem ajudar o leitor a entender o que o programa faz e por quê.

Tamanho da linha

O tamanho da linha não afeta o resultado do seu código mas pode torná-lo muito mais legível. Ao ler um texto, é sempre incômodo ter que ficar rolando a página de um lado para o outro. Esse sentimento é o mesmo ao ler um script. Tenha em mente que o seu script será lido em outros computadores, que possuem tamanho de tela diferentes e janelas do RStudio em tamanhos diferentes. Portanto, adote a regra de bolso de 80 caracteres (em torno) por linha.

Comentários

Comentários não mudam o resultado do seu programa e eles podem tornar seu código muito mais compreensível para terceiros. Portanto, comente bastante! Porém, lembre que quanto mais simples for o seu código, menos necessidade de comentários você terá.

Tenha em mente que seu código precisa deixar claro o que você está fazendo, o porque está fazendo e com base em que está fazendo. O que você está fazendo pode ficar mais explícito com pequenos comentários sobre o que está sendo feito em cada função ou linha. Porque está fazendo e com base em que está fazendo envolve decisões tomadas ao longo do projeto que precisam ser relatadas e uma das formas de relatar essa decisão é através de comentários3. Não se acanhe em deixar bem explicado o porquê tal parte do código está sendo implementada, principalmente as partes que excluem observações e variáveis.

Assim, comece o seu programa com um comentário no início indicando o objetivo do código e o produto dele gerado (caso haja algum). Indique também a que projeto esse programa pertence, data de criação do programa, última data de modificação e qual o autor(a) ou autores(as). O modelo a ser seguido está apresentado no pedaço de script abaixo. Note que no modelo abaixo existe uma parte de “produto gerado,” este indica o que o programa está gerando. Por exemplo, um script que faz a limpeza de uma base de dados bruta está gerando uma base de dados finais, ou então um programa que faz análise descritiva de uma base de dados está gerando gráficos e tabelas referentes a análise descritiva.

#----------------------------------------------------------------------------------------------
# PROJETO: Nome do projeto
#
# OBJETIVO: Objetivo do script Lorem ipsum dolor sit amet consectetur adipiscing, 
# elit semper turpis vivamus ultrices molestie volutpat, orci mauris nec pulvinar parturient. 
# Quis torquent sem aptent posuere quam quisque ex tempor
#
# PRODUTO: Produto gerado pelo script
#
# AUTOR: SereLepe da Silva
#
# DATA DE CRIACAO: mm/aaaa
#
# DATA DE MODIFICACAO: mm/aaaa
#
# MODIFICACOES: falar o que foi feito na modificacao. Foi acrescentado Lorem ipsum dolor sit # # amet consectetur adipiscing. A parte tal foi modificada disso para isso.
#----------------------------------------------------------------------------------------------

Para comentar localmente o que está fazendo seja bem sucinto e utilize somente uma linha. Ainda, para justificar algum código faça-o de forma clara e sucinta, conforme o padrão abaixo.

#----Estruturando a base-----------------------------------------------------------------------

# Colocando as observacoes em caixa alta
## Colocando em caixa alta pois Lorem ipsum dolor sit amet consectetur adipiscing, 
## elit semper turpis vivamus ultrices molestie volutpat (justificando)
for(coluna in 1:ncol(base_dados) ){
  
  try( for(linha in 1:nrow(base_dados) ){ 
    base_dados[linha,coluna] <- toupper(base_dados[linha, coluna]) 
  }
  )
  
}
rm(linha, coluna)

Caso queria explicar algum argumento do código (essa é uma prática excelente) faça conforme exemplificado abaixo, logo após o argumento. Além disso, tente manter esses comentários alinhados. Visualmente fica muito melhor.

# Corrigindo acentuacao e caracteres especiais
for(coluna in 1:ncol(base_dados) ){
  
  try( for(linha in 1:nrow(base_dados) ){
    
    #corrigindo acentos e cedilha
    base_dados[linha,coluna] <- stri_trans_general(base_dados[linha,coluna], "Latin-ASCII")
    
    #corrigindo caracteres especiais
    base_dados[linha,coluna] <- gsub("-" ,"" , base_dados[linha,coluna])
    base_dados[linha,coluna] <- gsub("\\." ,"" , base_dados[linha,coluna]) #\\. = . (ponto)
    base_dados[linha,coluna] <- gsub("ª" ,"" , base_dados[linha,coluna])
    base_dados[linha,coluna] <- gsub("º" ,"" , base_dados[linha,coluna])
  }
  )
  
}
rm(linha, coluna)

Assim sendo, comente sempre que achar necessário (COMENTE MUITO!) e nunca (NUNCA!) utilize acentos ortográficos nos comentários.

Indentação

No RStudio, adicionar espaços não altera a execução do código e utilizá-los torna o seu programa muito mais legível e visualmente agradável. Note a diferença entre os códigos nos códigos abaixo, como um é visualmente mais agradável que o outro.

# BOM

# Corrigindo codigo_inep

base_dados = base_dados %>%
  mutate( codigo_inep = case_when(
    
    codigo_inep == 19522     ~ 35585497,
    codigo_inep == 92873     ~ 35092873,
    codigo_inep == 35052986  ~ 35051986,
    codigo_inep == 35087105  ~ 35238053,
    codigo_inep == 35271732  ~ 35271792,
    is.na(codigo_inep)       ~ 35051901,
    TRUE                     ~ as.numeric(codigo_inep)
  )
  )

# RUIM

# Corrigindo codigo_inep

base_dados=base_dados%>%
  mutate(codigo_inep=case_when(
    codigo_inep==19522~35585497,
    codigo_inep==92873~35092873,
    codigo_inep==35052986~35051986,
    codigo_inep==35087105~35238053,
    codigo_inep==35271732~35271792,
    is.na(codigo_inep)~35051901,
    TRUE~as.numeric(codigo_inep)
  )
  )

Espaçamento

Colocar espaçamento entre operadores4 torna o seu script muito mais legível e visualmente agradável. Observe como o exemplo ruim acima está muito mais difícil de se entender. Além de espaçamento ao redor de operadores, coloque espaços entre argumentos de uma função e entre os parênteses de uma função.

Sintaxe

A sintaxe de um código está associada à linguagem do programa utilizado e suas características. Em relação ao RStudio, aqui são abordados os seguintes assuntos sobre sintaxe com o objetivo de tornar seu código legível: carregamento de pacotes, nomeação de objetos e funçoes, loop e organização do script.

Carregamento de pacotes

Programar em R em geral requer uso de funções pertencentes a pacotes específicos e muitas vezes utilizamos mais de um pacote em um script. Assim, a melhor forma de chamar esses pacotes é no início do script.

Ainda, como um script pode ser “rodado” no futuro e por outras pessoas, é importante guardar a informação da versão do pacote utilizado, para que resultados possam ser reproduzidos por todos e a qualquer momento. Para fazer isso você precisará rodar o seu script em alguns passos:

  1. Rodando um comando que veja a versão dos pacotes utilizados;

  2. Preenchendo essa informação em comentários ao lado de cada pacote conforme sua respectiva versão;

  3. Excluindo esse comando/linha ou deixando ela comentada;

  4. Chamando o pacote e seguindo com o script.

A versão final do seu script deve ficar conforme está no chunk abaixo.

#----Pacotes utilizados-------------------------------------------------------------------------

pacotes <- c( "readxl"  ,  # Versao 1.3.1
              "dplyr"   ,  # Versao 1.0.1
              "stringi" ,  # Versao 1.4.6
              "tidyr"   ,  # Versao 1.1.0
              "stringr" )  # Versao 1.4.0

# lapply(pacotes, packageVersion)
lapply(pacotes, library, character.only = T)

rm(pacotes)

Organização do script - seções

O RStudio permite que dentro do seu código seja possível organizá-lo em seções através de dois tipos de comentários específicos e, ainda, é possível acessar a seção de forma rápida (sem ser pelo rolamento do script).

Para criar uma seção no script basta fazer um comentário do tipo #- (pelo menos um - depois de #) ou, então, do tipo # (pelo menos um #). Porém, para a prática da divisão do script em seções ser instrutiva é preciso nomear essas seções de acordo com o que será feito nela, vide o exemplo e imagem abaixos. Após o texto no comentário é preciso preenchê-lo com, pelo menos, quatro hífens (-) ou hashtags (#).

Ainda, note que no exemplo apresentado abaixo o tipo de comentário foi #- - - - e não foi em vão. Esse tipo de comentário torna o seu programa visualmente mais limpo5.

#----------------------------------------------------------------------------------------------
# PROJETO: MELQO PRE ESCOLA - SAO PAULO
#
# OBJETIVO: Prepara a base de dados, processo de estruturacao de variaveis e 
# limpeza de dados da entrevista com o diretor (pre-escola)
#
# PRODUTO: Base de dados final
#
# AUTOR: SereLepe da Silva
#
# DATA DE CRIACAO: 02/2020
#
# DATA DE MODIFICACAO:  03/2020
#----------------------------------------------------------------------------------------------

#----Pacotes utilizados------------------------------------------------------------------------

pacotes <- c( "readxl"  ,  # Versao 1.3.1
              "dplyr"   ,  # Versao 1.0.1
              "stringi" ,  # Versao 1.4.6
              "tidyr"   ,  # Versao 1.1.0
              "stringr" )  # Versao 1.4.0

# lapply(pacotes, packageVersion)
lapply(pacotes, library, character.only = T)

rm(pacotes)

#----Caminhos----------------------------------------------------------------------------------

caminho_base_dados  <- "C:/Laboratório/Dados/MELQO/MELQO SAO PAULO/ORIGINAIS/CAMPO"
caminho_programas   <- "C:/Laboratório/daniel/melqo/melqo sao paulo/programas/do/campo"

Vale ressaltar, por fim, uma prática que permite que seu código fique mais organizado é criar e fazer de uma seção para caminhos (paths) de onde e para onde os arquivos serão importados e exportados. Note que no chunk acima existe esta seção.

Nomeação de objetos

Como tudo que existe no R é um objeto, é de suma importância aprender a nomeá-los. Dessa forma, é importante que o nome do objeto seja capaz de exprimir o que ele é porém sem ser redundante ou com uso excessivo de caracteres. Note como nos exemplos abaixo o uso excessivo de caracteres não ajudou na compreensão do objeto e que bastou algumas palavras que para compreendê-lo. O uso escasso de variáveis também não é recomendado, assim como o uso de caracteres em caixa alta.

Para separar palavras no nome do objeto é possível utilizar um ponto . ou underline _ . Porém é preferível o uso de underline.

#BOM

#pegando o numero da coluna respectivo a variavel
numero_coluna_variavel <- which( colnames(base_dados) == variavel )

#RUIM

#pegando o numero da coluna respectivo a variavel
numero_da_coluna_desta_variavel <- which( colnames(base_dados) == variavel )
numerocolunavariavel <- which( colnames(base_dados) == variavel )
NumeroColunaVariavel <- which( colnames(base_dados) == variavel )
numero <- which( colnames(base_dados) == variavel )
coluna <- which( colnames(base_dados) == variavel )

Nomeação de funções

Para nomear funções criadas no seu script o raciocínio é o mesmo para a nomeação de objetos: seja sucinto, claro mas sem uso excessivo ou escasso de caracteres e também não faça uso de caracteres em caixa alta. Assim como para objetos, para separar palavras no nome de uma função é possível utilizar um ponto . ou underline _ .

Porém, não utilize o mesmo padrão optado para nomear objetos, ou seja, se você optar pelo underline para nomear seu objeto, utilize o ponto para nomear sua função. Inclusive, esse é o padrão recomendado: underline para nomear objetos, utilize o ponto para nomear funções.

Criação de funções

Ainda sobre funções, ao criar uma função é preciso que esta tenha um único objetivo e não vários. Funções longas que fazem mais de uma coisa aumentam as chances de conterem erros. Elas também tornam a leitura e a reutilização dessa função mais difícil. Então, ao criar uma função tenha em mente que ela tem que fazer uma coisa só. Caso a sua função faça várias coisas, divida-a em várias funções.

Loop

É comum a diversas linguagens de programação escrever um loop utilizando somente a letra “i” ou “x” para o índice ou elemento, no entanto, essa forma não deixa claro o que está sendo percorrido. No passado esse tipo de prática era utilizado por conta do alto consumo de memória que o uso de caracteres tinha porém, atualmente isso não é mais um problema. Escrever o nome do que está sendo percorrido torna o seu código muito mais compreensível. Note a diferença abaixo.

#BOM

# Colocando as observacoes em caixa alta
for(coluna in 1:ncol(base_dados) ){
  
  try( for(linha in 1:nrow(base_dados) ){ 
    base_dados[linha,coluna] <- toupper(base_dados[linha, coluna]) 
  }
  )
  
}
rm(linha, coluna)
#RUIM

# Colocando as observacoes em caixa alta
for(i in 1:ncol(base_dados) ){
  try( for(j in 1:nrow(base_dados) ){ 
    base_dados[j,i] <- toupper(base_dados[j,i]) 
  })
}
rm(j, i)

Condicionais

Sempre prefira usar os condicionais if-else ao invés de usar dois condicionais if, conforme abaixo. Note que ao usar if-else você explicita que os dois casos são mutuamente exclusivos, além de deixar seu código mais legível.

#BOM

if( score > 15 ){
  #faz algo
} else{
  #faz outra coisa
}
#RUIM

if( score > 15 ){
  #faz algo
}
if( socre <= 15 ){
  #faz outra coisa
}

Boas práticas aplicada ao Stata

O conteúdo desenvolvido nessa seção foi baseado em Bjarkefur et al. (2020).

Um bom código perpassa por duas áreas: estilo e sintaxe. O estilo corresponde a elementos não funcionais como, por exemplo, espaçamento, indentação e nomeação. Já a sintaxe corresponde a linguagem do seu código e como ele é legível. Essas áreas aplicadas ao Stata serão abordadas nessa sessão.

Estilo

Estilo de programação é uma forma de descrever o esforço que deve ser feito para tornar seu código fácil de ler e entender. Uma boa organização do código e o uso de comentários podem ajudar o leitor a entender o que o programa faz e por quê.

Comentários

Comentários não mudam o resultado do seu programa mas eles podem tornar seu código muito mais compreensível para terceiros. Portanto, comente bastante! Porém, lembre que quanto mais simples for o seu código, menos necessidade de comentários você terá.

Tenha em mente que seu código precisa deixar claro o que você está fazendo, o porque está fazendo e com base em que está fazendo. O que você está fazendo pode ficar mais explícito com pequenos comentários sobre o que está sendo feito em cada comando. Porque está fazendo e com base em que está fazendo envolve decisões tomadas ao longo do projeto que precisam ser relatadas e uma das formas de relatar essa decisão é através de comentários6. Não se acanhe em deixar bem explicado porque tal parte do código está sendo implementada, principalmente as partes que excluem observações e variáveis.

Assim, comece o seu programa com um comentário no início indicando o objetivo do código e o produto dele gerado (caso haja algum). Indique também a que projeto esse programa pertence, data de criação do programa, última data de modificação e qual o autor(a) ou autores(as). O modelo a ser seguido está apresentado abaixo. Note que no modelo abaixo existe uma parte de “produto gerado,” este indica o que o programa está gerando. Por exemplo, um do-file que faz a limpeza de uma base de dados bruta está gerando uma base de dados finais, ou então um programa que faz análise descritiva de uma base de dados está gerando gráficos e tabelas referentes a análise descritiva.


/**********************************************************************************************
PROJETO: Nome do projeto

OBJETIVO: Objetivo do programa (do-file) Lorem ipsum dolor sit amet consectetur adipiscing, ///
elit semper turpis vivamus ultrices molestie volutpat, orci mauris nec pulvinar parturient. ///
Quis torquent sem aptent posuere quam quisque ex tempor

PRODUTO: Produto gerado pelo programa (do-file)

AUTOR: SereLepe da Silva

DATA DE CRIACAO: mm/aaaa

ULTIMA MODIFICACAO: mm/aaaa
*********************************************************************************************/

Para comentar um bloco de código fechado faça-o conforme o exemplo abaixo, em caixa alta. Note que ela pode se referir a um conjunto específico de comandos utilizados, como definição de labels ou pode também se referir a uma fase do programa, como correções pontuais da base de dados.

Já para comentar localmente o que está fazendo seja bem sucinto e utilize somente uma linha. E, por fim, para justificar algum comando faça-o de forma clara e sucinta, conforme o padrão abaixo.

/***********************************************************************************************
MACROS-CAMINHOS*/
{
local basedados     "C:\Laboratório\..."
local programas     "C:\Laboratório\...\programas"
local logs          "C:\Laboratório\...logs"
local workstata     "C:\Work Stata"
local tabelas       "C:\Laboratório\...\tabelas"
}
/*********************************************************************************************/


/***********************************************************************************************
IMPORTANDO BASE*/
{
import excel "$base_dados\base_de_dados.xlsx" , sheet("Página1") firstrow clear

*Renomeando as variaveis conforme o dicionario
ren nomeentrevistador   nome_entrevistador
ren codentrevistador      cod_entrevistador

*Renomeando as variaveis conforme o dicionario
/* Renomeando as variaveis conforme o dicionario pois Lorem ipsum dolor sit amet ///
consectetur adipiscing, elit semper turpis vivamus ultrices molestie volutpat
*/
ren nomeentrevistador   nome_entrevistador
ren codentrevistador    cod_entrevistador
}
/*********************************************************************************************/

Assim sendo, comente sempre que achar necessário (COMENTE MUITO!) e nunca (NUNCA!) utilize acentos ortográficos nos comentários.

Identação

No Stata, adicionar espaços não altera a execução do código e utilizá-los torna o seu programa muito mais legível e visualmente agradável. Note a diferença entre os códigos abaixo, como um é visualmente mais agradável que o outro.

*BOM

/***********************************************************************************************
MACROS-CAMINHOS*/
{
local basedados     "C:\Laboratório\..."
local programas     "C:\Laboratório\...\programas"
local logs          "C:\Laboratório\...logs"
local workstata     "C:\Work Stata"
local tabelas       "C:\Laboratório\...\tabelas"
}
/*********************************************************************************************/

*RUIM

/***********************************************************************************************
MACROS-CAMINHOS*/
{
local basedados "C:\Laboratório\..."
local programas "C:\Laboratório\...\programas"
local logs "C:\Laboratório\...logs"
local workstata "C:\Work Stata"
local tabelas "C:\Laboratório\...\tabelas"
}
/*********************************************************************************************/

Quebra de linhas

Ao ler um código, não é prático ficar rolando a tela para direita e para esquerda constantemente, por isso, evite linhas de código longas. Tome como regra de bolso que uma linha deve ter em torno de 80 caracteres. Assim, para organizar melhor o seu código quebre a sua linha de código usando ///7. Nas versões mais recentes do Stata a quebra de linha acontece automaticamente. Porém, para fins de padronização dos códigos e como não há uniformidade entre as versões utilizadas por todos os sereLepes, construa o seu código utilizando /// conforme o exemplo abaixo.

replace modalidade = 2 if nomesc == 1 | nomesc == 6 | nomesc == 7 |           ///
  nomesc == 8 | nomesc == 9 | nomesc == 10 | nomesc == 11 | nomesc == 12 |    ///
  nomesc == 13 | nomesc == 14 | nomesc == 15 | nomesc == 16 | nomesc == 17 |  ///
  nomesc == 18 | nomesc == 19 | nomesc == 20 | nomesc == 21 | nomesc == 22 |  ///
  nomesc == 23 | nomesc == 24 | nomesc == 25 | nomesc == 27 | nomesc == 28 |

Sintaxe

A sintaxe de um código está associada à linguagem do programa utilizado e suas características. Em relação ao Stata, aqui são abordados os seguintes assuntos sobre sintaxe com o objetivo de tornar seu código legível: macro, abreviação de comando, loop, condicionais e salvar a base.

Macro

O que é uma macro? Em poucas palavras, macro é uma forma de guardar várias palavras em uma só, por exemplo guardar um caminho (path file) do computador em apenas uma palavra. A macro possui dois comandos mais comuns local e global que correspondem a quanto tempo a macro ficará na memória. Para o comando local a macro criada ficará na memória até o do-file terminar. Já para o comando global, a macro criada ficará na memória até você sair do Stata.

Note que o uso de global permite que você crie uma macro em um projeto e ao mudar de projeto você continua com ela salva na memória. Assim, para maior segurança crie local macros.

Sempre (SEMPRE!) ao criar um do-file para o seu projeto crie primeiro as macros com os caminhos que serão utilizados no programa, conforme abaixo.

/***********************************************************************************************
MACROS-CAMINHOS*/
{
local basedados     "C:\Laboratório\..."
local programas     "C:\Laboratório\...\programas"
local logs          "C:\Laboratório\...logs"
local workstata     "C:\Work Stata"
local tabelas       "C:\Laboratório\...\tabelas"
}
/*********************************************************************************************/

Abreviação de comando

Os comandos do Stata geralmente podem ser abreviados, porém essa abreviação torna a leitura do seu código menos intuitiva, principalmente para novos programadores ou novos usuários do Stata.

Assim, evite abreviar os comandos, principalmente aqueles que se resumem a dois caracteres e que não indiquem claramente qual a palavra do comando.

Exemplos de abreviação compreensível:

  • tab para tabulate
  • hist para histogram
  • reg para regress

Exemplos de abreviação não compreensível:

  • tw para twoway
  • la para label ou la de para label define
  • di para display

Na dúvida, sempre escolha não abreviar.

Loop

É comum a diversas linguagens de programação escrever um loop utilizando somente a letra “i” ou “x” para o índice ou elemento, no entanto, essa forma não deixa claro o que está sendo percorrido. No passado esse tipo de prática era utilizado por conta do alto consumo de memória que o uso caracteres tinha porém, atualmente isso não é mais um problema. Escrever o nome do que está sendo percorrido torna o seu código muito mais compreensível. Note a diferença nos exemplos a seguir.

*BOM

foreach nome in nome_alunos{
        * faz algo com nome
}
 
 *Questao 11
foreach item of numlist 1/5{
  
  gen ed_q11_d`item' = 0
  
  replace ed_q11_d`item' = 1 if ed_q111 == `item' | ed_q112 == `item' |   ///
                                ed_q113 == `item' | ed_q114 == `item' 
}
*RUIM

foreach i in nome_alunos{
        * faz algo com i
}

*Questao 11
foreach z of numlist 1/5{
  gen ed_q11_d`z'=0
  replace ed_q11_d`z' = 1 if ed_q111 == `z' | ed_q112 == `z' | ed_q113 == `z' | ed_q114 == `z' 
}

Sentenças lógicas

Em sentenças lógicas no Stata, opte sempre por usar “!” para negativas ao invés de “~.” Essa notação (“!”) é a mesma utilizada na linguagem de R (e Python também), o que é uma grande vantagem para compreensão do seu código por terceiros, já que muitos sereLepes dominam ou o Stata ou o R.

Para checar missings utilize a função missing(‘var’) ao invés de construir um if(‘var’ \(>=\) .), conforme demonstrado abaixo.

*BOM

replace gen genero_mulher = "Feminino" if (genero == 1)  
replace gen genero_homem  = "Masculino" if ((genero != 1) & !missing(genero))  
*RUIM

replace gen genero_mulher = "Feminino" if genero == 1 
replace gen genero_homem = "Masculino" if genero ~= 1

Condicionais

Sempre prefira usar os condicionais if-else ao invés de usar dois condicionais if, conforme os exemplos. Note que ao usar if-else você explicita que os dois casos são mutuamente exclusivos, além de deixar seu código mais legível.

*BOM

if ( score > 15 ){
     *faz alguma coisa
}
else{
     *faz outra coisa
}  
*RUIM

if ( score > 15 ){
     *faz alguma coisa
}
if ( score =< 15 ){
     *faz outra coisa
}

Salvando a base

Boas práticas ao salvar uma base de dados são verificar se existem variáveis que podem ser excluídas, em geral variáveis intermediárias de verificação. Também é uma boa prática verificar se tem linhas duplicadas e se há identificadores duplicados, já que os identificadores costumam representar apenas um indivíduo.

Ainda, antes de salvar, utilize o comando compress para diminuir o tamanho do arquivo sem perder informação, seguindo o exemplo abaixo.

O que o compress faz? O comando compress examinará os dados na memória, determinará se alguma variável pode ser armazenada em um tipo de dados menor sem perder nenhuma precisão e converterá aquelas que podem ser. Ou seja, esse comando otimiza o armazenamento.

/***********************************************************************************************
SALVANDO BASE*/
{
 
 *Checado duplicacoes na variavel de identificacao/identificador
 
 isid id
 
 *Drop (dropar) variaveis que podem ser excluidas (se for o caso!)
 
 *Otimizando armazenamento
 
 compress
 
 *Salvando a base
 
 save "$base_dados_finais\base_de_dados_final.dta", replace
 
}
/**********************************************************************************************/

Help!

Dúvidas a respeito de um comando ou função faz parte do uso de um programa e por mais que alguém domine muito uma linguagem, é impossível saber todas as funções ou comandos e saber todos os argumentos das funções. Portanto, use (e abuse) do Help do seu programa. No RStudio, basta colocar a interrogação antes do nome da função para destacar a janela do Help com o documento que explica tal função. No Stata, basta digitar help antes do comando que ira abrir uma janela com as informações a respeito do comando.

Caso não tenha esclarecido sua dúvida, google-it! Ao pesquisar no Google8 a sua dúvida ou a respeito de uma função ou comando, você se torna oficialmente um programador! Nunca se esqueça que alguém há uns dez anos passou pela mesma dúvida que você e ela está no Stackoverflow9 ou no Statalist10. Então aproveite, pois você, sereLepe, está em ombros de gigantes!

Contato

Laboratório de Estudos e Pesquisas em Economia Social (LEPES).

Rua das Paineiras, casa 11. Campus da USP-RP

www.lepes.fearp.usp.br

  1. 3315-3918

Acompanhe-nos:
Facebook Instagram Linkedin YouTube Twitter

Referências

Bjarkefur, Kristoffer, Luiza Cardoso de Andrade, Benjamin Daniels, and Maria Ruth Jones. 2020. Development Research in Practice: The DIME Analytics Data Handbook. DIME Analytics.
Martin, Robert C. 2009. Clean Code: A Handbook of Agile Software Craftsmanship. Pearson Education.

  1. https://rstudio.com↩︎

  2. https://www.stata.com↩︎

  3. Outra forma de relatar decisões são documentos separados do código que contém todas essas informações aqui relatadas. Esse documento será no formato de um Leia-me↩︎

  4. Estes operadores são os operadores lógicos, aritméticos, relacionais e atribuitivos. Para exemplos veja https://www.datamentor.io/r-programming/operator/ .↩︎

  5. Lembrando que isso é apenas uma sugestão, porém o uso de seções é essencial para o seu código ser um bom código.↩︎

  6. Outra forma de relatar decisões são documentos separados do do-file que contém todas essas informações aqui relatadas. Esse documento pode ser no formato de um Leia-me.↩︎

  7. O Stata compreende que o código segue na linha debaixo.↩︎

  8. https://www.google.com.br/↩︎

  9. https://stackoverflow.com↩︎

  10. https://www.statalist.org/forums/↩︎