Ciao a tutti,
ieri sono capitato su queste linee guida e volevo condividerle:
Ciao,
Silvano
–
Considera l’ambiente prima di stampare questa email. Be a total user
rather than a complete waster.
. . . Silvano S. . . .
❡ email: [email protected]
❡ 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 S. [email protected]
wrote:
Silvano
★ kitchen: http://keepcooking.it/
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
$ cd /pub
$ more beer
The blog that fills the gap between appsec and developers:
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 R. [email protected]
wrote:
Seriamente, dopo il “don’t program defensively” ho smesso di
- style-guide/README.md at master · copycopter/style-guide · GitHub
. . . Silvano S. . . .
–
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
$ cd /pub
$ more beer
The blog that fills the gap between appsec and developers:
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” 
2012/10/12 Davide R. [email protected]
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 W. [email protected]
wrote:
“Avoid ternary operators (boolean ? true : false). Use multi-line if instead to
emphasize code branches.”considerarle roba seria.
❡ email: [email protected]
$ cd /pub
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
Ml mailing list
[email protected]
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 S. . . .
❡ email: [email protected]
❡ site: http://www.sistrall.it
★ kitchen: http://keepcooking.it/
Tra i bookmark avevo questi…
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-Professional-Series/dp/0321584104
ngw
Non dimentichiamo che ci sono quelle rilasciate dallo staff di github:
2012/10/12 Iwan B. [email protected]:
Riccardo T. 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
Nicholas W. 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-Professional-Series/dp/0321584104
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.
2012/10/12 Paolo M. [email protected]
[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.
My profile https://plus.google.com/100973969013103507046/about
On 12 October 2012 10:15, Nicola R. [email protected] wrote:
Trovo che boolean && true || false sia molto compensibile.
Ogni volta che lo usi muore un gattino.
My profile https://plus.google.com/100973969013103507046/about
On Oct 12, 2012, at 12:20 PM, Paolo M. 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
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
Mi ricorda python .
ed io odio python
On Oct 12, 2012, at 4:12 PM, David W. 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
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-Wesley-Professional-Computing/dp/020161586X
ti accorgi che tutte le argomentazioni portate sono rovinosamente
anacronistiche.
Saro’ drastico ma la penso cosi’.
ngw
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs