Programação ao pôr-do-sol? - página 17

Novo comentário
 
Alexandr Andreev:

Naturalmente, é mais fácil analisar o código conhecendo o esquema do que não conhecendo o esquema.

Tecnicamente, até seria conveniente ter algum tipo de visualizador de código. especialmente se uma não cancelar a outra, mas complementá-la.

Eu concordo.
 
Assim, chegamos à conclusão de que embora um cavalo trabalhe mais em uma fazenda coletiva, ele não tem nenhuma utilidade sem um bom noivo.
 
Mas você tem que trabalhar muito bem a usabilidade de tudo isso. E compreender o que é mais freqüentemente necessário. Ou seja, não faz sentido mostrar toda a confusão de todas as inter-relações, pois pode haver 20 heranças (em profundidade) do objeto com muitos anexos, recargas. Mas para ver onde este objeto é mencionado nas estruturas pai ou onde é inicializado se tivermos uma inicialização externa detalhada do objeto no código em análise. Ou crie rapidamente uma nova entidade intermediária com recarga de certas funções e entenda que você não cometeu erros nas funções de parentalidade. Embora geralmente esta tarefa seja realizada por busca ou compilação
 
Alexandr Andreev:

Naturalmente, é mais fácil analisar o código conhecendo o esquema do que não conhecendo o esquema.

Tecnicamente, até seria conveniente ter algum tipo de visualizador de código. especialmente se uma não cancelar a outra, mas complementá-la.

Mas por que não fazer um visualizador de código completo, que seria auto-suficiente?

Pense em uma linguagem gráfica agradável para a representação do código, boa navegação nele, decida a prioridade das informações a serem exibidas (informações mais importantes requerem menos esforços para exibi-las, menos importantes pelo contrário). Você também precisa de uma análise completa do código.

Não será fácil. Sei que é improvável que venha a ser implementado.

 
Aliaksandr Hryshyn:

Por que não fazer um visualizador de código completo que seja auto-suficiente?

Pense em uma linguagem gráfica para representação de código, pense em uma boa navegação nela, decida a prioridade da informação a ser exibida (mais informação importante requer menos esforço para ser exibida, menos importante - pelo contrário). Você também precisa de uma análise completa do código.

Não será fácil, com certeza. Sei que é improvável que venha a ser implementado.

Existem programas como o projeto 3D para refinarias de petróleo. Eles têm um diagrama de conexões de tubulações. Para engenheiros de processo experientes, é mais fácil ler uma pilha de desenhos do que um único diagrama "visual", mas eles se acostumam com isso depois de um tempo. O código complicado ainda será difícil de compreender em caso de visualização. Se você seguir todas as regras, o código é bastante fácil de ler em sua forma original.
 
Aliaksandr Hryshyn:

Por que não fazer um visualizador de código completo que seja auto-suficiente?

Pense em uma linguagem gráfica para representação de código, pense em uma boa navegação nela, decida a prioridade da informação a ser exibida (mais informação importante requer menos esforço para ser exibida, menos importante - pelo contrário). Você também precisa de uma análise completa do código.

Não será fácil, com certeza. Bem, eu sei que é improvável que venha a se dar conta...

Com a possibilidade de criar minhas próprias configurações com meu próprio código e design visual, e usando modelos de design visual prontos de outros, chama-se preguiça de escrever algumas linhas))))

Na programação, meu primeiro lugar a ser usado provavelmente é a recarga de funções. Mas no código tudo é muito breve de qualquer forma, escreva o novo nome, escreva de onde herdamos (e geralmente é um modelo), escreva o que e com o que o substituímos. Isso é tudo!

Acho que estas peculiaridades se transformarão rapidamente em uma enorme biblioteca e será difícil lembrar de todas elas.

 
Реter Konow:
Sim, mas sua direção é correta. A codificação é um canal estreito para aproveitar o potencial do cérebro. O padrão descrito pelo código é entendido centenas de vezes mais do que o mesmo padrão percebido pelos olhos. Imagine a rotação de uma voleia que em cada círculo abranda e aumenta ligeiramente o ângulo de inclinação. Descreva este processo com fórmulas em código e filme-o em uma câmera. Medir o tempo que o programador leva para perceber que isto é a mesma coisa.

Cada um tem suas próprias abordagens. Pessoalmente, acho os diagramas apenas um pouco irritantes) gosto muito mais da abordagem da programação literária de Donald Knuth (traduzida em russo como "alfabetizada" por alguma razão) e da forma como ela é implementada, por exemplo, na linguagem R (R Markdown).

Você está errado ao escrever sobre um spinner) É um problema mecânico não resolvido - não há fórmula geral para o movimento (mesmo que você negligencie o atrito).

Literate programming - Wikipedia
Literate programming - Wikipedia
  • en.wikipedia.org
The literate programming paradigm, as conceived by Knuth, represents a move away from writing computer programs in the manner and order imposed by the computer, and instead enables programmers to develop programs in the order demanded by the logic and flow of their thoughts.[2] Literate programs are written as an uninterrupted exposition of...
 
Aleksey Nikolayev:

Você está errado ao escrever sobre um spinner) É um problema mecânico não resolvido - não há fórmula geral para o movimento (mesmo que você ignore o atrito).

E a pedra celta é também uma voluta )

 
Aleksey Nikolayev:

...

Você está errado ao escrever sobre um spinner) É um problema mecânico não resolvido - não há fórmula geral para o movimento (mesmo que você negligencie o atrito).

De alguma forma eu não pensei sobre isso. )

 
Aleksey Mavrin:
Existem programas de software como o desenho 3D para refinarias de petróleo. Eles têm um diagrama de conexões de tubulação. É mais fácil para um engenheiro de processos experiente ler uma pilha de desenhos do que um único diagrama "visual", então eles se acostumam a ele. O código complicado ainda será difícil de compreender em caso de visualização. Se você seguir todas as regras, o código é bastante fácil de ler em sua forma original.

Você se pergunta por que os dois códigos exibidos abaixo são percebidos de maneira diferente:

//+------------------------------------------------------------------+
//| Initialization of the indicators                                 |
//+------------------------------------------------------------------+
bool CSampleExpert::InitIndicators(void)
  {
//--- create MACD indicator
   if(m_handle_macd==INVALID_HANDLE)
      if((m_handle_macd=iMACD(NULL,0,12,26,9,PRICE_CLOSE))==INVALID_HANDLE)
        {
         printf("Error creating MACD indicator");
         return(false);
        }
//--- create EMA indicator and add it to collection
   if(m_handle_ema==INVALID_HANDLE)
      if((m_handle_ema=iMA(NULL,0,InpMATrendPeriod,0,MODE_EMA,PRICE_CLOSE))==INVALID_HANDLE)
        {
         printf("Error creating EMA indicator");
         return(false);
        }
//--- succeed
   return(true);
  }

Em seguida, remova o gráfico 'tinsel'. Menos a cor, menos a indentação (posicionamento relativo).

//Inicialização dos indicadores

Bool CSampleExpert::InitIndicators(void)

{

//criar o indicador MACD

if(m_handle_macd==INVALID_HANDLE)

if((m_handle_macd=iMACD(NULL,0,12,26,9,PRICE_CLOSE))==INVALID_HANDLE)

{

printf("Error creating MACD indicator");

retorno(falso);

}

//criar o indicador EMA e adicioná-lo à coleta

if(m_handle_ema==INVALID_HANDLE)

if((m_handle_ema=iMA(NULL,0,InpMATrendPeriod,0,MODE_EMA,PRICE_CLOSE))==INVALID_HANDLE)

{

printf("Indicador de erro criando EMA");

retorno(falso);

}

//succeed

retorno(true);

}

A legibilidade é visivelmente pior. Isto sugere que a representação gráfica pode melhorar notavelmente a legibilidade. Não estou falando especificamente de diagramas, poderia haver muitas opções.
1...1011121314151617181920212223
Novo comentário