Regras de estrutura. Aprender a estruturar programas, explorar possibilidades, erros, soluções, etc.
Regras de estrutura. O conteúdo é secundário, a estrutura é primária.
O meu "Painel" tem a estrutura mais simples: Evento -> Manuseamento
Os eventos também são simples: pressão de botões, selecção de listas, selecção de calendários, movimentos do rato, etc.
Um problema típico para começar a conceber: como organizar (estruturar) o tratamento de eventos num programa para que este (o programa) possa ser mais desenvolvido e, ao mesmo tempo, um retrabalho mínimo do que já foi feito.
Quer discutir opções?
Do ramo"insectos, insectos, perguntas":
Um problema muito típico para o início da concepção: como organizar (estruturar) o processamento de eventos num programa para que este (o programa) possa ser mais desenvolvido e, ao mesmo tempo, refazer ao mínimo o que já foi feito.
Quer discutir opções?
Existe alguma literatura, por exemplo?
Em geral, as questões de design sobrepõem-se ao CAD e ao TRIZ.
Desenho em papel, por isso é mais conveniente para mim, por vezes demora até 50 folhas até que uma estrutura clara seja feita. Pode certamente em spets.editors, mas cada um deles para mim desconfortável (limitado), impossível de realizar um voo de fantasia, em suma, atrasar o trabalho.
- ru.wikipedia.org
Eu tenho a opção mais simples
int main() { while ( !IsStopped() ) { switch ( GetEvent() ) { case TIMER : case BUTTON : case LISTVIEW: case CALENDAR: case CLOSE : case ERROR : default : } } }
o que se entende por estrutura?
ZS: Fui ensinado desta forma:
1. tudo o que se pode fazer numa função está numa função.
2. goto é um pecado
3. todas as condições devem ser mínimas e não deve haver qualquer sobreposição numa única condição
4. 3. travessão
5. é preciso escrever de forma a que outros o possam ler depois de si
6. nomes de variáveis claras e significativas
7. comentários, mas não exagere
assim, mas não exactamente assim: http://korzh.net/2011-03-pravila-xoroshego-tona-v-programmirovanii.html
- korzh.net
Existe alguma literatura, por exemplo?
Em geral, as questões de design sobrepõem-se ao CAD e ao TRIZ.
Desenho sobre papel, é mais conveniente para mim, por vezes gastam-se até 50 folhas até surgir uma estrutura clara. Pode, claro, utilizar editores especiais, mas cada um deles é inconveniente (limitado) para mim, é impossível realizar um voo de fantasia, em suma, eles atrasam o trabalho.
O CAD não é exactamente o mesmo, mas é um desenho assistido por computador.
Antes de escrever um programa, fui ensinado a fazer um esboço em papel, uma linguagem simplificada, mas não estou habituado a isso.
Primeiro a chegar, primeiro a ser servido :). Porque não começa por nos dizer como é para si?
Bem, suspeitei que seria esse o caso... ))
OK, não tenho muito a esconder (em termos de estruturação), não tenho medo da discussão.
Mas não recomendo que assumam imediatamente ou critiquem apressadamente - não assumo "exemplar" ou mesmo qualquer tipo de harmonia nas minhas decisões - na sua massa, não são especialmente bem fundamentadas e geradas pelos mesmos factores "religiosos" - hábitos, "verdades do livro", artigos de fórum, amostras de entrega terminal padrão e outros resíduos agregados espontâneos na cabeça. Tenho algumas descobertas, mas nada demasiado sério.
Para começar, gostaria de propor alguns termos convenientes, para que houvesse menos confusão (suspeito que haverá muita).
1) Estrutura física do projecto: A organização de ficheiros, pastas e outras entidades visíveis na visão "exterior" do projecto.
2) Estrutura lógica do projecto: Organização de todo o material "interno" do software - variáveis, funções, classes, protocolos, etc.
-----------------
A estrutura física dos meus projectos de mql é muito simples e primitiva. Tento fazer isto conscientemente, para reduzir a confusão e minimizar as consequências de uma possível confusão.
Como regra (para um de tamanho médio) é um conjunto de ficheiros .mqh (dispostos em pastas apropriadas) + um ficheiro mq5.
// Se o sistema for multi-threaded (por exemplo, no caso mais simples, o Expert Advisor + indicadores) - então o número de ficheiros mq5 corresponde ao número de programas no projecto.
Tento não usar libs (.ex5) // Decisão muito controversa, mas faço-o para minimizar os problemas de tempo de execução.
--
Abster-me-ei de comentar as estruturas lógicas do projecto por agora - o assunto é muito grande e preciso de tirar o meu fôlego... :)
O CAD não é bem o mesmo, mas é um desenho assistido por computador.
Ensinaram-me a esboçar uma linguagem simplificada antes de escrever um programa, mas nunca me habituei a ela.
Tento visualizar o problema como um todo, e identificar os principais objectos que constituem o problema.
Depois decomponho os objectos nos seus componentes e procuro intersecções nos componentes, e depois aparecem os objectos dos antepassados.
É assim que as coisas são.
Se encontro algumas entidades no projecto, que já foram encontradas, tento utilizar código antigo e verificado.
Se estiver a falar de design, basta parar de lutar e adoptar o estilo MQ, então um clique de um botão de estilo dar-lhe-á a todos o mesmo estilo e tudo será compreensível para todos.
Tento não usar libs (.ex5) // Uma solução muito controversa, mas faço-o para minimizar problemas de tempo de execução.
Tento visualizar a tarefa como um todo, e identificar os principais objectos que a compõem.
Depois divido os objectos em componentes, procuro intersecções nos componentes, e depois aparecem os objectos dos antepassados.
É assim que é.
Se encontro entidades objecto num projecto que já vi antes, tento incluir o antigo código verificado.
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso
Desde os programas mais simples até pacotes de software complexos.
--
Exorto os profissionais a apoiarem este fio.
Compreendo a imensidão de um tema e a sua "carga religiosa"(*), e consequentemente o possível caótico e potencial conflito de um ramo.
No entanto, peço apoio porque todos podem beneficiar - ideias sensatas (com elevado potencial) são muitas vezes encontradas em montes de lixo, basta ser capaz de reparar e a tempo de "apanhar".
----
(*) Por "religiosamente carregado" neste contexto entendo o facto de que as estruturas dos programas são frequentemente construídas por programadores sobre hábitos, tradições e fontes literárias, mas não sobre o senso comum e as conveniências reais esperadas para si próprio e para outras pessoas (por exemplo, futuros co-autores).