Regole della struttura. Imparare a strutturare i programmi, esplorare le possibilità, gli errori, le soluzioni, ecc.
Regole della struttura. Il contenuto è secondario, la struttura è primaria.
Il mio "pannello" ha la struttura più semplice: Evento -> Gestione
Anche gli eventi sono semplici: pressioni di tasti, selezioni di liste, selezioni di calendari, movimenti del mouse, ecc.
Un problema abbastanza tipico per iniziare a progettare: come organizzare (strutturare) la gestione degli eventi in un programma in modo che esso (il programma) possa essere ulteriormente sviluppato e allo stesso tempo sia minima la rielaborazione di ciò che è già stato fatto.
Vuoi discutere delle opzioni?
Dal ramo"bug, bug, domande":
Un problema molto tipico per l'inizio della progettazione: come organizzare (strutturare) l'elaborazione degli eventi in un programma in modo che esso (il programma) possa essere ulteriormente sviluppato e allo stesso tempo rifare ciò che è già stato fatto con uno sforzo minimo.
Vuoi discutere delle opzioni?
Esiste una letteratura per esempio?
In generale, i problemi di progettazione si sovrappongono al CAD e al TRIZ.
Disegno su carta, quindi è più conveniente per me, a volte ci vogliono fino a 50 fogli fino a quando non si ottiene una struttura chiara. Può certamente in spets.editors, ma ognuno di loro per me scomodo (limitato), impossibile realizzare un volo di fantasia, in breve, rallentare il lavoro.
- ru.wikipedia.org
Ho l'opzione più semplice
int main() { while ( !IsStopped() ) { switch ( GetEvent() ) { case TIMER : case BUTTON : case LISTVIEW: case CALENDAR: case CLOSE : case ERROR : default : } } }
cosa si intende per struttura?
ZS: Mi è stato insegnato così:
1. Tutto ciò che si può fare in una funzione è in una funzione.
2. goto è un peccato
3. Tutte le condizioni devono essere minime e non ci deve essere alcuna sovrapposizione in una condizione
4. 3. rientro
5. bisogna scrivere in modo tale che gli altri possano leggerlo dopo di te
6. nomi di variabili chiari e significativi
7. commenti, ma senza esagerare
come questo, ma non come questo: http://korzh.net/2011-03-pravila-xoroshego-tona-v-programmirovanii.html
- korzh.net
Esiste una letteratura per esempio?
In generale, i problemi di progettazione si sovrappongono al CAD e al TRIZ.
Disegno su carta, è più conveniente per me, a volte fino a 50 fogli sono spesi fino a quando una struttura chiara emerge. Si possono, naturalmente, usare editor speciali, ma ognuno di essi è scomodo per me (limitato), è impossibile realizzare un volo di fantasia, insomma rallentano il lavoro.
Il CAD non è esattamente la stessa cosa, ma è la progettazione assistita dal computer.
Prima di scrivere un programma, mi hanno insegnato a fare uno schema su carta, un linguaggio algo semplificato, ma non ci sono abituato.
Primo arrivato, primo servito :). Perché non cominci a dirci com'è per te?
Beh, sospettavo che sarebbe stato il caso... ))
OK, non ho molto da nascondere (in termini di strutturazione), non ho paura della discussione.
Ma non vi consiglio di assumere immediatamente o di criticare frettolosamente - non assumo "esemplari" e nemmeno alcun tipo di armonia nelle mie decisioni - nella loro massa, non sono particolarmente fondate e generate dagli stessi fattori "religiosi" - abitudini, "verità di libri", articoli di forum, campioni di consegne terminali standard e altra spazzatura spontanea aggregata nella testa. Ho alcune scoperte, ma niente di troppo serio.
Per cominciare, vorrei proporre un paio di termini convenienti, in modo che ci sia meno confusione (sospetto che ce ne sarà molta).
1) Struttura fisica del progetto: l'organizzazione di file, cartelle e altre entità visibili alla vista "esterna" del progetto.
2) Struttura logica del progetto: organizzazione di tutte le cose "interne" del software - variabili, funzioni, classi, protocolli, ecc.
-----------------
La struttura fisica dei miei progetti mql è molto semplice e primitiva. Cerco consapevolmente di farlo, per ridurre la confusione e minimizzare le conseguenze di una possibile confusione.
Di regola (per una di medie dimensioni) è un insieme di file .mqh (disposti in cartelle appropriate) + un file mq5.
// Se il sistema è multi-threaded (per esempio, nel caso più semplice, l'Expert Advisor + indicatori) - allora il numero di file mq5 corrisponde al numero di programmi nel progetto.
Cerco di non usare libs (.ex5). // Decisione molto controversa, ma lo faccio per minimizzare i problemi di runtime.
--
Mi asterrò dal commentare le strutture logiche del progetto per il momento - l'argomento è molto grande e ho bisogno di tirare il fiato... :)
Il CAD non è proprio la stessa cosa, ma è la progettazione assistita dal computer.
Mi hanno insegnato ad abbozzare un linguaggio algo semplificato prima di scrivere un programma, ma non mi ci sono mai abituato.
Cerco di visualizzare il problema nel suo insieme e di identificare gli oggetti principali che lo compongono.
Poi scompongo gli oggetti nelle loro componenti e cerco le intersezioni nelle componenti, e poi appaiono gli oggetti antenati.
Ecco come stanno le cose.
Se trovo alcune entità nel progetto, che sono già state incontrate, cerco di usare il vecchio codice verificato.
Se state parlando di design, smettete di litigare e adottate lo stile MQ, poi con un clic su un pulsante di styler avrete tutti lo stesso stile e tutto sarà comprensibile per tutti.
Cerco di non usare libs (.ex5). // Una soluzione molto controversa, ma lo faccio per minimizzare i problemi di runtime.
Cerco di visualizzare il compito nel suo insieme e di identificare gli oggetti principali che lo compongono.
Poi divido gli oggetti in componenti, cerco le intersezioni nei componenti, e poi appaiono gli oggetti antenati.
Ecco come stanno le cose.
Se trovo entità oggetto in un progetto che ho già visto, cerco di includere il vecchio codice verificato.
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Accetti la politica del sito e le condizioni d’uso
Dai programmi più semplici ai pacchetti software complessi.
--
Esorto i professionisti a sostenere questo thread.
Capisco l'immensità di un tema e la sua "carica religiosa"(*), e di conseguenza il possibile conflitto caotico e potenziale di un ramo.
Ciononostante chiedo sostegno perché tutti ne possono beneficiare - le idee sensate (ad alto potenziale) si trovano spesso nei cumuli di spazzatura, bisogna solo essere in grado di notarle e in tempo per "prenderle".
----
(*) Per "religiosamente carico" in questo contesto intendo il fatto che le strutture dei programmi sono spesso costruite dai programmatori su abitudini, tradizioni e fonti letterarie, ma non sul buon senso e sulle convenienze reali attese per se stessi e per altre persone (per esempio, futuri coautori).