Programação para a Prova: Respostas em Python que Pontuam

Avaliadores de prova não executam seu código em um depurador por vinte minutos. Leem uma vez, talvez duas, e conferem contra um rubrica. Uma solução funcionando que ignora a rubrica ainda pode perder pontos, enquanto uma um pouco mais áspera que atinge cada checkpoint pode pontuar melhor. Escrever Python para uma prova é uma habilidade diferente de escrever Python para um projeto real, e vale a pena praticar separadamente.

Leia a rubrica antes de ler o problema duas vezes

A maioria das provas de programação — questões de resposta livre estilo AP CS A, provas intermediárias de universidade, avaliações de bootcamp de programação — publica regras de crédito parcial. Uma linha típica de rubrica parece: "1 ponto por estrutura de loop correta, 1 ponto por valor de retorno correto, 1 ponto por tratar o caso de lista vazia." Se você escrever um one-liner denso que obtém a resposta certa mas pula um loop explícito, alguns avaliadores vão descontar você mesmo que a saída esteja correta.

Antes de digitar qualquer coisa, identifique as partes que um avaliador provavelmente checará separadamente:

• Assinatura da função corresponde exatamente ao solicitado (nome, ordem de parâmetros, tipo de retorno)
• Caso base e caso recursivo, se recursão é esperada
• Limites do loop (erros off-by-one são a perda de ponto única mais comum)
• Casos extremos: entrada vazia, entrada de um elemento, números negativos, duplicatas

Escreva estes como comentários primeiro. # handle empty list, # base case: n == 0. Isto custa dez segundos e garante que você não esquece do caso que um avaliador está especificamente procurando.

Estruture o código para que crédito parcial seja visível

Compare duas respostas para "escreva uma função que retorna o segundo maior número em uma lista":

def second_largest(nums):
    return sorted(nums)[-2]

def second_largest(nums):
    if len(nums) < 2:
        return None
    largest = second = float('-inf')
    for n in nums:
        if n > largest:
            second = largest
            largest = n
        elif n > second and n != largest:
            second = n
    return second

A primeira está correta para entrada bem-formada mas quebra em uma lista com menos de dois elementos e dá uma resposta errada em duplicatas como [5, 5, 3] (retorna 5, possivelmente errado dependendo da especificação). A segunda é mais longa mas cada linha de rubrica — caso extremo, lógica correta, retorno correto — é explícita e ganha sua própria linha que um avaliador pode conferir. Em uma prova cronometrada, a segunda versão pontua melhor quase toda vez, mesmo que demore mais para digitar.

Não otimize prematuramente, não deixe bugs óbvios também

Questões de prova raramente testam conhecimento de Big-O a menos que digam diretamente. Se o enunciado diz "escreva uma função que encontra duplicatas," um loop aninhado a O(n²) é aceitável a menos que o enunciado especifique entrada grande ou peça uma solução eficiente. Gastar tempo de prova convertendo para uma abordagem baseada em conjunto a O(n) quando não foi pedido é tempo que você não consegue de volta.

Dito isso, alguns erros sempre vão custar você independentemente da rubrica:

• Usar == em vez de is inconsistentemente causando bugs de lógica (raro em provas Python mas aparece em questões pesadas em comparação)
• Mutar uma lista enquanto itera sobre ela — for x in lst: lst.remove(x) é uma armadilha clássica de prova que produz saída silenciosamente errada
• Esquecer return e imprimir em vez — muitos autograders checam valores de retorno, não stdout
• Off-by-one em range() — range(len(nums)) vs range(len(nums) - 1) é worth double-checking toda única vez que você escreve

Trace seu código manualmente antes de enviar

Em provas em papel e a maioria das provas de codificação em navegador, você não consegue rodar o código. Pegue um exemplo pequeno e trace linha por linha, anotando valores de variáveis conforme vai. Isto pega talvez 80% dos erros de lógica em menos de dois minutos, e é a coisa de maior valor que você pode fazer com tempo sobrando.

Para funções recursivas especificamente, trace pelo menos dois níveis profundos e escreva explicitamente o caso base atingido. Avaliadores frequentemente dão um ponto só por demonstrar que o caso base termina corretamente, separado do ponto para o caso recursivo estar correto.

Gerencie o relógio como um recurso, não uma reflexão tardia

Se uma seção de resposta livre vale 9 pontos em três sub-questões, orçamente tempo aproximadamente igual e saia se estiver travado além desse orçamento — uma parte (b) meio escrita mas quase correta vale mais pontos brutos do que uma parte (a) perfeita e uma parte (c) em branco. Escreva uma função stub com a assinatura correta e um pass ou um palpite mesmo se não conseguir terminar a lógica; uma assinatura correta sozinha às vezes vale um ponto de rubrica por si só.

Para mais sobre escrever Python limpo e testável fora da sala de prova, e sobre estruturas de dados que aparecem constantemente nessas questões, confira os segmentos relacionados de Python e Computer Science no Korra Studio.