Python na investigação: da folha de cálculo à análise reprodutível

A ciência precisa mostrar não apenas o resultado, mas o caminho

Uma tabela final pode parecer convincente. Um gráfico pode ser visualmente impecável. Um valor de p pode estar correctamente calculado. Ainda assim, nada disso revela, por si só, como os dados brutos se transformaram naquele resultado.

Entre a recolha e a publicação existe uma longa cadeia de decisões: corrigir grafias diferentes para a mesma localidade, converter idades guardadas como texto, identificar duplicações, definir valores ausentes, excluir medições impossíveis, calcular indicadores, escolher testes estatísticos e ajustar figuras. Quando essas decisões são tomadas por meio de cliques, cópias, colagens e fórmulas espalhadas por várias folhas, uma parte essencial do método permanece oculta.

É nesse espaço invisível que surgem muitos erros. Uma fórmula pode não abranger a última linha; uma coluna pode ser ordenada sem as restantes; um valor pode ser sobrescrito; uma nova versão do ficheiro pode circular com o nome “final_corrigido_versao3”. O problema não é a falta de competência do investigador. É a fragilidade de um processo que depende de memória, atenção contínua e operações difíceis de reconstruir.

Roger Peng propôs a reprodutibilidade computacional como um padrão mínimo quando a repetição independente completa de um estudo não é imediatamente possível. Nesse sentido, tornar disponíveis os dados permitidos, o código e as instruções de execução não é um luxo técnico: é uma forma de permitir que outras pessoas examinem como as evidências sustentam uma conclusão (Peng, 2011).

A folha de cálculo não é inimiga — mas tem limites

Folhas de cálculo são acessíveis, familiares e excelentes para várias tarefas. Permitem introduzir dados, fazer uma primeira inspecção, construir tabelas pequenas e comunicar resultados a pessoas que não programam. Em muitos contextos universitários, constituem a porta de entrada para a análise quantitativa.

O erro está em confundir familiaridade com rastreabilidade. À medida que o estudo cresce, três limitações tornam-se importantes.

1. A lógica fica escondida nas células

Numa folha com centenas de fórmulas, compreender o método exige abrir células individualmente e verificar referências. Uma alteração acidental pode produzir um resultado diferente sem deixar um registo claro do que mudou.

2. Repetir o trabalho significa repetir gestos

Se chegam 50 novos questionários, o investigador pode ter de copiar fórmulas, refazer filtros, actualizar gráficos e conferir intervalos. Quanto maior o número de operações manuais, maior a probabilidade de inconsistência.

3. A proveniência dos dados torna-se confusa

Quando dados brutos, dados corrigidos, cálculos e resultados convivem no mesmo ficheiro, torna-se difícil preservar o conjunto original. Uma boa análise deve permitir distinguir claramente aquilo que foi recolhido daquilo que foi transformado.

Python não elimina a folha de cálculo. Pelo contrário, bibliotecas como pandas importam e exportam formatos como CSV e Excel, permitindo que a folha continue a funcionar como interface de entrada ou de comunicação, enquanto as transformações passam a ser registadas em código (pandas, documentação sobre dados tabulares).

O que Python muda na prática

Programar uma análise significa escrever instruções explícitas para o computador. Em vez de limpar cada valor manualmente, descreve-se uma regra. Em vez de refazer o gráfico quando os dados mudam, executa-se novamente o mesmo código.

Considere um estudo sobre insegurança alimentar. O ficheiro contém o identificador do agregado familiar, a localidade, a diversidade alimentar e a situação de insegurança alimentar. Um fluxo simples poderia ser:

import pandas as pd

# 1. Ler os dados sem alterar o ficheiro original
dados = pd.read_excel("dados_brutos.xlsx")

# 2. Normalizar nomes de colunas
dados.columns = (
    dados.columns
    .str.strip()
    .str.lower()
    .str.replace(" ", "_")
)

# 3. Remover registos duplicados pelo identificador
dados_limpos = dados.drop_duplicates(subset="id_agregado")

# 4. Converter a diversidade alimentar para valor numérico
dados_limpos["diversidade_alimentar"] = pd.to_numeric(
    dados_limpos["diversidade_alimentar"],
    errors="coerce"
)

# 5. Produzir um resumo por localidade
resumo = (
    dados_limpos
    .groupby("localidade", as_index=False)
    .agg(
        participantes=("id_agregado", "count"),
        diversidade_media=("diversidade_alimentar", "mean")
    )
)

# 6. Guardar um resultado derivado, mantendo os dados brutos intactos
resumo.to_csv("resultados/resumo_por_localidade.csv", index=False)

Este código não é apenas um meio de obter uma tabela. Ele é um registo legível de seis decisões. Outro investigador pode verificar a coluna usada para identificar duplicações, questionar a conversão de valores inválidos ou executar a mesma sequência num conjunto actualizado.

O ganho central não é “fazer contas mais depressa”. É tornar o raciocínio operacional visível.

Reprodutibilidade não é o mesmo que replicação

Os termos são frequentemente usados como sinónimos, mas convém distingui-los.

• Reprodutibilidade computacional: outra pessoa obtém os mesmos resultados usando os mesmos dados, código e condições analíticas.
• Replicação: um novo estudo, com nova recolha de dados, testa novamente a mesma pergunta ou hipótese.

Uma análise pode ser reprodutível e ainda conter escolhas metodológicas inadequadas. Se o código aplica o teste estatístico errado, executá-lo perfeitamente não torna a inferência válida. Da mesma forma, uma investigação qualitativa ou de campo pode ser cientificamente rigorosa sem depender intensamente de programação.

Por isso, Python deve ser visto como parte da infraestrutura metodológica, não como substituto do desenho de estudo, da teoria, da ética ou do conhecimento do contexto. Código bem escrito automatiza decisões; não garante que sejam boas decisões.

Do ficheiro isolado ao projecto de investigação

Uma análise reprodutível começa antes do primeiro gráfico. Exige organização suficiente para que dados, código e resultados não se confundam. Uma estrutura possível é:

projecto/
├── README.md
├── dados/
│   ├── brutos/
│   └── processados/
├── codigo/
├── resultados/
│   ├── tabelas/
│   └── figuras/
├── documentos/
└── requirements.txt

O ficheiro README.md explica o objectivo do projecto, a origem dos dados, as instruções de execução e as limitações. A pasta de dados brutos deve ser preservada e, sempre que possível, tratada como somente leitura. Os dados processados são produtos do código, não substitutos silenciosos dos originais. Tabelas e figuras devem ser geradas automaticamente e guardadas em pastas próprias.

Essa separação parece simples, mas previne um dos erros mais frequentes: não saber se uma tabela é fonte, resultado intermédio ou produto final.

Notebooks: laboratório narrativo, mas não infalível

O Jupyter Notebook tornou-se popular porque reúne texto, código, equações, resultados e gráficos no mesmo documento. Para ensino e exploração, essa combinação é poderosa. O investigador pode explicar uma decisão e, logo abaixo, mostrar o código e o resultado correspondente.

No entanto, notebooks podem ser executados fora de ordem. Uma célula inferior pode depender de um valor criado numa célula superior que foi alterada depois. O documento parece completo, mas uma execução do início ao fim pode falhar. As recomendações para investigação reprodutível em Jupyter incluem organizar o fluxo de forma linear, documentar dependências, preservar dados de entrada, evitar resultados dependentes de estado oculto e testar a execução integral (Rule et al., 2019).

Uma regra prática é simples: antes de partilhar um notebook, reinicie o ambiente e execute todas as células do princípio ao fim. Se ele não produzir novamente os resultados, ainda não é reprodutível.

O ambiente também faz parte do método

O mesmo código pode comportar-se de modo diferente quando as versões das bibliotecas mudam. Por isso, não basta guardar um ficheiro .py ou .ipynb; é necessário registar as dependências.

Ambientes virtuais isolam as bibliotecas usadas por cada projecto. Um ficheiro requirements.txt pode guardar versões específicas:

pandas==2.3.2
numpy==2.3.2
scipy==1.16.1
matplotlib==3.10.5

As versões acima são apenas ilustrativas; o investigador deve registar aquelas que efectivamente testou. Para projectos mais complexos, gestores de ambiente e contentores podem capturar detalhes adicionais. A documentação oficial de empacotamento do Python reúne orientações para instalar, distribuir e controlar dependências (Python Packaging Authority).

Reprodutibilidade absoluta ao longo de décadas pode ser difícil, devido à evolução de sistemas operativos, bibliotecas e hardware. Ainda assim, documentar o ambiente reduz drasticamente a ambiguidade e prolonga a vida útil da análise.

Controlo de versões: um histórico do raciocínio

Ferramentas como Git registam alterações no código e em ficheiros de texto. Cada confirmação pode descrever uma mudança: “corrige tratamento de valores ausentes”, “adiciona análise por sexo” ou “actualiza legenda da Figura 2”. Isso permite comparar versões, recuperar estados anteriores e colaborar sem substituir ficheiros uns dos outros.

O controlo de versões não deve ser usado para publicar dados pessoais ou confidenciais. Ficheiros com nomes, contactos, coordenadas sensíveis ou informações clínicas precisam de protecção adequada e, em muitos casos, não devem ser enviados para repositórios públicos. Transparência científica não significa exposição indiscriminada.

Quando os dados não podem ser partilhados, ainda é possível disponibilizar:

• o código de análise;
• um dicionário de variáveis;
• dados simulados com a mesma estrutura;
• instruções para solicitar acesso legítimo;
• uma descrição precisa das restrições éticas e legais.

Automação também melhora a revisão científica

Quando tabelas e figuras são produzidas por código, uma correcção nos dados pode propagar-se por toda a análise. O investigador não precisa actualizar manualmente cada percentagem no documento. Isso reduz discrepâncias entre resultados e texto.

Além disso, funções reutilizáveis e testes automáticos podem verificar pressupostos básicos. Um projecto pode alertar se existirem idades negativas, identificadores repetidos ou categorias inesperadas. Wilson e colaboradores recomendam práticas como escrever programas para pessoas, dividir problemas em partes pequenas, automatizar tarefas repetitivas e acompanhar mudanças com controlo de versões (Wilson et al., 2014).

Essas práticas não pertencem apenas à informática. Elas são formas de controlo de qualidade aplicáveis à epidemiologia, biologia, agricultura, educação, economia e outras áreas que trabalham com dados.

Um percurso realista de migração

Não é necessário abandonar imediatamente todos os procedimentos conhecidos. A transição pode ocorrer em etapas.

Etapa 1 — Usar Python como leitor da folha

Mantenha a recolha em Excel ou num formulário, mas importe os dados com pandas. Comece por observar colunas, tipos de dados, valores ausentes e duplicações.

Etapa 2 — Automatizar uma tarefa repetitiva

Escolha uma operação frequente: padronizar nomes, calcular uma média, gerar uma tabela de frequências ou exportar um gráfico. Compare o resultado com o procedimento anterior.

Etapa 3 — Separar dados brutos e derivados

Nunca corrija silenciosamente o único exemplar do ficheiro original. Faça o código ler os dados brutos e produzir um novo conjunto processado.

Etapa 4 — Documentar decisões

Registe por que razão valores foram excluídos, como variáveis foram recodificadas e quais critérios definiram cada grupo. Comentários no código ajudam, mas decisões metodológicas importantes também devem aparecer no protocolo ou no README.

Etapa 5 — Registar o ambiente e testar do início ao fim

Crie um ambiente isolado, guarde as dependências e peça a um colega que execute a análise. As dificuldades encontradas por outra pessoa revelam lacunas que permanecem invisíveis para quem criou o projecto.

Os perigos de automatizar sem compreender

Python torna muito fácil aplicar modelos estatísticos, mas a facilidade da execução pode criar uma falsa sensação de rigor. Um comando pode produzir regressões, intervalos de confiança e gráficos sofisticados mesmo quando a amostra, o desenho ou os pressupostos não justificam a análise.

Há pelo menos cinco riscos que merecem atenção:

1. Código copiado sem validação: um exemplo da internet pode não corresponder à estrutura dos dados ou à pergunta científica.
2. Valores ausentes tratados automaticamente: remover todas as linhas incompletas pode introduzir viés.
3. Escolha de testes pelo resultado: experimentar vários métodos até encontrar significância compromete a validade da inferência.
4. Gráficos persuasivos, mas enganosos: escalas truncadas e agregações inadequadas podem distorcer padrões.
5. Uso acrítico de inteligência artificial: assistentes podem gerar código plausível, porém errado, inventar funções ou ignorar questões éticas.

A inteligência artificial pode explicar mensagens de erro, propor uma estrutura inicial e comentar código, mas o investigador continua responsável por verificar cada transformação e interpretar os resultados. Código gerado por IA deve ser tratado como uma sugestão sujeita a revisão, não como autoridade metodológica.

O contexto africano: reprodutibilidade com recursos limitados

Em universidades e centros de investigação com acesso irregular à internet, computadores partilhados ou licenças dispendiosas, ferramentas abertas oferecem uma vantagem concreta. Python, Jupyter, pandas, SciPy e Matplotlib podem ser usados sem pagamento de licenças. Materiais podem ser instalados para trabalho local, e o código pode circular em dispositivos de armazenamento ou redes institucionais.

Mas software gratuito não significa adopção sem custos. São necessários formação, tempo, apoio técnico e materiais ajustados aos problemas locais. Ensinar apenas sintaxe — variáveis, ciclos e funções — não basta. A aprendizagem torna-se mais significativa quando parte de situações reais: organizar dados de parcelas agrícolas, calcular diversidade alimentar, analisar qualidade da água ou resumir resultados laboratoriais.

Também é importante evitar que a exigência de reprodutibilidade se transforme numa barreira injusta. Um estudante não deve ser penalizado por não dominar uma infraestrutura sofisticada que a instituição nunca ensinou. A resposta adequada é construir competências progressivamente, promover colaboração e reconhecer diferentes níveis de maturidade computacional.

Reprodutível para quem?

Um projecto não é verdadeiramente reprodutível se apenas o seu autor compreende nomes enigmáticos, caminhos absolutos e etapas não documentadas. Reprodutibilidade é também uma questão de comunicação.

Isso implica usar nomes claros, explicar abreviaturas, indicar unidades, fornecer metadados e escrever instruções que alguém fora da equipa consiga seguir. Implica ainda considerar acessibilidade: resultados importantes não devem existir apenas em gráficos; tabelas, descrições textuais e valores essenciais ajudam leitores com diferentes necessidades.

Reproduzir não é simplesmente pressionar “Executar”. É compreender o suficiente para avaliar se cada etapa corresponde ao método declarado.

Uma mudança de hábito científico

A passagem para Python não acontece quando o investigador instala a linguagem. Acontece quando começa a pensar na análise como um processo que deve poder ser reconstruído.

Esse processo pode ser resumido em perguntas:

• De onde vieram os dados?
• O original foi preservado?
• Que transformações foram realizadas?
• Quem as realizou e por quê?
• Que versões de software foram usadas?
• As tabelas e figuras podem ser geradas novamente?
• Outra pessoa consegue executar e compreender o fluxo?

Se essas perguntas recebem respostas claras, a tecnologia está a servir a ciência. Se permanecem sem resposta, um notebook elegante pode apenas esconder a mesma opacidade de uma folha de cálculo desorganizada.

Conclusão: código como parte da evidência

Python não torna automaticamente uma investigação rigorosa. Contudo, permite que o rigor deixe marcas verificáveis: regras de limpeza explícitas, análises repetíveis, figuras geradas a partir dos dados e um histórico de alterações.

A folha de cálculo continuará a ter lugar no laboratório, na sala de aula e no trabalho de campo. A mudança necessária não é proibi-la, mas reconhecer o momento em que operações manuais deixam de ser suficientes. Quando uma análise influencia uma conclusão científica, o procedimento que a produziu deve ser tão examinável quanto a própria conclusão.

Adoptar Python, portanto, não é apenas aprender uma linguagem. É assumir um compromisso com uma ciência que pode explicar o que fez, repetir o que calculou e corrigir-se quando necessário. Na investigação, essa capacidade não é um detalhe técnico. É parte da confiança que uma comunidade deposita no conhecimento produzido.