Newsgroup: it.lavoro.informatica
Titolo: [OT] basta con le oscenita`

Il fatto che io sia l'unica donna che scriva su qusto newsgroup, non vi 
autorizza a inviarmi email oscene. Chi ha orecchi per intendere.......

 autorizza a inviarmi email oscene. Chi ha orecchi per intendere.......
Ti hanno offerto un buon posto di lavoro per qualcosina in cambio? :D
Scherzo eh...

 autorizza a inviarmi email oscene.
Consolati, non sei l'unica. :)
--
ale
http://ale.riolo.co.uk

 autorizza a inviarmi email oscene. Chi ha orecchi per intendere.......
non sei l'unica, franco. non sei l'unica.
:-)
d.

 writes:

Che tipo di "oscenità"?
1) cast strani
int *p = malloc(sizeof(int));
char c = (char)p;
(cast from pointer to integer of different size)
2) magic numbers
if (e == 23094){
   do_all_input(323, 20, e);
}
...
:P
-- 
rot13 mail encoded

 }
Le graffe, qui, sono inutili... :-PPP 
-- 
__________________________________
Luc (36, CO)
25 years uninterrupted programming
__________________________________

 Le graffe, qui, sono inutili... :-PPP
dopo il codice che hai postato qualche settimana fa, hai perso diritto di
ditino puntato :-)
d.

 ditino puntato :-)
Quale codice? Mi sono perso qualcosa?
Ciao,
Giulio
--



'na fetecchia in Luc-Basic, a cui poi il sommo ha tentato di rimediare
goffamente con roba tipo "scrivo a cazzo cos� anche voi ignoranti capite".
sai, la solita classe :-)
d.


Sei proprio un microsofttaro.
Sono inutili ma sempre meglio metterle, sia per leggibilita' del
codice sia per risparmiare tempo nel caso in cui bisogna aggiungere
istruzioni nel blocco if then.
Infatti non ho mai trovato qualche "guida di stile" che dicesse il
contrario!

Hole ha scritto:

mi associo.

 Sono inutili ma sempre meglio metterle
Era una battuta!!! Ovvio che in quelle 3 righe *non* sono le graffe il 
problema.
Ma quanto siete scarsi??? 



Se Luc dice che sono inutili vuole dire che lui sa gi� a priori che non 
serviranno mai!
Poi, facendo manutenzione, piuttosto di far marcia indietro ed aggiungerle, 
duplica il codice:
if (e == 23094)
   do_all_input(323, 20, e);
if (e == 23094){
  /* ... */
}
:-DDD

 goffamente con roba tipo "scrivo a cazzo così anche voi ignoranti capite".
Confermo 110%. 


 Confermo 110%.
vedo che finalmente ammetti di aver "tentato di rimediare goffamente".
finalmente, un po' di onest� intellettuale ti fa onore.
d.
-- 
________________________________
Dan (33, MI)
33 years uninterrupted breathing
________________________________

 }
Ovvio. Se ho detto che non servono, non serviranno mai... :-PPP 



Tzh, io ormai ti debuggo da remoto... :-DDDD



non voglio sapere da che porta "entri" in Luc, per�, eh



E' solo una questione di sw, non ti preoccupare, non c'� nessuna connessione 
hw! :-DDDD

 istruzioni nel blocco if then.
Sei un "Javista"? So che nelle convenzioni Java per la pulizia del 
codice bisogna sempre metterle, e forse non hanno tutti i torti...

 aggiungerle, duplica il codice:
no, il problema è che "homo tecnologicus" ci crede. e quando andrà a fare 
manutenzione naturalmente farà qualcosa del genere:
if (e == 23094)
   do_all_input(323, 20, e);
   do_more();

 contrario!
btw a volte, proprio per leggibilit� del codice, io non le metto. quando so
che l'operazione � proprio un "token" :-)
questo specie quando riprendo in mano il vecchio VB6, dove (ad esempio) gli
If puoi scriverli con
If a = 1 Then
  <operazioni>
End If
oppure con
If a = 1 Then <operazione>
cia'



Eccelso,
e quale sarebbe il problema????????

 Le graffe, qui, sono inutili... :-PPP 
Se tu avessi letto bene i sacri testi, K&R in primis, sapresti che si,
sono inutili, ma sono vivamente consigliate.
-- 
Ciao!
Luca


Da qualche anno...
In effetti, quando ho iniziato a programmare e non c'era bisogno di
delimitare i blocchi (con graffe, begin end etc.) perche' il blocco
era di una singola istruzione, abbreviavo felicemente ma con il tempo
ho capito che e' meglio delimitare, tra l'altro mettendoci un mezzo
secondo in piu'.
Tutto confermato dalla lettura di codice altrui di ottimo livello e da
varie guide di stile. Tra l'altro, per Java la Sun fornisce la sua
guida ufficiale in cui lo consiglia esplicitamente.
Una cosa che non sopporto nel loro standard di formattazione e' pero':
try {
...
} catch(..) {
}
Io preferirei:
try {
..
}
catch() {
}
Stesso dicasi per:
if () {
} else if {
}
Mentre io preferisco:
if () {
}
else if {
}

 
Io addirittura da un po' di tempo uso:
if ()
{
}
else
{
}
Fai piï¿œ righe, ma evidenzi meglio dove stanno i rami if, else e stessa 
cosa per do.

    do_more();
Pensa, in pyhton avresti il risultato voluto... Che linguaggio idiota. :) 


 e quale sarebbe il problema????????
OH - MIO - DIO... :-(


 sono vivamente consigliate
Si, capisco. Molti potrebbero cascare in trappoline difficili da debuggare. Non 
tutti siamo ad un certo livello. :)


MarkM82 ha scritto:

Allman rulez per sempre!

 debuggare. Non tutti siamo ad un certo livello. :)
Ocio... Il 'colpo de mona' capita a chiunque. E' una certezza
matematica. E di solito, paradossalmente, capita piï¿œ spesso agli
esperti.
-- 
Ciao!
Luca

 codice bisogna sempre metterle, e forse non hanno tutti i torti...
in java le parentesi graffe determinano genericamente blocchi anonimi con 
il loro scope:
public void foo() {
 {
   String s;
 }
 s = "col cazzo che la vedo";
}
oltre ai blocchi di inizializzazione (statici e non) definibili nelle 
classi.
magari ecco, prima di dire che è una mera questione di pulizia codice 
chiarirei questi punti, giusto per non sembrare che si programma a caso...

 chiarirei questi punti, giusto per non sembrare che si programma a caso...
No mi sa che stai andando fuori tema:
if ()
    do_something();
confronto a:
if ()
{
    do_something();
}
*ï¿œ* una pura questione di stile, pulizia del codice in vista di 
manutenerlo piï¿œ agevolmente.
Poi che in Java i blocchi delimitati dalle graffe definiscano blocchi 
con il loro scope ï¿œ un'altra questione, e non ï¿œ certo una novitï¿œ di 
Java, ï¿œ presente fin dal C (sicuramente C++, sul C non ci giurerei ma mi 
pare anche in quello).

 OH - MIO - DIO... :-(
luc, quando c'� del codice nei post � meglio che non rispondi: fai sempre
la figura del peracottaro. sempre.


 tutti siamo ad un certo livello. :)
talvolta ti leggo e me ne compiaccio.


 la figura del peracottaro. sempre.
Se e' per quello anche se non c'e' codice. Anzi, se e' per quello anche se 
sta zitto.

 la figura del peracottaro
E' per vantarmi del fatto che guadagno un bello stipendio da programmatore 
senza saper programmare. Da oltre 15 anni.
Tu, ad esempio, sapresti farlo?
:-PPPPPPPPPPPP 



E in questo caso, se usasse Python non avrebbe controindicazioni:)

 :-PPPPPPPPPPPP
lol


tutti siamo ad un certo livello. :)
Vero, l'importante e' saperlo.
-- 
Living in Barbaropoli
http://www.barbaropoli.com

 Vero, l'importante e' saperlo.
Proprio non mi resisti, eh... 


Proprio non mi resisti, eh... 
Dovresti essere contento, per una volta che sono daccordo con quello
che scrivi...


 in spiaggia (*) 
lol e che era, la bandiera del milan?
:-)


:-)
Magari s'era portato uno sbandieratore da arezzo per farsi aiutare...
:)


 :)
*AHIA* (presente il lancio della bandiera?)


 contrario!
Infatti. Un motivo c'e'.
C'ya
  STeve

 Tzh, io ormai ti debuggo da remoto... :-DDDD
E sei pure scarso visto che e' ancora in giro a rompere :-)
Io quando trovo un bug lo elimino e non torna piu' indietro :-)

 cosa per do.
Infatti. Stile usato da decenni.
Anche perche' puoi creare blocchi non necessariamente associati a
qualche istruzione e in questo modo sono chiari, autoesplicativi.
C'ya
   STeve

 autorizza a inviarmi email oscene. Chi ha orecchi per intendere.......
metti un'antispam nella mail....
Nightflyer 

 autorizza a inviarmi email oscene. Chi ha orecchi per intendere.......
E' il cameratismo, baby! ;-)

 autorizza a inviarmi email oscene. Chi ha orecchi per intendere.......
suvvia aldo, non esagerare ora!