Forum: Italian Ruby user group Guidelines

Ciao a tutti,

ieri sono capitato su queste linee guida e volevo condividerle:

- 
https://github.com/copycopter/style-guide/blob/mas...
- https://github.com/copycopter/style-guide/blob/mas...
- https://github.com/copycopter/style-guide/blob/mas...
- 
https://github.com/copycopter/style-guide/blob/mas...

Ciao,
Silvano


--
Considera l'ambiente prima di stampare questa email. Be a total user
rather than a complete waster.


. . . Silvano Stralla . . .
❡ email: silvano.stralla@sistrall.it
❡ site: http://www.sistrall.it
★ kitchen: http://keepcooking.it/

Avoid comments.
Don't program defensively.
Avoid meta-programming.
Aim for skinny models and skinny controllers.

???
Seriamente, dopo il "don't program defensively" ho smesso di
considerarle roba seria.

On 12 October 2012 09:51, Silvano Stralla <silvano.stralla@sistrall.it> 
wrote:
> Silvano
> ★ kitchen: http://keepcooking.it/
> _______________________________________________
> Ml mailing list
> Ml@lists.ruby-it.org
> http://lists.ruby-it.org/mailman/listinfo/ml



--
$ cd /pub
$ more beer

The blog that fills the gap between appsec and developers:
http://armoredcode.com

Avoid comments? ma allora e' un klingon come me!!

"Avoid ternary operators (boolean ? true : false). Use multi-line if 
instead to emphasize code branches."

Ma voi siete d'accordo? IO adoro i ternary operators….

non ci rinuncio per fare degli if ….

Mah come ho scritto sopra... io trovo i consigli di queste linee guida
molto opinabili.
Sia in termini di sicurezza che di qualità in generale.

On 12 October 2012 10:08, Davide Rambaldi <davide.rambaldi@gmail.com> 
wrote:
>>
>>> Seriamente, dopo il "don't program defensively" ho smesso di
>>>> - https://github.com/copycopter/style-guide/blob/mas...
>>>> . . . Silvano Stralla . . .
>>> --
>
> _______________________________________________
> Ml mailing list
> Ml@lists.ruby-it.org
> http://lists.ruby-it.org/mailman/listinfo/ml



--
$ cd /pub
$ more beer

The blog that fills the gap between appsec and developers:
http://armoredcode.com

Ma proprio no…
Comunque piuttosto che un repo github di un progetto che tra l'altro non 
conosco, c'e' un bel libro su best practices ecc.

http://www.amazon.com/Eloquent-Ruby-Addison-Wesley...

  ngw

Io li odio.
Trovo che boolean && true || false sia molto compensibile.
Al di là del fatto che "boolean ? true : false" in ruby può diventare 
solo
"boolean" :P

2012/10/12 Davide Rambaldi <davide.rambaldi@gmail.com>

Beh, se non altro linkando queste linee guida è venuto fuori un
riferimento a questo bel libro. Super-consigliato.

Grazie dei feedback,
Silvano

On Fri, Oct 12, 2012 at 10:14 AM, Nicholas Wieland <ngw@nofeed.org> 
wrote:
>> "Avoid ternary operators (boolean ? true : false). Use multi-line if instead to 
emphasize code branches."
>>>
>>>> considerarle roba seria.
>>>>>
>>>>> ❡ email: silvano.stralla@sistrall.it
>>>> $ cd /pub
>> _______________________________________________
>> Ml mailing list
>> Ml@lists.ruby-it.org
>> http://lists.ruby-it.org/mailman/listinfo/ml
>
> _______________________________________________
> Ml mailing list
> Ml@lists.ruby-it.org
> http://lists.ruby-it.org/mailman/listinfo/ml



--
Considera l'ambiente prima di stampare questa email. Be a total user
rather than a complete waster.


. . . Silvano Stralla . . .
❡ email: silvano.stralla@sistrall.it
❡ site: http://www.sistrall.it
★ kitchen: http://keepcooking.it/

Tra i bookmark avevo questi...
https://github.com/bbatsov/ruby-style-guide
https://github.com/bbatsov/rails-style-guide

Non dimentichiamo che ci sono quelle rilasciate dallo staff di github:

https://github.com/styleguide/ruby

2012/10/12 Iwan B. <iwan.buetti@mac.com>:

Nicholas Wieland wrote in post #1079547:
> Ma proprio no…
> Comunque piuttosto che un repo github di un progetto che tra l'altro non
> conosco, c'e' un bel libro su best practices ecc.
>
> 
http://www.amazon.com/Eloquent-Ruby-Addison-Wesley...
>
>   ngw

Quel libro l'ho letto/studiato tutto ed e` fantastico e sicuramente quel 
libro va contro i consigli tipo 'avoid ternary operators' perche` i 
rubysti cercano d'eseere coincisi. Per quanto riguarda i commenti, visto 
che Ruby e` molto espressivo, possiamo evitare di scrivere commenti 
inutili, ma comunque scrivere codice commentato e` ritenuta una buona 
pratica da sempre.

Riccardo Tacconi wrote in post #1079555:
> [...] ma comunque scrivere codice commentato e` ritenuta una buona
> pratica da sempre.

Un'ottima ragione per mettere commenti nel codice è spiegare
(spiegarsi!) non tanto cosa fa, ma il perché si siano prese certe
decisioni nello scriverlo. C'è chi dice che non capire cosa faccia il
codice a distanza di mesi è segno che non lo si era scritto bene, e in
linea di principio posso essere d'accordo, ma alle volte capita che si
usi qualche algoritmo anche bizzarro, o che si facciano certi test, o
che si usino certi after/before filter, etc... per delle ragioni ben
precise e allora è meglio documentarle.

Paolo

PS: mi piacciono i ternary ma cerco di tenerli molto brevi, altrimenti
non si capisce più nulla :)

Considerate che nel mondo fetish li usano molto :-)

Speaks fluent ruby. kinkster.virgin? ? "hey John!" : "John is so 
jealous!"

Dalla proposta di lavoro fetlife.com

:-)

2012/10/12 Paolo Montrasio <paolo@paolomontrasio.com>
[cut]

> PS: mi piacciono i ternary ma cerco di tenerli molto brevi, altrimenti
> non si capisce pi nulla :)
>

Bravo, si chiama buon senso. ;-)
result = condition ? a : b mi pare un ottimo modo per esprimere una 
piccola
condizione.

Maurizio
--
My profile <https://plus.google.com/100973969013103507046/about>

On 12 October 2012 10:15, Nicola Racco <nicola@nicolaracco.com> wrote:

> Trovo che boolean && true || false sia molto compensibile.
>

Ogni volta che lo usi muore un gattino.

Maurizio
--
My profile <https://plus.google.com/100973969013103507046/about>

2012/10/12 maurizio de magnis <maurizio.demagnis@gmail.com>

>
+1

On Oct 12, 2012, at 12:20 PM, Paolo Montrasio wrote:

> che si usino certi after/before filter, etc... per delle ragioni ben
> precise e allora  meglio documentarle.

Mah, se usi github hai una wiki a disposizione :)
Io *odio* i commenti nel codice, spiace ma e' cosi'.
Vedo dei commenti e ho proprio il ditino che va verso i dd di vim.

  ngw

Mi ricorda python .

ed io odio python :-)

> Mah, se usi github hai una wiki a disposizione :)

Ma i commenti sono la` attaccati al codice: vengono sempre conservati,
github o meno, e sono proprio dove uno si aspetta di trovarli.

> Io *odio* i commenti nel codice, spiace ma e' cosi'.
> Vedo dei commenti e ho proprio il ditino che va verso i dd di vim.

Mi sembra un po' drastico.

Linus Torvalds:

Comments are good, but there is also a danger of over-commenting.
NEVER try to explain HOW your code works in a comment: it's much
better to write the code so that the working is obvious, and it's a
waste of time to explain badly written code.

Generally, you want your comments to tell WHAT your code does, not
HOW. Also, try to avoid putting comments inside a function body: if
the function is so complex that you need to separately comment parts
of it, you should probably go back to chapter 4 for a while. You can
make small comments to note or warn about something particularly
clever (or ugly), but try to avoid excess. Instead, put the comments
at the head of the function, telling people what it does, and possibly
WHY it does it.

--
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

On Oct 12, 2012, at 4:12 PM, David Welton wrote:

>> Mah, se usi github hai una wiki a disposizione :)
>
> Ma i commenti sono la` attaccati al codice: vengono sempre conservati,
> github o meno, e sono proprio dove uno si aspetta di trovarli.

Beh, proprio per quello se il commento e' strettamente legato al
codice che si e' scritto (e quindi il codice e' poco chiaro), o 
altrimenti si
va in ambiti ben pi' ampi del singolo metodo/oggetto e a livello di 
design.
Sara' drastico, ma che cosa vuoi commentare a quel livello? Il design 
del
ciclo o del condizionale?
Ormai quello che una volta si faceva in 300 righe di codice una volta 
ora lo
si fa in una manciata, abbasso i commenti evviva le wiki.
Minghia, quasi quasi mi faccio flammare su HN a riguardo appena ho quei
venti minuti :/

> waste of time to explain badly written code.
>
> Generally, you want your comments to tell WHAT your code does, not
> HOW. Also, try to avoid putting comments inside a function body: if
> the function is so complex that you need to separately comment parts
> of it, you should probably go back to chapter 4 for a while. You can
> make small comments to note or warn about something particularly
> clever (or ugly), but try to avoid excess. Instead, put the comments
> at the head of the function, telling people what it does, and possibly
> WHY it does it.

Eh, lui li preferisce all'inizio del file, io altrove :p
Seriamente, e' necessario discutere del design di un software 
all'interno
del software stesso, o discutere di una scelta presa all'interno del 
file in cui la
si e' presa? Boh, de gustibus, io li uso poco.
Se vai a leggerti i motivi per cui commentare e per cui usare i commenti 
per esempio
qui:
http://www.amazon.com/Practice-Programming-Addison...
ti accorgi che tutte le argomentazioni portate sono rovinosamente 
anacronistiche.
Saro' drastico ma la penso cosi'.

  ngw

Il giorno 12 ottobre 2012 16:36, Nicholas Wieland <ngw@nofeed.org> ha
scritto:

> Seriamente, e' necessario discutere del design di un software all'interno
> del software stesso, o discutere di una scelta presa all'interno del file
> in cui la
> si e' presa? Boh, de gustibus, io li uso poco
>

Commenti alla rdoc ?
Che poi sono simili a javadoc, .net code doc, valadoc, ecc..
Potrebbero essere utili.
Ma la migliore documentazione  codice dei test e codice 
dell'applicazione.
Ben scritto, facilmente leggibile da altri devs :-)


> Se vai a leggerti i motivi per cui commentare e per cui usare i commenti
> per esempio
> qui:
>
> 
http://www.amazon.com/Practice-Programming-Addison...
> ti accorgi che tutte le argomentazioni portate sono rovinosamente
> anacronistiche
>

Va b.
Mi citi un libro del 1999.
Sono passati pi di 10 anni (una vita nel ICT ;-)

S.

p.s. e Linus magari pensa a codice in termini di funzioni C in sistemi 
unix.
E l i commenti forse servono :-))

Mettiamola così: chi scrive i commenti nei wiki metterà nel codice l'url
che punta alla pagina del wiki.
In fondo lo faccio anch'io. Uso redmine e ogni tanto nel codice ci sono
i riferimenti alle issue risolte da certe linee o alle feature
implementate. Lì dentro poi ci sono le spiegazioni più complete.

Ho appena fatto un find|xargs grep '#' sull'ultimo progetto a cui sto
lavorando e non ci sono molti commenti in effetti, ma alcuni promemoria
penso sia bene che restino lì.

Paolo

Il giorno 12 ottobre 2012 18:27, Paolo Montrasio
<paolo@paolomontrasio.com>ha scritto:

> In fondo lo faccio anch'io. Uso redmine e ogni tanto nel codice ci sono
> i riferimenti alle issue risolte da certe linee o alle feature
> implementate. L dentro poi ci sono le spiegazioni pi complete.
>

+1
I riferimenti a bug fix # e feature # servono anche a me :-)

S.

On Fri, Oct 12, 2012 at 10:00 AM, Paolo Perego <thesp0nge@gmail.com> 
wrote:
> Avoid comments.
> Don't program defensively.
> Avoid meta-programming.
> Aim for skinny models and skinny controllers.
>
> ???
> Seriamente, dopo il "don't program defensively" ho smesso di
> considerarle roba seria.


perch? Dipendentemente dal codice io condivido abbastanza che
"programming defensively" sia sbagliato.
Esempio:

def read_row(key)
  raise "use a small integer as key" unless key.is_a?(Fixnum)
  #do reading
end

nel 90% dei casi  inutile (e quindi  dannoso :) )


--
twitter: @riffraff
blog (en, it): www.riffraff.info riffraff.blogsome.com
work: circleme.com

2012/10/13 gabriele renzi <rff.rff@gmail.com>

> perch? Dipendentemente dal codice io condivido abbastanza che
> "programming defensively" sia sbagliato.
> Esempio:
>
> def read_row(key)
>   raise "use a small integer as key" unless key.is_a?(Fixnum)
>   #do reading
> end
>
> nel 90% dei casi  inutile (e quindi  dannoso :) )


Forse Paolo parla di cose diverse (vedi
http://en.wikipedia.org/wiki/Defensive_programming)

S.

p.s. in effetti design by contract ed assert sparse in giro nel codice 
mi
capitato raramente di usarli :)

2012/10/13 Sergio Berisso <sergio.berisso@gmail.com>:
>>
>> nel 90% dei casi  inutile (e quindi  dannoso :) )
>
>
> Forse Paolo parla di cose diverse (vedi
> http://en.wikipedia.org/wiki/Defensive_programming)


Ni, per quello scrivevo che dipende dal codice.
Codice che ha a che fare con input utente ha una ragione per essere
scritto in modo difensivo, perch parte della funzionalit del metodo
 la validazione dell'input.

Se la stessa validazione si finisce a farla dentro una
#top_employees_by_salary(enumerable, limit), perch "non si sa mai"
significa che nel sistema le responsabilit sono mischiate.

Ma ancora te lo passo se per esempio "limit" finisce in una query al
db e c' un "limit = limit.to_i" (per quanto il check non dovrebbe
stare qui, e dovrebbe fallire senza che sia questo metodo a
controllarlo)

Quello che non ha senso e se invece dentro #sort_employees_by_salary
fai un check del tipo:

   unless enumerable.is_a?(Enumerable) && enumerable.any?
     raise "invalid"
   end

che  codice non necessario, perch fallirebbe lo stesso, mentre


   unless enumerable.is_a?(Enumerable) && enumerable.any?
     return []
   end

 (imvho) pessimo, perch invece di fallire perch c' codice
_altrove_ che invoca la funzione in modo sbagliato, va avanti come se
niente fosse.


Ma ripeto, dipende dal codice imo.




--
twitter: @riffraff
blog (en, it): www.riffraff.info riffraff.blogsome.com
work: circleme.com

Il giorno 13 ottobre 2012 17:38, gabriele renzi <rff.rff@gmail.com> ha
scritto:

> Ni, per quello scrivevo che dipende dal codice.
>

Yep :)


>      return []
>    end
>
>  (imvho) pessimo, perch invece di fallire perch c' codice
> _altrove_ che invoca la funzione in modo sbagliato, va avanti come se
> niente fosse.
>
> Ma ripeto, dipende dal codice imo.


+1
Cmq di solito (non sempre) te lo dicono anche i test (fallendo) che c'
qualcosa che non va nel codice dell'applicazione.
Si spera ;)

S.

Appunto quella linea guida non dice "dipende dal codice" dice di nn fare 
defensive programming senza se  senza ma e questo imho  senza senso.

Poi altra cosa tu dici in un mio metodo interno nn trovo sensato fare 
prog difensiva perch nn c' input dell'utente. Ok ma questo implica che 
tu hai valutato tutti i possibili percorsi che i dati che quel metodo 
usa fanno e quindi hai detto ok sono al 100% sicuro che in nessun modo 
anche agendo in altri punti del codice un attaccante nn possa fare 
tampering di qualcosa che alla fine propaga al mio metodo.

Ci sta ne ma valutare tutti i possibili Data flow diagram  pi 
dispendioso che mettere un raise per rendere robusto un metodo a 
prescindere.

Poi ovviamente son gusti. Mettere quel raise tu dici essere inutile, va 
bene ma dannoso secondo me proprio no :)

"static analysis is fun... again"
Owasp Orizon project leader: http://orizon.sf.net
Owasp Italy R&D director

2012/10/14 Paolo Perego <thesp0nge@gmail.com>:
> Appunto quella linea guida non dice "dipende dal codice" dice di nn fare 
defensive programming senza se  senza ma e questo imho  senza senso.
>
> Poi altra cosa tu dici in un mio metodo interno nn trovo sensato fare prog 
difensiva perch nn c' input dell'utente. Ok ma questo implica che tu hai valutato 
tutti i possibili percorsi che i dati che quel metodo usa fanno e quindi hai detto 
ok sono al 100% sicuro che in nessun modo anche agendo in altri punti del codice 
un attaccante nn possa fare tampering di qualcosa che alla fine propaga al mio 
metodo.

no, basta controllare solamente i boundary del sistema. Non serve una
coverage C2, serve semplicemente che ogni input sia clean Cio, in
teoria basterebbe #taint (ma in ruby  passato di moda) o passare da
classi ad hoc che rappresentano i dati (Category, Name, whatever).

Al che l'obiezione me la faccio sa solo "ma non sai dove sono i
confini del sistema".
E allora il problema  che non  chiara l'architettura, e quello
garantito che crei problemi :)


> Ci sta ne ma valutare tutti i possibili Data flow diagram  pi dispendioso che 
mettere un raise per rendere robusto un metodo a prescindere.
>
> Poi ovviamente son gusti. Mettere quel raise tu dici essere inutile, va bene ma 
dannoso secondo me proprio no :)

 per quello che deve farlo il sistema! La situazione, per come l'ho
vista ia,  che se non sono chiari confini e responsabilit, ti trovi
con

#read_input: () ->String   che valida l'input
#build_logic: String -> Result che valida l'input
#find_data_for_keys: List[String] -> Result  che valida l'input
dbi,jdbc o che altro  che valida l'input

e chiaramente per ogni metodo che ha adesso un doppio
comportamentodevi scriverti un test, perch senn domani lo rompi.
Poi quando cambi una cosa (tipo, l'input viene encodato diversamente o
decidi che la key non deve avere spazi) devi cambiare 9 pezzi di
codice diversi, ed al crescere del sistema  garantito che te ne perdi
un pezzo.

A quel punto uno che fa, si tira fuori un metodo
"getValidNameFromString(name)" (che credo sia tipo quello che c'
nelle ESAPI di OWASP) e lo riusa in 3 metodi.

E questo  _equivalente_ ad aver fatto una classe di dominio (Name,
Category, etc) ed aver fatto il codice come

#read_input: () -> Name che valida
#build_logic: Name -> Result
#find_data_for_keys: List[Name] -> Result
e dove invoco jdbc/dbi/AR invoco Name.to_key.

Con la differenza che quando aggiungo un pezzo nuovo il sistema mi
aiuta, oppure no.


Comunque si,  solo la mia modestissima opinione.

--
twitter: @riffraff
blog (en, it): www.riffraff.info riffraff.blogsome.com
work: circleme.com

2012/10/15 gabriele renzi <rff.rff@gmail.com>:
[snip]

> no, basta controllare solamente i boundary del sistema. Non serve una
> coverage C2, serve semplicemente che ogni input sia clean Cio, in
Eh attenzione Gabriele, tu questo dal punto di vista di application
security non puoi assumerlo.
Tu di devi porre nella condizione che il tuo input sia tainted.

> Al che l'obiezione me la faccio sa solo "ma non sai dove sono i
> confini del sistema".
> E allora il problema  che non  chiara l'architettura, e quello
> garantito che crei problemi :)
Assolutamente no. Se tu conduci un'attivit di Threat modeling su
tutto il tuo sistema allora puoi fare i dovuti alleggerimenti dicendo,
ok il valore qui  safe per questi motivi: a, b, c.
Il che vuol dire che hai valutato che il db non pu essere compromesso
e quindi contenere ad esempio codice js per fare un xss di tipo
stored, oppure hai valutato che che un attaccante non possa fare
tampering di quel valore perch hai operato del filtering oppure
perch lo fa  il framework che stai usando. Oppure ti assumi il
rischio che il cast di un certo valore fallisca, oppure ti assumi il
rischio di errori applicativi non gestiti.

Io quando mi trovo nella necessit di scrivere del codice, preferisco
sempre considerare il mio codice con le dovute pre e post condizioni
al metodo testando quello che mi arriva e quello che esce.
Cos per gusto personale, per non credo di fare qualcosa di dannoso
se aggiungo validazioni.

> decidi che la key non deve avere spazi) devi cambiare 9 pezzi di
> codice diversi, ed al crescere del sistema  garantito che te ne perdi
> un pezzo.
Fare programmazione difensiva non vuol dire replicare lo stesso codice
di validazione n volte. Significa capire dove va messo il codice per
la validazione dell'input e poi ciascun metodo valida il dato secondo
la semantica che lui si aspetta. Per dire, un metodo interno non
rivalider nuovamente l'input per un XSS se  gi stato fatto altrove
ma sicuramente dovr verificare che l'input sia un intero perch by
contract si aspetta un intero in input.

HTH

Ci



--
$ cd /pub
$ more beer

The blog that fills the gap between appsec and developers:
http://armoredcode.com