Entrar
Últimos assuntos
» Preciso de ajudapor AftonDuGrau Dom 21 Abr 2024, 20:18
» Como faz o evento drawn GUI, não se repetir?
por aminaro Sex 19 Abr 2024, 20:30
» Como ajustar velocidade de cada frame da animação no game maker
por Ralphed Qui 18 Abr 2024, 18:28
» PROBLEMAS COM FÍSICAS DE ÁGUA
por aminaro Ter 16 Abr 2024, 10:07
» Retorno da GMBR!!!
por Ralphed Sex 12 Abr 2024, 22:45
» JOGADOR PARANDO NO AR QUANDO ATACA
por aminaro Qua 10 Abr 2024, 13:51
» Problemas com texto interativo
por Kaaru72 Dom 07 Abr 2024, 11:31
» Erro escondido e indecifrável
por dev_gabize.azv Qui 04 Abr 2024, 10:11
» Mudar cor de apenas uma palavra
por Ralphed Sáb 30 Mar 2024, 00:39
» Procuro Programador de game maker
por Wou Sex 15 Mar 2024, 10:27
» Mod APK
por gamerainha Qua 13 Mar 2024, 06:30
» Aceito pedidos de sprites (Com exemplos meus)
por Sevilha Qua 28 Fev 2024, 12:17
» Inventário simples
por Isquilo_Roedor Qui 22 Fev 2024, 15:18
» Problemas na programaçnao de inimigo [jogo DOOM LIKE]
por Black Mirror Dom 11 Fev 2024, 13:34
» ANDROID MULTI TOUCH
por DiegoBr Dom 04 Fev 2024, 12:13
» Servidor de Discord do fórum?
por Lighter Sáb 27 Jan 2024, 17:18
» Save e Load Json
por Klinton Rodrigues Qui 25 Jan 2024, 11:12
» Colisão com mais de um objeto
por aminaro Seg 22 Jan 2024, 15:02
» Oi sou novo aqui
por Thiago Silveira Alexandre Sáb 20 Jan 2024, 20:55
» Como acessar conteudo comprado no marketplace
por macmilam Sex 19 Jan 2024, 07:42
» Devlogs em vídeos do Block Room
por Joton Seg 15 Jan 2024, 16:56
» Alguém aqui já ganha dinheiro com seus games?
por Joton Seg 15 Jan 2024, 16:49
» ACERVO GMBR MAGAZINE
por Joton Qui 11 Jan 2024, 19:21
» como aumentar o obj sem aumentar a colisão??
por GabrielXavier Qua 10 Jan 2024, 07:21
» Asteroid Core - Early Acesse Update [0.2.0.0]
por JOZ. Seg 08 Jan 2024, 14:39
Organizando condições (if e else)
GMBR :: Ensine & Aprenda :: Tutoriais :: Game Maker
Página 1 de 1
Organizando condições (if e else)
Artigo escrito por Neorevolutions, originário do site:
http://developers3.webcindario.com/articles/view.php?id=29&title=Organizando+blocos+if-else&PHPSESSID=1cc292ca2319952b4338ed094b881e2b
Introdução
Todo programador utiliza blocos de if-else, isso é certeza. Mas nem todo programador sabe utiliza-lo de maneira legível ou organizada, sendo ele experiente ou iniciante.
Dependendo de como se escreve um programa ou script, pode haver a necessidade de se utilizar grandes quantidades de blocos condicionais. Se há somente um ou dois blocos dentro de outro, não há muito motivo para se alarmar, mas quando a cadeia de blocos começa a aumentar, a legibilidade do código começa a diminuir drasticamente.
Blocos dentro de blocos
Toda confusão com blocos if-else começa quando se faz necessário que um determinado código somente seja executado após passar por uma série de testes. E em algumas ocasiões, a cada teste que falha, se necessita mostrar o erro ao cliente. Para se ter uma idéia do problema, veja o código abaixo:
Esse código pode ser considerado horrível e o programador que escreve desta forma, deveria tentar corrigir o problema. Note que não existem tantos blocos if-else, mas mesmo assim dificulta um pouco seu entendimento.
Uma maneira melhor de se conseguir o mesmo objetivo do exemplo anterior, mas escrevendo de uma forma mais clara é não utilizando o else ou evitando de se colocar um bloco dentro de outro. Veja como ficaria o mesmo código escrito de outra forma.
Como pode ver, o bloco ficou mais legível, pois precisamos nos preocupar com um bloco de cada vez. No exemplo anterios teriamos que nos preocupar com o teste que está sendo lido no momento e também com os outros testes feitos anteriormente. Fica também mais dificil localizar onde está o código que irá ser executado se passar em todos os testes.
Além de tudo, o bloco else está muito longe de seu par, o que pode causar confusão em se saber qual else faz parte com um determinado if. Utilizando-se o segundo método pode eliminar ou pelo menos diminuir esse problema.
Esse primeiro exemplo não é dos piores, existem outros ainda mais confusos. Veja:
Esse código é dificil de se seguir por que os blocos de erro e estão misturados com os outros. Por este motivo, não é tão óbvio o caminho lógico a ser seguido. Um meio de se melhorar este código é utilizando o estilo do primeiro exemplo, mas isto também não seria a melhor solução. Veja como ficaria seguindo o estilo do primeiro exemplo:
Ficou mais legível, mas ainda não seria o ideal. Ainda há uma certa dificuldade em se perceber qual erro faz parte de qual teste. Para se aumentar a legibilidade, é prefirivel que este código fique isolado em uma função, retornando um status geral. Veja:
Perceba que ficou mais facil de se seguir a lógica pretendida e ainda melhorando a legibilidade desse código. Outro modo de se fazer a mesma coisa é o seguinte:
Este último código ficou ainda mais fácil de ser lido e entendido por qualquer um que o observe. Separando-se partes complexas em diferentes funções pode melhorar a legibilidade nos casos em que o tamanho das funções seja muito extenso.
Organizando conjuntos de testes
Outro problema que pode ocorrer num código é uma quantidade muito grande de testes relacionais ou lógicos. Isso tudo dentro de um único if.
Veja como seria um caso típico do problema:
Esse é um exemplo simples, então ainda é legível. Mas se houvesse mais operadores relacionais e lógicos, o código se tornaria mais complexo e, portanto, mais dificil de se entender.
Veja como criar um código mais legível se um dia encontrar uma situação parecida.
Este método clarifica o entendimento por ser mais fácil de se ler, pois fica parecido com uma lingua real ao invés de uma linguagem de programação.
O que seria mais fácil de se entender?
A: Se o indice for menor que zero ou o indice for maior que o máximo ou o indice é o mesmo que o anterior ou os dados não foram inseridos, então faça tal coisa.
B: Se o indice é inválido ou se o indice for repetido ou se os dados não foram inseridos, faça tal coisa.
Provavelmente respondeu B.
Hoje em dia, com a capacidade dos computadores, criar 3 ou 4 variáveis a mais praticamente não influencia na performance geral.
Conclusão
Todas estas informações são apenas dicas para todos os programadores que queiram melhorar seus códigos. Nada os impede de ignorá-las e seguir com o mesmo estilo. Mas será que há algo que o impeça de utilizá-los e criar códigos mais legíveis?
Assimo como qualquer dica, utilize apenas os que achar necessarios ou que for apropriado para cada situação.
http://developers3.webcindario.com/articles/view.php?id=29&title=Organizando+blocos+if-else&PHPSESSID=1cc292ca2319952b4338ed094b881e2b
Introdução
Todo programador utiliza blocos de if-else, isso é certeza. Mas nem todo programador sabe utiliza-lo de maneira legível ou organizada, sendo ele experiente ou iniciante.
Dependendo de como se escreve um programa ou script, pode haver a necessidade de se utilizar grandes quantidades de blocos condicionais. Se há somente um ou dois blocos dentro de outro, não há muito motivo para se alarmar, mas quando a cadeia de blocos começa a aumentar, a legibilidade do código começa a diminuir drasticamente.
Blocos dentro de blocos
Toda confusão com blocos if-else começa quando se faz necessário que um determinado código somente seja executado após passar por uma série de testes. E em algumas ocasiões, a cada teste que falha, se necessita mostrar o erro ao cliente. Para se ter uma idéia do problema, veja o código abaixo:
- Código:
if ( arquivo_existe )
{
if ( arquivo_aberto )
{
if ( ler_linha_do_arquivo )
{
if ( linha_valida )
{
print( linha );
}
else
{
print("Linha inválida");
}
}
else
{
print("Não foi possível ler a linha");
}
}
else
{
print("Arquivo não aberto");
}
}
else
{
print("Arquivo não existe");
}
Esse código pode ser considerado horrível e o programador que escreve desta forma, deveria tentar corrigir o problema. Note que não existem tantos blocos if-else, mas mesmo assim dificulta um pouco seu entendimento.
Uma maneira melhor de se conseguir o mesmo objetivo do exemplo anterior, mas escrevendo de uma forma mais clara é não utilizando o else ou evitando de se colocar um bloco dentro de outro. Veja como ficaria o mesmo código escrito de outra forma.
- Código:
if ( arquivo_existe == false )
{
print("Arquivo não existe");
return;
}
if ( arquivo_aberto == false )
{
print("Arquivo não aberto");
return;
}
if ( ler_linha_do_arquivo == false )
{
print("Não foi possível ler a linha");
return;
}
if ( linha_valida == false )
{
print("Linha inválida");
return;
}
print( linha );
Como pode ver, o bloco ficou mais legível, pois precisamos nos preocupar com um bloco de cada vez. No exemplo anterios teriamos que nos preocupar com o teste que está sendo lido no momento e também com os outros testes feitos anteriormente. Fica também mais dificil localizar onde está o código que irá ser executado se passar em todos os testes.
Além de tudo, o bloco else está muito longe de seu par, o que pode causar confusão em se saber qual else faz parte com um determinado if. Utilizando-se o segundo método pode eliminar ou pelo menos diminuir esse problema.
Esse primeiro exemplo não é dos piores, existem outros ainda mais confusos. Veja:
- Código:
string erro;
status resultado;
resultado = abrir_arquivo( arquivo );
if ( resultado == status_erro )
{
erro = "Arquivo nao aberto";
}
else
{
resultado = ler_arquivo(arquivo, dados);
if ( resultado == status_ok )
{
resultado = mostrar_dados( dados );
if ( resultado == status_erro )
{
erro = "Dados invalidos";
}
else
{
resultado = salvar_dados( dados );
if ( resultado == status_erro )
{
erro = "Dados não salvos";
}
else
{
limpar_dados( dados );
erro = "Nenhum";
}
}
}
else
{
erro = "Erro de leitura";
}
}
Esse código é dificil de se seguir por que os blocos de erro e estão misturados com os outros. Por este motivo, não é tão óbvio o caminho lógico a ser seguido. Um meio de se melhorar este código é utilizando o estilo do primeiro exemplo, mas isto também não seria a melhor solução. Veja como ficaria seguindo o estilo do primeiro exemplo:
- Código:
string erro;
status resultado;
resultado = abrir_arquivo( arquivo );
if ( resultado == status_ok )
{
resultado = ler_arquivo(arquivo, dados);
if ( resultado == status_ok )
{
resultado = mostrar_dados( dados );
if ( resultado == status_ok )
{
resultado = salvar_dados( dados );
if ( resultado == status_ok )
{
limpar_dados( dados );
erro = "Nenhum";
}
else
{
erro = "Dados não salvos";
}
}
else
{
erro = "Dados invalidos";
}
}
else
{
erro = "Erro de leitura";
}
}
else
{
erro = "Arquivo nao aberto";
}
Ficou mais legível, mas ainda não seria o ideal. Ainda há uma certa dificuldade em se perceber qual erro faz parte de qual teste. Para se aumentar a legibilidade, é prefirivel que este código fique isolado em uma função, retornando um status geral. Veja:
- Código:
tipo_de_erro processar_arquivo( arquivo )
{
status resultado;
resultado = abrir_arquivo( arquivo );
if ( resultado == status_erro )
return Erro_Arquivo_Nao_Aberto;
resultado = ler_arquivo(arquivo, dados);
if ( resultado == status_erro )
return Erro_Arquio_Nao_Lido;
resultado = mostrar_dados( dados );
if ( resultado == status_erro )
return Erro_Dados_Invalidos;
resultado = salvar_dados( dados );
if ( resultado == status_erro )
return Erro_Dados_Nao_Salvos;
limpar_dados( dados );
return Erro_Nenhum;
}
Perceba que ficou mais facil de se seguir a lógica pretendida e ainda melhorando a legibilidade desse código. Outro modo de se fazer a mesma coisa é o seguinte:
- Código:
tipo_de_erro processar_arquivo( arquivo )
{
if ( abrir_arquivo( arquivo ) == status_erro )
return Erro_Arquivo_Nao_Aberto;
if ( ler_arquivo(arquivo, dados) == status_erro )
return Erro_Arquio_Nao_Lido;
if ( mostrar_dados( dados ) == status_erro )
return Erro_Dados_Invalidos;
if ( salvar_dados( dados ) == status_erro )
return Erro_Dados_Nao_Salvos;
limpar_dados( dados );
return Erro_Nenhum;
}
Este último código ficou ainda mais fácil de ser lido e entendido por qualquer um que o observe. Separando-se partes complexas em diferentes funções pode melhorar a legibilidade nos casos em que o tamanho das funções seja muito extenso.
Organizando conjuntos de testes
Outro problema que pode ocorrer num código é uma quantidade muito grande de testes relacionais ou lógicos. Isso tudo dentro de um único if.
Veja como seria um caso típico do problema:
- Código:
if (
indice < 0 ||
indice > maximo ||
indice == ultimo_indice ||
dados_inseridos == false )
{
print("Dados invalidos");
}
Esse é um exemplo simples, então ainda é legível. Mas se houvesse mais operadores relacionais e lógicos, o código se tornaria mais complexo e, portanto, mais dificil de se entender.
Veja como criar um código mais legível se um dia encontrar uma situação parecida.
- Código:
bool indice_invalido = (indice < 0 || indice > maximo);
bool indice_repetido = (indice == ultimo_indice);
bool dados_inexistentes = (dados_inseridos == false );
if ( indice_invalido || indice_repetido || dados_inexistentes)
print("Dados invalidos");
Este método clarifica o entendimento por ser mais fácil de se ler, pois fica parecido com uma lingua real ao invés de uma linguagem de programação.
O que seria mais fácil de se entender?
A: Se o indice for menor que zero ou o indice for maior que o máximo ou o indice é o mesmo que o anterior ou os dados não foram inseridos, então faça tal coisa.
B: Se o indice é inválido ou se o indice for repetido ou se os dados não foram inseridos, faça tal coisa.
Provavelmente respondeu B.
Hoje em dia, com a capacidade dos computadores, criar 3 ou 4 variáveis a mais praticamente não influencia na performance geral.
Conclusão
Todas estas informações são apenas dicas para todos os programadores que queiram melhorar seus códigos. Nada os impede de ignorá-las e seguir com o mesmo estilo. Mas será que há algo que o impeça de utilizá-los e criar códigos mais legíveis?
Assimo como qualquer dica, utilize apenas os que achar necessarios ou que for apropriado para cada situação.
M.A.S.- Data de inscrição : 03/01/2009
Reputação : 0
Número de Mensagens : 377
Prêmios :
x 0 x 0 x 0
x 0 x 0 x 0
x 0 x 0 x 0
GMBR :: Ensine & Aprenda :: Tutoriais :: Game Maker
Página 1 de 1
Permissões neste sub-fórum
Não podes responder a tópicos
|
|