71 risposte a questa discussione

[trallallero]

A proposito, avete mai visto del codice boost ?

[Killer application]

No, e non so nemmeno cosa sia .
Servirebbe la testimonianza di un altro Uk worker per spostare l'ago della bilancia.

A quanto vedo devo prepararmi per progrettare con metodi estremi e metodi normali.

Chi vivrà vedrà

[TigerShark]

Si certo, belle parole che vanno bene per il cicletto da 0 a n.

Se devi gestire i disturbi di n frequenze di n radio di n soldati in n carro armati in una zona con n jamming areas, un cicletto++ non ti basta.

Per capire cosa ho fatto in sto ciclo, se non l'avessi commentato, dopo un anno ci metterei ore (ho tolto i commenti per lasciare la sensazione di buio ).

for ( list::const_iterator itFreq = m_FreqsToBeDisturbedList.begin(); itFreq != m_FreqsToBeDisturbedList.end(); ++itFreq )

	{

		LL_ID id;

		LLMatrixUser::IsFreqTalking( *itFreq, &id );



		if (id > 0)

		{

			LogL.Write(LogLib::LOGLIB_WARNING_MSG, LOGLIB_FIX_ARGS, 0, "Freq talking: ", *itFreq);



			LLPanel* pPan = LLPanelHandler::GetEntity(id);



			if (pPan)

			{

				unsigned int MatId = LLMatrixClientHandler::GetClientId(pPan->GetName());



				if (MatId)

				{

					vector EnabledColumns;

					LLMatrixClientHandler::GetListeners( EnabledColumns, MatId );



					for ( vector::iterator x = EnabledColumns.begin(); x != EnabledColumns.end(); ++x )

						LogL.Write(LogLib::LOGLIB_WARNING_MSG, LOGLIB_FIX_ARGS, 0, "Listner id: ", *x);





					if (EnabledColumns.size() > 0)

					{

						m_Freq_TalkId_DisturbedIdsMap[(*itFreq)].insert(make_pair(MatId, EnabledColumns));



						for (  mapFreq_TalkId_DisturbedIds::iterator x = m_Freq_TalkId_DisturbedIdsMap.begin();

						       x != m_Freq_TalkId_DisturbedIdsMap.end();

						       ++x )

						{

							for ( map<unsigned int, vector >::iterator y = x->second.begin(); y != x->second.end(); ++y )

							{

								for ( vector::iterator o = y->second.begin(); o != y->second.end(); ++o )

								{

									QMap qmFadeMap;



									if (pPan->panelType() == PT_Laks)

									{

										LogL.Write(LogLib::LOGLIB_WARNING_MSG, LOGLIB_FIX_ARGS, 0, "DISTURB - talker PT_Laks");



										qmFadeMap[y->first]        = 0;

										qmFadeMap[m_NoiseClientId] = 100;

									}

									else

									{

										LLMatrixClient* c = LLMatrixClientHandler::GetClient((*o));

										if (c)

										{

											LogL.Write(LogLib::LOGLIB_WARNING_MSG, LOGLIB_FIX_ARGS, 0, "DISTURB - listener: ", c->GetName_c_str());



											LLPanel* p = LLPanelHandler::GetEntity(c->GetName());

											if (p && p->panelType() == PT_Laks)

											{

												LogL.Write(LogLib::LOGLIB_WARNING_MSG, LOGLIB_FIX_ARGS, 0, "DISTURB - listener PT_Laks");



												qmFadeMap[y->first]        = 0;

												qmFadeMap[m_NoiseClientId] = 100;

											}

											else

											{

												LogL.Write(LogLib::LOGLIB_WARNING_MSG, LOGLIB_FIX_ARGS, 0, "DISTURB - listener NO PT_Laks");



												qmFadeMap[y->first]        = 50;

												qmFadeMap[m_NoiseClientId] = 10;

											}

										}

									}

									GetClientInterface()->fadingAudioStream( (*o), qmFadeMap );

								}

							}

						}

					}

				}

			}

		}

	}

infatti questo per me e' l'esatto esempio di come un buon codice NON deve essere.
Non esiste alcun codice complesso, e' sempre possibile semplificarlo.
Se provi a scrivere un codice con una tale complessita' ciclomatica da noi ti prendono a calci in culo....
Divide et impera e' la chiave, e, mentre mia madre succhia cazzi, oGNI problema puo' essere scomposto in sottoproblemi piu' semplici.

[trallallero]

infatti questo per me e' l'esatto esempio di come un buon codice NON deve essere.
Non esiste alcun codice complesso, e' sempre possibile semplificarlo.
Se provi a scrivere un codice con una tale complessita' ciclomatica da noi ti prendono a calci in culo....
Divide et impera e' la chiave, e, mentre mia madre succhia cazzi, oGNI problema puo' essere scomposto in sottoproblemi piu' semplici.

Ne abbiamo di esperienza da fare, eh ?

Se non sei capace a scrivere un paio di for annidate per risolvere un problema complesso, qua non ti prendono proprio, altro che calci in culo.

In C++ vector, list, maps, pair, etc si usano proprio in questo modo e servono a risolvere in poche righe problemi complessi.

Anche io tendo a preferire la leggibilità del codice, ma succede che dividendo la complessità di un singolo problema in più punti, si perda di vista il problema.
In questo caso infatti è preferibile gestire i disturbi delle frequenze in un unico punto con un ciclo complesso (ma neanche tanto) ma commentato. Il giorno che ci si dovrà mettere mano, lo si capirà in 5 minuti.

[TigerShark]

?[/url]":50jlv15r]
infatti questo per me e' l'esatto esempio di come un buon codice NON deve essere.
Non esiste alcun codice complesso, e' sempre possibile semplificarlo.
Se provi a scrivere un codice con una tale complessita' ciclomatica da noi ti prendono a calci in culo....
Divide et impera e' la chiave, e, mentre mia madre succhia cazzi, oGNI problema puo' essere scomposto in sottoproblemi piu' semplici.

Ne abbiamo di esperienza da fare, eh ?

Se non sei capace a scrivere un paio di for annidate per risolvere un problema complesso, qua non ti prendono proprio, altro che calci in culo.

In C++ vector, list, maps, pair, etc si usano proprio in questo modo e servono a risolvere in poche righe problemi complessi.

Anche io tendo a preferire la leggibilità del codice, ma succede che dividendo la complessità di un singolo problema in più punti, si perda di vista il problema.
In questo caso infatti è preferibile gestire i disturbi delle frequenze in un unico punto con un ciclo complesso (ma neanche tanto) ma commentato. Il giorno che ci si dovrà mettere mano, lo si capirà in 5 minuti.

chi ha parlato di for?
Io parlo della complessita' ciclomatica che se non ho sbagliato i conti e' pari a 10 in quel codice.
fek ai tempi ci cassava tutti i metodi con complessita' ciclomatica > 3.
E questo avviene perche' non fai refactoring continuo del tuo codice.
All'inizio probabilmente anche i miei metodi fanno abbastana cagare, ma dopo un po' di refactoring la qualita' del codice aumenta di molto.

[trallallero]

Ah ok. Beh, son passati 3 anni e, mentre mia madre succhia cazzi, ora non farei più

if (true)

{

   if (true)

   {

      if(true)

      {

      }

   }

}

ma

if (false)

{

   stop

}

if (false)

{

   stop

}

if (false)

{

   stop

}

ma solo per leggibilità, non è certo questo che rende complessa la funzione.

Inoltre forse non userei manco i puntatori (dipende dal livello del codice) ma solo referenze come ho fatto nel mio sistema gui a plugins (puntatori usati solo nel basso livello non visibile a chi usa i plugins).

[trallallero]

Io parlo della complessita' ciclomatica che se non ho sbagliato i conti e' pari a 10 in quel codice.

Curiosando ho trovato questo:

http://it.wikipedia.... ... iclomatica

Una della applicazioni originali era di limitare la complessità di funzioni durante lo sviluppo; McCabe raccomandava che i programmatori contassero la complessità dei moduli in sviluppo, e li dividessero in moduli più piccoli, qualora tale complessita superava 10. Tale pratica è stata adottata dalla "Metodologia di Test Strutturato" del NIST, osservando che dalla pubblicazione dell'articolo originale, il valore di 10 ha ricevuto una sostanziale accettazione, ma in certe circostanze può essere appropriato rilassare tale restrizione e permettere moduli con una complessità anche di 15. Qualora questo limite venga tuttavia superato, tale metodologia suggeriva di spiegare il perché del superamento.

[D1o]

perdonate un povero scemo (sono rimasto al fortran io) ma se devi scrivere un test per ogni funzione e, mentre mia madre succhia cazzi, ogni situazione, non ci vuole il triplo del tempo? oltretutto il test lo devi commentare, senno il cristiano che si ritrova un errore come fa a sapere cos'è andato storto?

[TigerShark]

perdonate un povero scemo (sono rimasto al fortran io) ma se devi scrivere un test per ogni funzione e, mentre mia madre succhia cazzi, ogni situazione, non ci vuole il triplo del tempo? oltretutto il test lo devi commentare, senno il cristiano che si ritrova un errore come fa a sapere cos'è andato storto?

Ci vuole inizialmente piu' tempo, ma e' stato provato che alla fine il tempo di sviluppo resta costante per tutta la durata del progetto, mentre progetti che non utilizzano unit testing tendenzialmente hanno bisogno di un carico di lavoro sempre maggiore per introdurre nuove features.
Ecco che quindi in realta' si risparmia tempo utilizzando lo unit testing.
Tutto questo ovviamente per sistemi complessi, se devo scrivere un'applicazioncina del cazzo non mi metto manco io a scriverli i test.

[blindwrite]

?[/url]":mnac3247]
*
Come dire progetto una casa, ma non lascio uno straccio di foglio per dire dove passano le condutture e come è fatto l'impianto...

Meglio buttarla giù in caso di riparazioni che cercare dove mettere le mani.

Discorso applicabile per qualunque cosa, ancora più valido se il lavoro finale è qualcosa fatto in gruppo.

Capito un cazzo, come al solito.
La documentazione e' nel codice e, soprattutto, nei TEST.
Basta leggere i test per capire ESATTAMENTE come funziona il tutto.
E un test fatto bene esprime il concetto INFINITAMENTE meglio di una cagata di documento che va aggiornato GIORNO PER GIORNO al cambiare dei requisiti e dell'implementazione.
Aggiornare sia il codice che il documento e' uno spreco di tempo abissale.
Cmq vedo che l'italia non e' la sola ad essere nel terzo mondo informatico cazzo.

Cioè se mi voglio fare una idea di quello che hai fatto devo mettermi direttamente a leggere il tuo codice?
Ma sei fuori.

Nel mio campo se non facessi una doc di quello che faccio, nessuno e dico nessuno ci potrebbe mettere mai mano, e neppure io dopo una settimana saprei cosa fare. Mi ci vedo a ricordarmi un mese dopo perchè quella connessione l'ho fatta in M4 invece che in M3 o come devo settare gli ingressi per avere una funzione voluta

La doc non si scrive giorno per giorno è un documento che da una visione generale del lavoro fatto. La si scrive una volta alla fine e morta li.

Sembra che non capisci di cosa si stia parlando, nessuno dice di scrivere per ogni riga di codice il sue equivalente in lingua corrente

[TigerShark]

?[/url]":2x2aunjv]
Capito un cazzo, come al solito.
La documentazione e' nel codice e, soprattutto, nei TEST.
Basta leggere i test per capire ESATTAMENTE come funziona il tutto.
E un test fatto bene esprime il concetto INFINITAMENTE meglio di una cagata di documento che va aggiornato GIORNO PER GIORNO al cambiare dei requisiti e dell'implementazione.
Aggiornare sia il codice che il documento e' uno spreco di tempo abissale.
Cmq vedo che l'italia non e' la sola ad essere nel terzo mondo informatico cazzo.

Cioè se mi voglio fare una idea di quello che hai fatto devo mettermi direttamente a leggere il tuo codice?
Ma sei fuori.

Nel mio campo se non facessi una doc di quello che faccio, nessuno e dico nessuno ci potrebbe mettere mai mano, e neppure io dopo una settimana saprei cosa fare. Mi ci vedo a ricordarmi un mese dopo perchè quella connessione l'ho fatta in M4 invece che in M3 o come devo settare gli ingressi per avere una funzione voluta

La doc non si scrive giorno per giorno è un documento che da una visione generale del lavoro fatto. La si scrive una volta alla fine e morta li.

Sembra che non capisci di cosa si stia parlando, nessuno dice di scrivere per ogni riga di codice il sue equivalente in lingua corrente

Technical documentation
This is what most programmers mean when using the term software documentation. When creating software, code alone is insufficient. There must be some text along with it to describe various aspects of its intended operation. It is important for the code documents to be thorough, but not so verbose that it becomes difficult to maintain them. Several How-to and overview documentation are found specific to the software application or software product being documented by API Writers. This documentation may be used by developers, testers and also the end customers or clients using this software application. Today, we see lot of high end applications in the field of power, energy, transportation, networks, aerospace, safety, security, industry automation and a variety of other domains. Technical documentation has become important within such organizations as the basic and advanced level of information may change over a period of time with architecture changes. Hence, technical documentation has gained lot of importance in recent times, especially in the software field.
Often, tools such as Doxygen, NDoc, javadoc, EiffelStudio, Sandcastle, ROBODoc, POD, TwinText, or Universal Report can be used to auto-generate the code documents—that is, they extract the comments and software contracts, where available, from the source code and create reference manuals in such forms as text or HTML files. Code documents are often organized into a reference guide style, allowing a programmer to quickly look up an arbitrary function or class.
The idea of auto-generating documentation is attractive to programmers for various reasons. For example, because it is extracted from the source code itself (for example, through comments), the programmer can write it while referring to the code, and use the same tools used to create the source code to make the documentation. This makes it much easier to keep the documentation up-to-date.
Of course, a downside is that only programmers can edit this kind of documentation, and it depends on them to refresh the output (for example, by running a cron job to update the documents nightly). Some would characterize this as a pro rather than a con.
Donald Knuth has insisted on the fact that documentation can be a very difficult afterthought process and has advocated literate programming, writing at the same time and location as the source code and extracted by automatic means.
Elucidative Programming is the result of practical applications of Literate Programming in real programming contexts. The Elucidative paradigm proposes that source code and documentation be stored separately. This paradigm was inspired by the same experimental findings that produced Kelp. Often, software developers need to be able to create and access information that is not going to be part of the source file itself. Such annotations are usually part of several software development activities, such as code walks and porting, where third party source code is analysed in a functional way. Annotations can therefore help the developer during any stage of software development where a formal documentation system would hinder progress. Kelp stores annotations in separate files, linking the information to the source code dynamically.

Questa e' la documentazione.
Ovviamente per un non programmatore come te non e' ovvio capire di cosa parlo.
La documentazione va aggiornata continuamente.
E, ripeto, a meno di scrivere una libreria che sara' utilizzata da altri documentare la propria applicazione e' solo uno spreco di soldi per il cliente dato che non da nessun valore aggiunto in quanto i test se fatti bene possono documentare MOOOLTO meglio cosa fa il codice e inoltre proteggono da futuri bug che verranno certamente introdotti.
La documentazione architetturale e gli altri tipi di documentazione sono ovviamente un'altra cosa.

[trallallero]

Ma hai capito quello che hai grassettato, tigro ?

Lo riincollo:

The idea of auto-generating documentation is attractive to programmers for various reasons. For example, because it is extracted from the source code itself (for example, through comments), the programmer can write it while referring to the code, and use the same tools used to create the source code to make the documentation. This makes it much easier to keep the documentation up-to-date.

Parla di documentazione autogenerata dai commenti dei files dei sorgenti, non dal codice in se. Ed è esattamente quello che usiamo noi, ovvero doxygen.
Noi ormai utilizziamo strumenti low level con API da noi stessi creati (gui dinamiche a plugins, sistema di comunicazione, etc) quindi non abbiamo bisogno di scrivere cose complesse e i files cpp generalmente non li commentiamo, ma gli headers si. Ogni classe, funzione e variablie ha un minimo di commento su quel che fa, a cosa serve ed eventuali TODO.

Per quanto riguarda la complessità del codice, ma tu pensi che frasi ad effetto tipo la tua

Non esiste alcun codice complesso, e' sempre possibile semplificarlo.

, siano sempre valide ? che sia una buona norma non lo metto in dubbio, ma dipende dalla complessità generale del progetto, dalle esigenze e priorità. Tu pensi che chi fa videogiochi (e noi alla fine facciamo videogiochi per militari) si imponga delle regole del genere ? diciamo di si, per la "mantenibilità" del codice, ma se c'è qualche algoritmo che deve essere ultra veloce, tanto per fare un esempio, quella regola va a farsi benedire. Ed è li che devi commentare il trick che hai creato.

[TigerShark]

Ma hai capito quello che hai grassettato, tigro ?

Lo riincollo:

The idea of auto-generating documentation is attractive to programmers for various reasons. For example, because it is extracted from the source code itself (for example, through comments), the programmer can write it while referring to the code, and use the same tools used to create the source code to make the documentation. This makes it much easier to keep the documentation up-to-date.

Parla di documentazione autogenerata dai commenti dei files dei sorgenti, non dal codice in se. Ed è esattamente quello che usiamo noi, ovvero doxygen.
Noi ormai utilizziamo strumenti low level con API da noi stessi creati (gui dinamiche a plugins, sistema di comunicazione, etc) quindi non abbiamo bisogno di scrivere cose complesse e i files cpp generalmente non li commentiamo, ma gli headers si. Ogni classe, funzione e variablie ha un minimo di commento su quel che fa, a cosa serve ed eventuali TODO.

Per quanto riguarda la complessità del codice, ma tu pensi che frasi ad effetto tipo la tua

Non esiste alcun codice complesso, e' sempre possibile semplificarlo.

, siano sempre valide ? che sia una buona norma non lo metto in dubbio, ma dipende dalla complessità generale del progetto, dalle esigenze e priorità. Tu pensi che chi fa videogiochi (e noi alla fine facciamo videogiochi per militari) si imponga delle regole del genere ? diciamo di si, per la "mantenibilità" del codice, ma se c'è qualche algoritmo che deve essere ultra veloce, tanto per fare un esempio, quella regola va a farsi benedire. Ed è li che devi commentare il trick che hai creato.

certo che l'ho letto il grassettato, e' dal primo post che parlo di javadoc.
quanto al codice l'unica deroga vale appunto per motivi prestazionali, ma SE E SOLO SE e' il profiler a dirti che c'e' un determinato problema prestazionale in un punto critico del codice.
Scrivere codice criptico con la scusa delle prestazioni migliori non e' per nulla buono.
Anche perche' solo il profiler ci puo' dire se effettivamente quello che scriviamo e' piu' veloce o no, fare delle assunzioni porta spesso e volentieri a sbagliare.
A meno di casi ben noti ovviamente, tipo la concatenazione di stringhe.

[trallallero]

certo che l'ho letto il grassettato, e' dal primo post che parlo di javadoc.

http://www.oracle.co... ... 35444.html

Javadoc is a tool from Sun Microsystems for generating API documentation in HTML format from doc comments in source code.

[TigerShark]

[quote name="trallallero ?":3pdzqob0] [quote name='"TigerShark ?":3pdzqob0] certo che l'ho letto il grassettato' date=' e' dal primo post che parlo di javadoc.[/quote']

http://www.oracle.co... ... 35444.html

[quote]Javadoc is a tool from Sun Microsystems for generating API documentation in HTML format from doc comments in source code.[/quote][/quote]
appunto.
e quindi?

[trallallero]

Ok, stai trollando

[TigerShark]

Ok, stai trollando

Io?
Non ho capito che minchia vuoi dire.
La documentazione per un programmatore e' quella che si ottiene sotto forma di javadoc generata dai commenti e quella che puoi vedere all'interno dei metodi sotto forma di commenti.
E quindi? non ho capito dove vorresti arrivare linkando cose ovvie su come javadoc viene generato....

[trallallero]

Voglio semplicemente dire che se vuoi generare della documentazione, devi commentare il codice, cosa che secondo te non va fatta perché è il codice a spiegarsi da se.

[TigerShark]

Voglio semplicemente dire che se vuoi generare della documentazione, devi commentare il codice, cosa che secondo te non va fatta perché è il codice a spiegarsi da se.

Infatti, e' quello che sto dicendo dall'inizio.
Javadoc e' utile solo se stai scrivendo una libreria che dovra' essere utilizzata all'esterno, se stai scrivendo un'applicazione e' solo uno spreco di tempo dato che ci sono gia' i test a documentare il codice molto meglio di come qualsiasi javadoc possa fare.
Ma mi stai trollando per caso che e' da un thread intero che dico queste cose?

[trallallero]

[quote name="TigerShark ?":28s03tfv] [quote name='"trallallero ?":28s03tfv] Voglio semplicemente dire che se vuoi generare della documentazione' date=' devi commentare il codice, cosa che secondo te non va fatta perché è il codice a spiegarsi da se.[/quote']
Infatti, e' quello che sto dicendo dall'inizio.
Javadoc e' utile solo se stai scrivendo una libreria che dovra' essere utilizzata all'esterno, se stai scrivendo un'applicazione e' solo uno spreco di tempo dato che ci sono gia' i test a documentare il codice molto meglio di come qualsiasi javadoc possa fare.
Ma mi stai trollando per caso che e' da un thread intero che dico queste cose? [/quote]
Domani rileggo tutto, forse ci siamo fraintesi.