É uma prática ruim criar blocos de código?


12

No C ++, é recomendável criar blocos de código dentro de alguma função, como a seguinte:

    bool f()
    {
       {
           double test = 0;

           test = // some other variable outside this function, for example.

           if (test == // some value)
             return true;
       }

       {
           double test = 0;

           test = // some variable outside this function, different from the last one.

           if (test == // some value)
             return true;
       }

       return false;

    }

O objetivo de fazer isso seria usar o mesmo nome de variável "teste" várias vezes, para o mesmo tipo de procedimento. No projeto atual, tenho várias variáveis ​​e estou executando vários testes. Eu realmente não quero continuar criando novas variáveis ​​com nomes diferentes para cada um dos testes, considerando como os testes são tão semelhantes.

É uma má prática inserir blocos de código para que as variáveis ​​fiquem fora do escopo após cada teste e, em seguida, eu possa usar seus nomes novamente? Ou devo procurar outra solução? Deve-se observar que considerei usar o mesmo conjunto de variáveis ​​para todos os meus testes (e apenas defini-los como 0 após o término de cada teste), mas fiquei com a impressão de que isso pode ser uma prática ruim.


19
Se eu estivesse revisando esse código, diria para você separar cada um desses testes em métodos individuais ... Como conseqüência, você não precisaria usar blocos de código para fazer o escopo separadamente.
Maybe_Factor

1
@Maybe_Factor - eu concordo. O benefício de métodos separados é que você pode nomear cada bloco, fornecendo um código mais legível.
Mouviciel 2/11

@mouviciel Não apenas código mais legível, mas relatórios de teste mais legíveis!
precisa saber é o seguinte

@Maybe_Factor Eu discordo. Mover coisas para funções separadas tem o efeito negativo de fazê-las parecer pequenos pedaços reutilizáveis ​​de funcionalidade. Manter toda a lógica de uma função em um só lugar é bom.
Route de milhas

1
@MilesRout Esta não é uma função lógica, trata-se de vários testes de unidade para uma função, tudo em uma única função de teste. Blocos de código versus funções no código normal é outra discussão inteiramente.
precisa saber é o seguinte

Respostas:


22

Os blocos são perfeitamente razoáveis ​​se você os estiver usando para escopo de algum recurso. Arquivos, conexões de rede, alocações de memória, transações de banco de dados, o que for. Nesses casos, o bloco é realmente parte da estrutura lógica do código: você gera um recurso, ele existe por algum período de tempo e depois desaparece em um horário designado.

Mas se tudo o que você está fazendo é definir um nome para o escopo , então eu diria que eles são uma má prática. De um modo geral, é claro; circunstâncias especiais podem ser aplicadas.

Por exemplo, se essa função foi gerada por algum sistema de geração de código, estrutura de teste ou algo semelhante, blocos para fins de escopo de nome são uma coisa razoável. Mas você estaria falando de código escrito para o propósito de uma máquina, não de um humano.

Se um humano está escrevendo código em que precisa reutilizar nomes dentro da mesma função, eu diria que esses blocos provavelmente precisam ser funções separadas. Especialmente se esses nomes estiverem sendo usados ​​com tipos e / ou significados diferentes dentro desses blocos.


10

Não é uma prática ruim criar blocos como este. É como os escopos funcionam.

Geralmente, isso é feito ao usar RAII (Aquisição de recursos é inicialização) e você deseja controlar quando os destruidores são chamados.

Se demorar, eu consideraria mover esse código para sua própria função.

Na minha opinião, apenas usá-lo para reciclar nomes de variáveis ​​não é uma boa ideia. Mas posso ver que foi útil em casos com pouca memória


A reutilização de nomes de variáveis ​​locais não afeta o uso da memória.
kevin Cline

1
Você não acha que um otimizador inteligente poderia usar 1 local de memória para as 2 variáveis?
Robert Andrzejuk 2/11

3
Sim. Mas isso também pode ser feito se estiverem no mesmo escopo, se não tiverem destruidores.
Sebastian Redl
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.