Em Programação Qual Das Seguintes Afirmações Define Corretamente Um Algoritmo

O que é um algoritmo na prática

Muita gente confunde algoritmo com programa. Não é a mesma coisa. Um algoritmo é uma sequência finita e bem definida de passos que resolve um problema ou realiza uma tarefa. O programa é a materialização disso em código, com todas as idiossincrasias da linguagem e do compilador. Você pode escrever um algoritmo à mão, num quadro branco, antes de tocar no teclado. Isso é mais comum do que parece em entrevistas técnicas. A diferença entre saber explicar o algoritmo e saber implementá-lo é onde a maioria das pessoas tropeça.

Em programação qual das seguintes afirmações define corretamente um algoritmo

A definição correta é a que diz que um algoritmo é uma sequência ordenada e finita de instruções que, quando executada, produz um resultado previsível a partir de entradas específicas. Ele precisa ter início, meio e fim definidos. Se não tem fim, não é algoritmo — é loop infinito. E loop infinito, por si só, não é algo ruim em todos os contextos, mas numa definição teórica conta como defeito. As definições erradas que aparecem em questões desse tipo costumam incluir palavras como "tentar", "esperar que funcione", "mais ou menos". Algoritmo não aceita ambiguidade. Cada passo precisa ser inequívoco. Se você precisa de um dicionário para entender a instrução, já errou. No fundo, um algoritmo responde três perguntas: o que receber, o que fazer e o que devolver. Entrada, processamento, saída. Qualquer definição que ignore um desses três pilares está incompleta.

Dei uma aula sobre isso e um aluno perguntou se um script que ele tinha escrito contando a ocorrências de uma palavra num arquivo era um algoritmo. Eu disse que sim, porque tinha entrada (o arquivo), processamento (a contagem) e saída (o número). A pergunta dele era sobre qual versão era melhor, não sobre o que era um algoritmo. Essa distinção aparece o tempo todo.

Propriedades que todo algoritmo preciso precisa ter

Entrada: zero ou mais valores fornecidos externamente. Pode ser vazio, mas precisa ser explícito. Saída: pelo menos um resultado. Se não sai nada, o algoritmo não fez nada útil. Finitude: precisa terminar. Sempre. Existe diferença entre complexidade alta e não-terminal. Um algoritmo que leva 10^9 anos para rodar ainda é finito. Um que nunca para já foge da definição.

Definição: cada passo tem que ser claro, sem margem para interpretação. Isso é mais difícil do que parece quando você começa a escrever para máquinas que processam tudo literalmente. Efetividade: cada passo precisa ser executável na prática, não só no papel. Uma instrução como "escolha o melhor caminho" não é efetiva. Escolher como definir "melhor" é que é efetivo. Essas cinco propriedades vêm do livro do Knuth, Introduction to Algorithms. Quem cita como fonte primária em provas técnicas geralmente espera que você saiba o nome delas, não apenas a lista.

Um exemplo real do dia a dia

Eu precisei uma vez escrever um algoritmo de ordenação para dados vindos de sensores industriais. A especificação dizia apenas "ordenar os valores". Parecia simples. O problema era que os sensores às vezes enviavam NaN (not a number) e o algoritmo de quicksort padrão simplesmente travava ou ordenava os valores válidos e jogava os NaN no meio da lista sem lógica. A solução que funcionou foi tratar NaNs como um caso especial antes da ordenação. Separei os NaNs, ordenei só os valores numéricos com um heapsort (que tem garantia de O(n log n) no pior caso, ao contrário do quicksort), e depois reconexionei os NaNs no final. Esse detalhe — escolher o algoritmo de ordenação com base nos dados de entrada e não na complexidade assintótica pura — é o tipo de coisa que livros não ensinam. Você aprende quando o quicksort quebra na produção às três da manhã. Esse caso mostra algo importante: definir um algoritmo formalmente é uma coisa. Defini-lo de maneira robusta para o mundo real é outra. A definição teórica não te prepara para NaNs, dados ausentes, overflow de ponto flutuante ou qualquer um dos dezenas de bordas que aparecem quando você para de usar arrays hipotéticos.

Erros comuns em questões de múltipla escolha

A principal armadilha é a palavra "infinito". Se uma definição fala que um algoritmo pode ter infinitos passos, está errada. Outro erro clássico é confundir algoritmo com heurística. Heurística é uma aproximação que entrega uma resposta boa o bastante sem garantia de optimalidade. Algoritmo exato exige corretude verificável. Também vejo muita gente marcar alternativas que dizem que algoritmo é "um programa pronto". Programa é código. Algoritmo é o plano antes do código. O código pode conter bugs, a definição do algoritmo não deve. Outra pegadinha frequente: afirmar que algoritmos só existem na computação. Eles existem há séculos. O algoritmo de Euclides para o MDC é de 300 a.C. Isso não muda a definição, mas ajuda a entender que o conceito é mais antigo que as máquinas.

Complexidade e a definição de algoritmo

Complexidade computacional é uma propriedade analisada depois que o algoritmo está definido. Não faz parte da definição em si. Um algoritmo pode ser perfeitamente válido e ter complexidade exponencial. O fato de ser ineficiente não o desclassifica como algoritmo. O que desclassifica é a falta de finitude ou a ambiguidade dos passos. Eficiência é uma métrica de qualidade, não de existência. Isso confunde muita gente que treina para prova e mistura os conceitos. Na prática, quando você trabalha com algoritmos reais, a eficiência é o que mais importa. Mas numa questão teórica, a correção da definição vem antes de qualquer discussão sobre Big O. Separar esses dois níveis de análise é parte do raciocínio que a banca quer ver.

Por que isso importa fora da prova

Se você consegue definir um algoritmo com clareza, consegue descrevê-lo para colegas, revisar implementações de outros e identificar onde o código divergiu da intenção original. Isso é útil em code review, em documentação e em situações onde o código não existe ainda e você precisa decidir o que construir. Muitas falhas em projetos começam com uma definição de algoritmo mal entendida. O time codifica algo que soa como a solução, mas na verdade resolve um problema diferente porque os requisitos de entrada e saída não estavam claros desde o início. Definir o algoritmo antes de escrever uma linha de código evita essa categoria inteira de erro. A minha experiência é que desenvolvedores mais experientes gastam mais tempo definindo o algoritmo no papel ou em pseudocódigo e menos tempo depurando implementação. Não é uma regra absoluta, mas a proporção se inverte quando você pula direto para o código.