Codificação rígida - Hard coding
A codificação rígida (também codificação permanente ou codificação permanente ) é a prática de desenvolvimento de software de incorporar dados diretamente no código-fonte de um programa ou outro objeto executável, em oposição a obter os dados de fontes externas ou gerá-los em tempo de execução . Os dados codificados normalmente só podem ser modificados editando o código-fonte e recompilando o executável, embora possam ser alterados na memória ou no disco usando um depurador ou editor hexadecimal . Os dados codificados geralmente representam partes imutáveis de informações, como constantes físicas , números de versão e elementos de texto estáticos. Dados Softcoded , por outro lado, codificar informações arbitrárias através de entrada do usuário , arquivos de texto , arquivos INI , HTTP respostas do servidor, arquivos de configuração, macros de pré-processamento, constantes externos, bancos de dados, argumentos de linha de comando, e são determinados em tempo de execução.
Visão geral
A codificação rígida requer que o código-fonte do programa seja alterado a qualquer momento em que os dados de entrada ou o formato desejado mudem, quando pode ser mais conveniente para o usuário final alterar os detalhes por algum meio fora do programa.
Freqüentemente, a codificação rígida é necessária, mas também pode ser considerada um antipadrão . Os programadores podem não ter uma solução de interface de usuário dinâmica elaborada para o usuário final, mas ainda assim devem fornecer o recurso ou lançar o programa. Isso geralmente é temporário, mas resolve, em curto prazo, a pressão para entregar o código. Posteriormente, a codificação suave é feita para permitir que um usuário passe parâmetros que fornecem ao usuário final uma maneira de modificar os resultados ou resultados.
O termo "hard-coded" foi inicialmente usado como uma analogia para circuitos de hardwiring - e pretendia transmitir a inflexibilidade que resulta de seu uso no design e implementação de software. No contexto de ambientes de desenvolvimento colaborativo extensível em tempo de execução , como MUDs , hardcoding também se refere ao desenvolvimento do motor central do sistema responsável por tarefas de baixo nível e execução de scripts , em oposição à softcoding que desenvolve os scripts de alto nível que obtêm interpretado pelo sistema em tempo de execução , com valores de fontes externas, como arquivos de texto , arquivos INI , macros de pré-processador , constantes externas, bancos de dados , argumentos de linha de comando, respostas do servidor HTTP , arquivos de configuração e entrada do usuário . Nesse caso, o termo não é pejorativo e se refere ao desenvolvimento geral, em vez de incorporar dados de saída especificamente.
Hardcoding e backdoors
A codificação de credenciais é uma forma popular de criar uma porta dos fundos . As credenciais codificadas geralmente não são visíveis nos arquivos de configuração ou na saída dos comandos de enumeração de contas e não podem ser facilmente alteradas ou ignoradas pelos usuários. Se descoberto, um usuário pode ser capaz de desabilitar tal backdoor modificando e reconstruindo o programa a partir de seu código-fonte ( se a fonte estiver disponível publicamente ), descompilando ou software de engenharia reversa , editando diretamente o código binário do programa ou instituindo uma integridade verificar (como assinaturas digitais, anti-adulteração e anti-fraude ) para evitar o acesso inesperado, mas tais ações são frequentemente proibidas por um contrato de licença de usuário final .
Hardcoding e DRM
Como medida de gerenciamento de direitos digitais , os desenvolvedores de software podem codificar um número de série exclusivo diretamente em um programa. Ou é comum codificar uma chave pública , criando o DRM para o qual é inviável criar um keygen.
Caso contrário, um cracker de software pode codificar um número de série válido para o programa ou mesmo impedir que o executável solicite ao usuário, permitindo que cópias não autorizadas sejam redistribuídas sem a necessidade de inserir um número válido, compartilhando o mesmo chave para cada cópia, se uma tiver sido codificada.
Caminho de instalação fixo
Se um programa do Windows for programado para presumir que está sempre instalado em C: \ Arquivos de programas \ Appname e alguém tentar instalá-lo em uma unidade diferente por motivos de espaço ou organização, ele pode falhar ao instalar ou executar após a instalação. Este problema pode não ser identificado no processo de teste, uma vez que o usuário médio instala na unidade e diretório padrão e o teste pode não incluir a opção de alterar o diretório de instalação. No entanto, é aconselhável para programadores e desenvolvedores não corrigir o caminho de instalação de um programa, uma vez que o caminho de instalação padrão depende do sistema operacional, versão do sistema operacional e decisões de administrador de sistema . Por exemplo, muitas instalações do Microsoft Windows usam a unidade C: como disco rígido principal , mas isso não é garantido.
Havia um problema semelhante com microprocessadores nos primeiros computadores, que iniciavam a execução em um endereço fixo na memória.
Disco de inicialização
Alguns programas " protegidos contra cópia " procuram um arquivo específico em um disquete ou unidade flash na inicialização para verificar se não são cópias não autorizadas. Se o computador for substituído por uma máquina mais nova, que não possua unidade de disquete, o programa que o requer agora não poderá ser executado, pois o disquete não poderá ser inserido.
Este último exemplo mostra por que a codificação permanente pode se tornar impraticável, mesmo quando parece que funcionaria completamente. Nas décadas de 1980 e 1990, a grande maioria dos PCs era equipada com pelo menos uma unidade de disquete, mas as unidades de disquete deixaram de ser usadas posteriormente. Um programa codificado dessa maneira 15 anos atrás poderia enfrentar problemas se não fosse atualizado.
Pastas Especiais
Alguns sistemas operacionais Windows possuem as chamadas Pastas Especiais, que organizam arquivos logicamente no disco rígido. Podem surgir problemas envolvendo codificação permanente:
Caminho do perfil
Alguns programas do Windows codificam permanentemente o caminho do perfil para locais definidos pelo desenvolvedor, como . Esse é o caminho para a grande maioria do Windows 2000 ou superior, mas isso causaria um erro se o perfil fosse armazenado em uma rede ou realocado de outra forma. A maneira correta de obtê-lo é chamar a função ou resolver a variável de ambiente. Outra suposição que os desenvolvedores costumam fazer é presumir que o perfil está localizado em um disco rígido local.
C:\Documents and Settings\UsernameGetUserProfileDirectory%userprofile%
Caminho da pasta Meus Documentos
Alguns programas do Windows codificam o caminho My Documentscomo ProfilePath\My Documents. Esses programas funcionariam em máquinas que executam a versão em inglês, mas em versões localizadas do Windows, essa pasta normalmente tem um nome diferente. Por exemplo, nas versões italianas, a My Documentspasta é denominada Documenti . My Documentstambém pode ter sido realocado usando o Redirecionamento de Pasta na Diretiva de Grupo no Windows 2000 ou superior. A maneira correta de obtê-lo é chamar a SHGetFolderPathfunção.
Solução
Uma referência indireta, como uma variável dentro do programa chamada "FileName", poderia ser expandida acessando uma janela de diálogo "Browse for File", e o código do programa não teria que ser alterado se o arquivo fosse movido.
A codificação rígida é especialmente problemática na preparação do software para tradução para outros idiomas.
Em muitos casos, um único valor embutido em código, como um tamanho de array, pode aparecer várias vezes no código-fonte de um programa. Este seria um número mágico . Normalmente, isso pode causar um bug no programa se algumas das aparências do valor forem modificadas, mas não todas. Esse bug é difícil de encontrar e pode permanecer no programa por muito tempo. Um problema semelhante pode ocorrer se o mesmo valor codificado for usado para mais de um valor de parâmetro, por exemplo, uma matriz de 6 elementos e um comprimento de string de entrada mínimo de 6. Um programador pode alterar por engano todas as instâncias do valor (muitas vezes usando um recurso de pesquisa e substituição do editor) sem verificar o código para ver como cada instância é usada. Ambas as situações são evitadas definindo constantes , que associam nomes aos valores, e usando os nomes das constantes para cada aparência dentro do código.
Um caso importante de codificação permanente é quando as strings são colocadas diretamente no arquivo, o que força os tradutores a editar o código-fonte para traduzir um programa. (Existe uma ferramenta chamada gettextque permite que as strings sejam deixadas em arquivos, mas permite que os tradutores as traduzam sem alterar o código-fonte; ela efetivamente desdenha os códigos das strings.)
Codificação permanente em competições
Em competições de computação, como a Olimpíada Internacional de Informática , os competidores devem escrever um programa com um padrão específico de entrada-saída de acordo com os requisitos das perguntas.
Em casos raros em que o número possível de entradas é pequeno o suficiente, um competidor pode considerar o uso de uma abordagem que mapeie todas as entradas possíveis para suas saídas corretas. Este programa seria considerado uma solução embutida em código em oposição a um algoritmo (embora o programa embutido em código possa ser a saída de um programa algorítmico).