Programmazione del tramonto? - pagina 17

Nuovo commento
 
Alexandr Andreev:

Naturalmente, è più facile analizzare il codice conoscendo lo schema che non conoscendo lo schema.

Tecnicamente sarebbe anche conveniente avere una specie di visualizzatore di codice... Soprattutto se uno non annulla l'altro ma lo completa.

Sono d'accordo.
 
Così siamo giunti alla conclusione che anche se un cavallo lavora di più in una fattoria collettiva, non serve a niente senza un buon stalliere.
 
Ma bisogna elaborare molto bene l'usabilità del tutto. E capire cosa è più spesso necessario. Cioè non ha senso mostrare tutto il casino di tutte le interrelazioni, perché ci possono essere 20 eredità (in profondità) dell'oggetto con molti allegati, ricariche. Ma per vedere dove questo oggetto è menzionato nelle strutture parentali o dove viene inizializzato se abbiamo scritto l'inizializzazione esterna dettagliata dell'oggetto nel codice in analisi. O creare rapidamente una nuova entità intermedia con il ricaricamento di certe funzioni e capire che non hai fatto errori in quelle madri. Anche se di solito questo compito è gestito dalla ricerca o dal compilatore
 
Alexandr Andreev:

Naturalmente, è più facile analizzare il codice conoscendo lo schema che non conoscendo lo schema.

Tecnicamente sarebbe anche conveniente avere una specie di visualizzatore di codice... Soprattutto se uno non annulla l'altro ma lo completa.

Ma perché non fare un vero e proprio visualizzatore di codice che sia autosufficiente?

Pensate a un bel linguaggio grafico per la rappresentazione del codice, una buona navigazione in esso, decidete la priorità delle informazioni da visualizzare (le informazioni più importanti richiedono meno sforzi per visualizzarle, meno importanti al contrario). Avete anche bisogno di un'analisi approfondita del codice.

Non sarà facile di sicuro. OK, so che è improbabile che si arrivi all'attuazione...

 
Aliaksandr Hryshyn:

Perché non fare un vero e proprio visualizzatore di codice che sia autosufficiente?

Pensate a un linguaggio grafico per la presentazione del codice, pensate a una buona navigazione in esso, decidete la priorità delle informazioni visualizzate (le informazioni più importanti richiedono meno sforzo di visualizzazione, meno importanti - al contrario). Avete anche bisogno di un'analisi approfondita del codice.

Non sarà facile. OK, so che è improbabile che si arrivi all'attuazione...

Ci sono programmi come il design 3D per le raffinerie di petrolio. Hanno un diagramma dei collegamenti delle tubazioni. Per gli ingegneri di processo esperti, è più facile leggere una pila di disegni che un singolo diagramma "visivo", ma dopo un po' ci si abitua. Voglio dire che il codice complicato sarà ancora difficile da comprendere in caso di visualizzazione. Se si seguono tutte le regole, il codice è abbastanza facile da leggere nella sua forma originale.
 
Aliaksandr Hryshyn:

Perché non fare un vero e proprio visualizzatore di codice che sia autosufficiente?

Pensate a un linguaggio grafico per la rappresentazione del codice, pensate a una buona navigazione in esso, decidete la priorità delle informazioni da visualizzare (le informazioni più importanti richiedono meno sforzo di visualizzazione, meno importanti - al contrario). Avete anche bisogno di un'analisi approfondita del codice.

Non sarà facile. Beh, so che è improbabile che si realizzi...

Con la possibilità di creare le mie impostazioni con il mio codice e il mio design visivo, e usando modelli di design visivo già pronti di altri, si chiama pigrizia scrivere un paio di righe)))

Nella programmazione, il mio primo luogo di utilizzo è probabilmente il caricamento delle funzioni. Ma nel codice tutto è comunque molto breve, scrivere il nuovo nome, scrivere da dove ereditiamo (e di solito è un template), scrivere cosa e con cosa lo sostituiamo. Questo è tutto!

Penso che queste stranezze cresceranno rapidamente in un'enorme biblioteca e sarà difficile ricordarle tutte.

 
Реter Konow:
Sì, ma la sua direzione è corretta. La codifica è un canale stretto per sfruttare il potenziale del cervello. Lo schema descritto dal codice è compreso centinaia di volte più a lungo dello stesso schema percepito dagli occhi. Immaginate la rotazione di una pallavolo che su ogni cerchio rallenta e aumenta leggermente l'angolo di inclinazione. Descrivere questo processo con formule in codice e filmarlo con una telecamera. Misurate il tempo che impiega il programmatore a capire che si tratta della stessa cosa.

Ognuno ha i suoi approcci. Personalmente, trovo diagrammi solo leggermente fastidiosi) mi piace molto di più l'approccio della programmazione letteraria di Donald Knuth (tradotto in russo come "letterato" per qualche motivo) e il modo in cui è implementato, per esempio, nel linguaggio R (R Markdown).

Ti sbagli a scrivere di una trottola) È un problema di meccanica irrisolto - non esiste una formula generale per il moto (anche se trascuri l'attrito).

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:

Ti sbagli a scrivere di una trottola) È un problema di meccanica irrisolto - non c'è una formula generale per il moto (anche se si ignora l'attrito).

E la pietra celtica è anche una voluta)

 
Aleksey Nikolayev:

...

Ti sbagli a scrivere di una trottola) È un problema di meccanica irrisolto - non c'è una formula generale per il moto (anche se trascuri l'attrito).

In qualche modo non ci ho pensato. )

 
Aleksey Mavrin:
Ci sono programmi software come il design 3D per le raffinerie di petrolio. Hanno un diagramma dei collegamenti delle tubazioni. Per un ingegnere di processo esperto è più facile leggere un mucchio di disegni che un singolo diagramma "visivo", poi ci si abitua. Voglio dire che il codice complicato sarà ancora difficile da comprendere in caso di visualizzazione. Se si seguono tutte le regole, il codice è abbastanza facile da leggere nella sua forma originale.

Vi chiedete perché le due visualizzazioni del codice qui sotto sono percepite in modo diverso:

//+------------------------------------------------------------------+
//| 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);
  }

Successivamente, rimuovete l'orpello grafico. Meno il colore, meno il rientro (posizionamento relativo).

//inizializzazione degli indicatori

bool CSampleExpert::InitIndicators(void)

{

//crea l'indicatore MACD

if(m_handle_macd==INVALID_HANDLE)

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

{

printf("Errore nella creazione dell'indicatore MACD");

return(false);

}

//crea l'indicatore EMA e aggiungilo alla collezione

if(m_handle_ema==INVALID_HANDLE)

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

{

printf("Errore nella creazione dell'indicatore EMA");

return(false);

}

//successo

return(true);

}

La leggibilità è notevolmente peggiore. Questo suggerisce che la rappresentazione grafica può migliorare notevolmente la leggibilità. Non sto parlando specificamente di diagrammi, ci potrebbero essere molte opzioni.
1...1011121314151617181920212223
Nuovo commento