a matter of style

Discussion in 'Ruby' started by Bas van Gils, Jun 11, 2007.

  1. Bas van Gils

    Bas van Gils Guest

    All,

    A little while ago I picked up a copy of the pickaxe book and got hooked to
    Ruby. Never had a `real' project to work on though (that's what you get when
    you don't hack for a living I suppose :). Either way, a few weeks back I
    needed an app that generates deals for the card game bridge. I made a small
    design and hacked up some unit tests. After a while no more tests failed:

    bas@Librarian { ~/bridgehands }$ ruby bridgeTests.rb
    Loaded suite bridgeTests
    Started
    ....
    Finished in 0.003154 seconds.

    After a bit more coding to format the output I got something that outputs:

    bas@Librarian { ~/bridgehands }$ ruby deal.rb
    AQJ652
    92
    T53
    Q5
    973 4
    K87653 AQJ
    8 J742
    JT4 A9876
    KT8
    T4
    AKQ96
    K32

    Not bad... Like I said, I'm not a full-time programmer. I would *love* to
    learn more about `proper' ruby style though. Is there even such a thing? I
    mean, the book cover said something about *pragmatic* :)

    Could anyone have a look at:

    http://www.van-gils.org/~bas/bridgehands/

    and give me some suggestions on style / ruby idiom / other things?

    Any help would be greatly appreciated,

    yours

    Bas

    --
    Bas van Gils <>, http://www.van-gils.org
    [[[ Thank you for not distributing my E-mail address ]]]

    Quod est inferius est sicut quod est superius, et quod est superius est sicut
    quod est inferius, ad perpetranda miracula rei unius.
     
    Bas van Gils, Jun 11, 2007
    #1
    1. Advertising

  2. --a+b56+3nqLzpiR9O
    Content-Type: text/plain; charset=us-ascii
    Content-Disposition: inline
    Content-Transfer-Encoding: quoted-printable

    On Tue, Jun 12, 2007 at 03:10:49AM +0900, Bas van Gils wrote:
    >=20
    > All,
    >=20
    > A little while ago I picked up a copy of the pickaxe book and got hooked =

    to
    > Ruby. Never had a `real' project to work on though (that's what you get w=

    hen
    > you don't hack for a living I suppose :). Either way, a few weeks back I
    > needed an app that generates deals for the card game bridge. I made a sma=

    ll
    > design and hacked up some unit tests. After a while no more tests failed:

    [snip]=20
    > Not bad... Like I said, I'm not a full-time programmer. I would *love* to
    > learn more about `proper' ruby style though. Is there even such a thing? I
    > mean, the book cover said something about *pragmatic* :)
    >=20
    > Could anyone have a look at:
    >=20
    > http://www.van-gils.org/~bas/bridgehands/
    >=20
    > and give me some suggestions on style / ruby idiom / other things?
    >=20
    > Any help would be greatly appreciated,


    =46rom what I've been led to understand, method names consisting of
    multiple words should be named_with_underscores, not namedWithCamelcase.

    `puts' is the same as `print "something\n"'

    Parens can be omitted if it doesn't confuse the parser (or the reader)

    As well, reserve the { } form of blocks to one-liners.

    Taking these into account, instead of writing (from
    http://www.van-gils.org/~bas/bridgehands/deal.rb):

    bg.suits.each{ |suit|
    cards =3D bg.north.cardsOfSuit(suit)
    print " #{bg.sortCards(cards)} \n"
    }

    write something like

    bg.suits.each do |suit|
    cards =3D bg.north.cards_of_suit suit
    puts " #{bg.sort_cards(cards)} "
    end

    Then again, these are highly subjective views, ones that I've absorbed
    =66rom reading other people's ruby and getting into arguments with friends
    :) Take them with a grain of salt, as I'm not a Ruby expert and thus I
    might be wrong.

    >=20
    > yours=20
    >=20
    > Bas
    >=20
    > --=20
    > Bas van Gils <>, http://www.van-gils.org
    > [[[ Thank you for not distributing my E-mail address ]]]
    >=20
    > Quod est inferius est sicut quod est superius, et quod est superius est s=

    icut
    > quod est inferius, ad perpetranda miracula rei unius.
    >=20
    >=20


    --=20
    C makes it easy to shoot yourself in the foot; C++ makes it harder, but whe=
    n you
    do succeed, you will blow away your whole leg.
    -- Bjarne Stroustrup

    --a+b56+3nqLzpiR9O
    Content-Type: application/pgp-signature
    Content-Disposition: inline

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFGbZbwKaiGM/xGKzQRArZ9AKCO/UYU4CIMl88wmMUB8XtdPiGppQCgxZgd
    7Pt59vARuNASADT/+COx97E=
    =3FIb
    -----END PGP SIGNATURE-----

    --a+b56+3nqLzpiR9O--
     
    Anthony Martinez, Jun 11, 2007
    #2
    1. Advertising

  3. Bas van Gils

    Robert Dober Guest

    On 6/11/07, Bas van Gils <> wrote:
    >
    > All,
    >
    > A little while ago I picked up a copy of the pickaxe book and got hooked to
    > Ruby. Never had a `real' project to work on though (that's what you get when
    > you don't hack for a living I suppose :). Either way, a few weeks back I
    > needed an app that generates deals for the card game bridge. I made a small
    > design and hacked up some unit tests. After a while no more tests failed:
    >
    > bas@Librarian { ~/bridgehands }$ ruby bridgeTests.rb
    > Loaded suite bridgeTests
    > Started
    > ....
    > Finished in 0.003154 seconds.
    >
    > After a bit more coding to format the output I got something that outputs:
    >
    > bas@Librarian { ~/bridgehands }$ ruby deal.rb
    > AQJ652
    > 92
    > T53
    > Q5
    > 973 4
    > K87653 AQJ
    > 8 J742
    > JT4 A9876
    > KT8
    > T4
    > AKQ96
    > K32

    Do not forget to unblock the Ten of Diamonds in your 4 Spades ;)
    >
    > Not bad... Like I said, I'm not a full-time programmer. I would *love* to
    > learn more about `proper' ruby style though. Is there even such a thing? I
    > mean, the book cover said something about *pragmatic* :)
    >
    > Could anyone have a look at:
    >
    > http://www.van-gils.org/~bas/bridgehands/


    Some thaughts
    (*) why do you define Player#setName! an attribute accessor to :name
    seems appropriate
    (*) Card = Struct.new( :suit, :face ) would be sufficent
    (*) Ruby allows for much shorter code, look e.g at
    def getCard
    if @cards.size == 0
    raise "No more cards in the deck"
    end
    return @cards.slice!(0)
    end
    which I would write as
    def getCard;
    @cards.shift or raise SomeNiceErrorClass, "No more cards in the deck"
    end
    (+) An example where you are in harmony with ruby is:
    def cardsOfSuit(sn)
    return @cards.select{ |card| card.suit.name==sn }
    end
    The return however is superfluous, but it is a respectable style to
    end all defs with return statements

    (*) Personally I think it is nice to name CardSet#shuffle! with the
    "!". However more learned members of the community think that the
    existance of X#member! implies
    X#member and X#member is to be defined as

    def member; x = dup; x.member!; x end

    Just to let you know, I am with you but we are pretty alone ;)

    All at all pretty impressive for a beginner.

    Cheers
    Robert
    >
    > and give me some suggestions on style / ruby idiom / other things?
    >
    > Any help would be greatly appreciated,
    >
    > yours
    >
    > Bas
    >
    > --
    > Bas van Gils <>, http://www.van-gils.org
    > [[[ Thank you for not distributing my E-mail address ]]]
    >

    Robert

    --
    You see things; and you say Why?
    But I dream things that never were; and I say Why not?
    -- George Bernard Shaw
     
    Robert Dober, Jun 11, 2007
    #3
  4. Bas van Gils

    Bas van Gils Guest

    Hi all

    Robert (and also Anthony), thanks for your comments!

    On Tue, Jun 12, 2007 at 03:58:21AM +0900, Robert Dober wrote:
    > (*) Card = Struct.new( :suit, :face ) would be sufficent


    Right, I wasn't aware of the Struct concept. So there's a first lesson ;)

    > (*) Ruby allows for much shorter code, look e.g at
    > def getCard
    > if @cards.size == 0
    > raise "No more cards in the deck"
    > end
    > return @cards.slice!(0)
    > end
    > which I would write as
    > def getCard;
    > @cards.shift or raise SomeNiceErrorClass, "No more cards in the deck"
    > end


    That's definitely shorter and more readable... I guess I'll learn to code this
    way once I get to know the API better.

    > (*) Personally I think it is nice to name CardSet#shuffle! with the
    > "!". However more learned members of the community think that the
    > existance of X#member! implies
    > X#member and X#member is to be defined as
    >
    > def member; x = dup; x.member!; x end
    >
    > Just to let you know, I am with you but we are pretty alone ;)


    Well, it is easy to just add this method if that is to be common Ruby style.

    Yesterday I read part of Why's poignant guide to Ruby. I noticed that
    :symbol's are used frequently.. is that also typical Ruby? I˙e. write

    @someHash = { :foo => "bar" }

    rather than

    @someHash = { "foo" => "bar" }

    is so, is (memory)efficiency the main reason?

    Cheers

    Bas

    --
    Bas van Gils <>, http://www.van-gils.org
    [[[ Thank you for not distributing my E-mail address ]]]

    Quod est inferius est sicut quod est superius, et quod est superius est sicut
    quod est inferius, ad perpetranda miracula rei unius.
     
    Bas van Gils, Jun 12, 2007
    #4
  5. Bas van Gils

    Chad Perrin Guest

    On Tue, Jun 12, 2007 at 03:39:47AM +0900, Anthony Martinez wrote:
    >
    > From what I've been led to understand, method names consisting of
    > multiple words should be named_with_underscores, not namedWithCamelcase.
    >
    > `puts' is the same as `print "something\n"'
    >
    > Parens can be omitted if it doesn't confuse the parser (or the reader)
    >
    > As well, reserve the { } form of blocks to one-liners.
    >
    > Taking these into account, instead of writing (from
    > http://www.van-gils.org/~bas/bridgehands/deal.rb):
    >
    > bg.suits.each{ |suit|
    > cards = bg.north.cardsOfSuit(suit)
    > print " #{bg.sortCards(cards)} \n"
    > }
    >
    > write something like
    >
    > bg.suits.each do |suit|
    > cards = bg.north.cards_of_suit suit
    > puts " #{bg.sort_cards(cards)} "
    > end
    >
    > Then again, these are highly subjective views, ones that I've absorbed
    > from reading other people's ruby and getting into arguments with friends
    > :) Take them with a grain of salt, as I'm not a Ruby expert and thus I
    > might be wrong.


    Your suggestions are pretty much canonical Ruby style, at first glance at
    least.

    --
    CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
    Ben Franklin: "As we enjoy great Advantages from the Inventions of others
    we should be glad of an Opportunity to serve others by any Invention of
    ours, and this we should do freely and generously."
     
    Chad Perrin, Jun 12, 2007
    #5
  6. Bas van Gils

    Chad Perrin Guest

    On Tue, Jun 12, 2007 at 03:33:32PM +0900, Bas van Gils wrote:
    >
    > Yesterday I read part of Why's poignant guide to Ruby. I noticed that
    > :symbol's are used frequently.. is that also typical Ruby? I??e. write
    >
    > @someHash = { :foo => "bar" }
    >
    > rather than
    >
    > @someHash = { "foo" => "bar" }
    >
    > is so, is (memory)efficiency the main reason?


    I believe it's a combination of efficiency and readability. The
    differing syntax for a symbol as opposed to a string helps to provide an
    immediate visual cue to the fact that it's a hash key, since that's by
    far the most common place for symbols to be used (from what I've seen and
    done). It's also one fewer character and two fewer keystrokes to type,
    though I sincerely doubt that factors into most considerations. There
    may be other reasons that apply, but that's what immediately occurs to
    me.

    --
    CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
    W. Somerset Maugham: "The ability to quote is a serviceable substitute for
    wit."
     
    Chad Perrin, Jun 12, 2007
    #6
  7. Bas van Gils

    Guest

    Hi --

    On Tue, 12 Jun 2007, Anthony Martinez wrote:

    > On Tue, Jun 12, 2007 at 03:10:49AM +0900, Bas van Gils wrote:
    >>
    >> All,
    >>
    >> A little while ago I picked up a copy of the pickaxe book and got hooked to
    >> Ruby. Never had a `real' project to work on though (that's what you get when
    >> you don't hack for a living I suppose :). Either way, a few weeks back I
    >> needed an app that generates deals for the card game bridge. I made a small
    >> design and hacked up some unit tests. After a while no more tests failed:

    > [snip]
    >> Not bad... Like I said, I'm not a full-time programmer. I would *love* to
    >> learn more about `proper' ruby style though. Is there even such a thing? I
    >> mean, the book cover said something about *pragmatic* :)
    >>
    >> Could anyone have a look at:
    >>
    >> http://www.van-gils.org/~bas/bridgehands/
    >>
    >> and give me some suggestions on style / ruby idiom / other things?
    >>
    >> Any help would be greatly appreciated,

    >
    > From what I've been led to understand, method names consisting of
    > multiple words should be named_with_underscores, not namedWithCamelcase.
    >
    > `puts' is the same as `print "something\n"'


    Almost. puts adds "\n" unless it's already there. So these are
    equivalent:

    print "hello\n"
    puts "hello\n"

    > Parens can be omitted if it doesn't confuse the parser (or the reader)


    Can be, but it's best not to get too cutesy with it :) In
    particular, please have mercy and don't leave the parens out in method
    signatures. Things like this:

    def a b, c, d = 1

    read very strangely, at least to my eyes.

    > As well, reserve the { } form of blocks to one-liners.


    That's going to depend partly on whether you run across the
    (relatively rare) case where the precedence difference between {} and
    do/end actually matters. There are also some interesting ideas on
    record (see archives) involving blocks with side effects vs. blocks
    that just calculate. But I can't remember which is supposed to be
    which :)

    > Then again, these are highly subjective views, ones that I've absorbed
    > from reading other people's ruby and getting into arguments with friends
    > :) Take them with a grain of salt, as I'm not a Ruby expert and thus I
    > might be wrong.


    Reading Ruby code, in particular the Ruby source code itself, is a
    great way to see the traditional style. I've never seen anyone
    improve on that style. People get very excited about the fact that
    Ruby lets you "do your own thing" in terms of style -- like:

    printf( "My name is %s\n", thisPerson.name() );

    and such... but if most Ruby were written like that I think I would
    have put the Pickaxe back on the shelf at the bookstore :)


    David

    --
    * Books:
    RAILS ROUTING (new! http://safari.awprofessional.com/9780321509246)
    RUBY FOR RAILS (http://www.manning.com/black)
    * Ruby/Rails training
    & consulting: Ruby Power and Light, LLC (http://www.rubypal.com)
     
    , Jun 12, 2007
    #7
  8. On Jun 12, 2007, at 6:59 AM, wrote:
    > Hi --
    >
    > On Tue, 12 Jun 2007, Anthony Martinez wrote:
    >
    >> On Tue, Jun 12, 2007 at 03:10:49AM +0900, Bas van Gils wrote:

    >
    >> As well, reserve the { } form of blocks to one-liners.

    >
    > That's going to depend partly on whether you run across the
    > (relatively rare) case where the precedence difference between {} and
    > do/end actually matters. There are also some interesting ideas on
    > record (see archives) involving blocks with side effects vs. blocks
    > that just calculate. But I can't remember which is supposed to be
    > which :)
    >
    > <snip>
    >
    > David
    >
    > --
    > * Books:
    > RAILS ROUTING (new! http://safari.awprofessional.com/9780321509246)
    > RUBY FOR RAILS (http://www.manning.com/black)
    > * Ruby/Rails training
    > & consulting: Ruby Power and Light, LLC (http://www.rubypal.com)


    Jim Weirich tends to be an advocate of that convention: use do-end
    for blocks that are "just blocks" and {} for blocks where the value
    of the block is to be used. If you ever see any of Jim's code that
    uses Builder, this convention is quite apparent. The problem of the
    higher precedence of the braces can often be side-stepped by
    parenthesizing the method arguments preceding the {block}. This is
    one of the reasons that the do/end form is recommended for Rakefiles
    so that the need for ()'s doesn't distract from the DSL-ish feel of
    the task method.

    I tend to merge this idea with the one for one-liners and prefer {}
    in irb where the code isn't being saved anywhere and almost never use
    {} in ERb templates where the opening and closing of the block are in
    separate <% %>'s.

    -Rob

    Rob Biedenharn http://agileconsultingllc.com
     
    Rob Biedenharn, Jun 12, 2007
    #8
  9. Bas van Gils

    Robert Dober Guest

    > Almost. puts adds "\n" unless it's already there. So these are
    > equivalent:
    >
    > print "hello\n"
    > puts "hello\n"

    Right but do you remember when I stupidly changed your code from
    puts a
    to
    puts a.join("\n")

    So this is another difference between print and puts, puts prints the
    content of an array seperated by newlines. print does no such thing of
    course.

    > particular, please have mercy and don't leave the parens out in method
    > signatures. Things like this:
    >
    > def a b, c, d = 1
    >
    > read very strangely, at least to my eyes.

    I love it, I *really* read it better like this. But I guess the
    community rather puts parens :( and if you want to comply listen to
    David.
    Let us just have a look at the Ruby core as David suggests below

    All methods
    ruby -e 'c=0;ARGF.each{|f|c+=1 if /^\s*def\s/===f};puts c' $(ruby -e
    'puts Dir["**/*.rb"]')
    18258
    ====
    All methods with parens
    ruby -e 'c=0;ARGF.each{|f|c+=1 if /^\s*def.*\(/===f};puts c' $(ruby
    -e 'puts Dir["**/*.rb"]')
    12271
    ====
    All methods without parens and without parameters
    ruby -e 'c=0;ARGF.each{|f|c+=1 if /^\s*def\s\w+\s*$/===f};puts c'
    $(ruby -e 'puts Dir["**/*.rb"]')
    5303 +
    ------
    ruby -e 'c=0;ARGF.each{|f|c+=1 if /^\s*def\s\w+\s*#/===f};puts c'
    $(ruby -e 'puts Dir["**/*.rb"]')
    94 = 5397
    --- ====
    Leaves
    ruby -e 'puts 18258 - 12271 - 5303 - 97'
    587 methods corresponding to "our" style which makes
    ruby -e 'puts 58700/18258.0'
    3.21502902837112%

    Not enough to get into parliament I'd say.



    >
    > > As well, reserve the { } form of blocks to one-liners.

    >
    > That's going to depend partly on whether you run across the
    > (relatively rare) case where the precedence difference between {} and
    > do/end actually matters. There are also some interesting ideas on
    > record (see archives) involving blocks with side effects vs. blocks
    > that just calculate. But I can't remember which is supposed to be
    > which :)
    >

    I try to avoid do end inside { }
    Beware of this too
    some_method a, b {|x| puts x}
    will not work use either parens or do...end.

    Cheers
    Robert
    --
    You see things; and you say Why?
    But I dream things that never were; and I say Why not?
    -- George Bernard Shaw
     
    Robert Dober, Jun 12, 2007
    #9
  10. Bas van Gils

    Guest

    Hi --

    On Wed, 13 Jun 2007, Robert Dober wrote:

    >> Almost. puts adds "\n" unless it's already there. So these are
    >> equivalent:
    >>
    >> print "hello\n"
    >> puts "hello\n"

    > Right but do you remember when I stupidly changed your code from
    > puts a
    > to
    > puts a.join("\n")
    >
    > So this is another difference between print and puts, puts prints the
    > content of an array seperated by newlines. print does no such thing of
    > course.
    >
    >> particular, please have mercy and don't leave the parens out in method
    >> signatures. Things like this:
    >>
    >> def a b, c, d = 1
    >>
    >> read very strangely, at least to my eyes.

    > I love it, I *really* read it better like this. But I guess the
    > community rather puts parens :( and if you want to comply listen to
    > David.
    > Let us just have a look at the Ruby core as David suggests below


    Another little test:

    $ ruby -e 'puts
    ARGF.select{|f| f =~ /^\s*def\s\w+\s+\w+/}.size' $(ruby -e 'puts
    Dir["**/*.rb"]')
    120

    $ ruby -e 'puts
    ARGF.select{|f| f =~ /^\s*def\s\w+\s+\w+/}.size' $(ruby -e 'puts
    Dir["**/*.rb"].reject {|fn| fn =~ /rexml/} ')
    9

    :) I think Sean is skewing the graph :-


    David

    --
    * Books:
    RAILS ROUTING (new! http://safari.awprofessional.com/9780321509246)
    RUBY FOR RAILS (http://www.manning.com/black)
    * Ruby/Rails training
    & consulting: Ruby Power and Light, LLC (http://www.rubypal.com)
     
    , Jun 12, 2007
    #10
  11. Bas van Gils

    Robert Dober Guest

    On 6/12/07, <> wrote:
    > Hi --
    >
    > On Wed, 13 Jun 2007, Robert Dober wrote:
    >
    > >> Almost. puts adds "\n" unless it's already there. So these are
    > >> equivalent:
    > >>
    > >> print "hello\n"
    > >> puts "hello\n"

    > > Right but do you remember when I stupidly changed your code from
    > > puts a
    > > to
    > > puts a.join("\n")
    > >
    > > So this is another difference between print and puts, puts prints the
    > > content of an array seperated by newlines. print does no such thing of
    > > course.
    > >
    > >> particular, please have mercy and don't leave the parens out in method
    > >> signatures. Things like this:
    > >>
    > >> def a b, c, d = 1
    > >>
    > >> read very strangely, at least to my eyes.

    > > I love it, I *really* read it better like this. But I guess the
    > > community rather puts parens :( and if you want to comply listen to
    > > David.
    > > Let us just have a look at the Ruby core as David suggests below

    >
    > Another little test:
    >
    > $ ruby -e 'puts
    > ARGF.select{|f| f =~ /^\s*def\s\w+\s+\w+/}.size' $(ruby -e 'puts
    > Dir["**/*.rb"]')
    > 120
    >
    > $ ruby -e 'puts
    > ARGF.select{|f| f =~ /^\s*def\s\w+\s+\w+/}.size' $(ruby -e 'puts
    > Dir["**/*.rb"].reject {|fn| fn =~ /rexml/} ')
    > 9
    >
    > :) I think Sean is skewing the graph :-

    I love that guy... ;)
    Seriously it would be stupid to advice a newby into a personal style
    that is way off mainstream and I did not.
    But I will not put parens around my defs because I feel that if Ruby
    gives me this possibility and I like it I should use it.

    Now when it comes to working in teams the whole story changes again...
    most important thing being a *consistent* style. By adopting a style
    close to mainstream that can be achieved easier....

    That is why I feel that this discussion is important.


    >
    > David
    >
    > --
    > * Books:
    > RAILS ROUTING (new! http://safari.awprofessional.com/9780321509246)
    > RUBY FOR RAILS (http://www.manning.com/black)
    > * Ruby/Rails training
    > & consulting: Ruby Power and Light, LLC (http://www.rubypal.com)
    >


    Cheers
    Robert
    --
    Books:
    Wait a minute why is nobody publishing me ;)
    Are you reading this Tim?

    Robert
     
    Robert Dober, Jun 12, 2007
    #11
  12. Bas van Gils

    Chad Perrin Guest

    On Tue, Jun 12, 2007 at 07:59:10PM +0900, wrote:
    > On Tue, 12 Jun 2007, Anthony Martinez wrote:
    > >On Tue, Jun 12, 2007 at 03:10:49AM +0900, Bas van Gils wrote:

    >
    > >Parens can be omitted if it doesn't confuse the parser (or the reader)

    >
    > Can be, but it's best not to get too cutesy with it :) In
    > particular, please have mercy and don't leave the parens out in method
    > signatures. Things like this:
    >
    > def a b, c, d = 1
    >
    > read very strangely, at least to my eyes.


    It reads a little like OCaml to me -- which is pretty strange, in the
    context of a Ruby program. I tend to like a syntax that remains constant
    across the language (which is one of the reasons I expect to find
    IronRuby to be rather disconcerting in practice, once it's finalized, and
    one of the reasons I tend to avoid .NET variants of languages in
    general).


    >
    > >As well, reserve the { } form of blocks to one-liners.

    >
    > That's going to depend partly on whether you run across the
    > (relatively rare) case where the precedence difference between {} and
    > do/end actually matters. There are also some interesting ideas on
    > record (see archives) involving blocks with side effects vs. blocks
    > that just calculate. But I can't remember which is supposed to be
    > which :)


    I have yet to see a practical case where the precedence actually came
    into play -- and I suspect that, when I do finally see such a thing,
    readability would benefit from a refactor so that it doesn't come into
    play after all.


    >
    > >Then again, these are highly subjective views, ones that I've absorbed
    > >from reading other people's ruby and getting into arguments with friends
    > >:) Take them with a grain of salt, as I'm not a Ruby expert and thus I
    > >might be wrong.

    >
    > Reading Ruby code, in particular the Ruby source code itself, is a
    > great way to see the traditional style. I've never seen anyone
    > improve on that style. People get very excited about the fact that
    > Ruby lets you "do your own thing" in terms of style -- like:
    >
    > printf( "My name is %s\n", thisPerson.name() );
    >
    > and such... but if most Ruby were written like that I think I would
    > have put the Pickaxe back on the shelf at the bookstore :)


    I like the flexibility of the language. I also like the canonical style.

    In other words, I think I agree.

    --
    CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
    Ben Franklin: "As we enjoy great Advantages from the Inventions of others
    we should be glad of an Opportunity to serve others by any Invention of
    ours, and this we should do freely and generously."
     
    Chad Perrin, Jun 12, 2007
    #12
  13. On Jun 12, 2007, at 4:47 PM, Chad Perrin wrote:

    > On Tue, Jun 12, 2007 at 07:59:10PM +0900, wrote:
    >> On Tue, 12 Jun 2007, Anthony Martinez wrote:
    >>> On Tue, Jun 12, 2007 at 03:10:49AM +0900, Bas van Gils wrote:

    >>
    >>> As well, reserve the { } form of blocks to one-liners.

    >>
    >> That's going to depend partly on whether you run across the
    >> (relatively rare) case where the precedence difference between {} and
    >> do/end actually matters. There are also some interesting ideas on
    >> record (see archives) involving blocks with side effects vs. blocks
    >> that just calculate. But I can't remember which is supposed to be
    >> which :)

    >
    > I have yet to see a practical case where the precedence actually came
    > into play -- and I suspect that, when I do finally see such a thing,
    > readability would benefit from a refactor so that it doesn't come into
    > play after all.


    assert_not_nil @enum.find do
    # ... a few lines of search code here ...
    end

    You need to switch block styles, add some parenthesis, or separate
    the two calls.

    James Edward Gray II
     
    James Edward Gray II, Jun 12, 2007
    #13
  14. Bas van Gils

    Chad Perrin Guest

    On Wed, Jun 13, 2007 at 06:51:54AM +0900, James Edward Gray II wrote:
    > On Jun 12, 2007, at 4:47 PM, Chad Perrin wrote:
    >
    > >On Tue, Jun 12, 2007 at 07:59:10PM +0900, wrote:
    > >>On Tue, 12 Jun 2007, Anthony Martinez wrote:
    > >>>On Tue, Jun 12, 2007 at 03:10:49AM +0900, Bas van Gils wrote:
    > >>
    > >>>As well, reserve the { } form of blocks to one-liners.
    > >>
    > >>That's going to depend partly on whether you run across the
    > >>(relatively rare) case where the precedence difference between {} and
    > >>do/end actually matters. There are also some interesting ideas on
    > >>record (see archives) involving blocks with side effects vs. blocks
    > >>that just calculate. But I can't remember which is supposed to be
    > >>which :)

    > >
    > >I have yet to see a practical case where the precedence actually came
    > >into play -- and I suspect that, when I do finally see such a thing,
    > >readability would benefit from a refactor so that it doesn't come into
    > >play after all.

    >
    > assert_not_nil @enum.find do
    > # ... a few lines of search code here ...
    > end
    >
    > You need to switch block styles, add some parenthesis, or separate
    > the two calls.


    Parentheses sound perfectly reasonable to me.

    --
    CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
    Leon Festinger: "A man with a conviction is a hard man to change. Tell him
    you disagree and he turns away. Show him facts and figures and he questions
    your sources. Appeal to logic and he fails to see your point."
     
    Chad Perrin, Jun 12, 2007
    #14
  15. Bas van Gils

    Bas van Gils Guest

    On Wed, Jun 13, 2007 at 04:49:01AM +0900, Robert Dober wrote:
    [...]
    > Seriously it would be stupid to advice a newby into a personal style
    > that is way off mainstream and I did not.

    [...]
    > Now when it comes to working in teams the whole story changes again...
    > most important thing being a *consistent* style. By adopting a style
    > close to mainstream that can be achieved easier....
    >
    > That is why I feel that this discussion is important.


    I agree that the discussion is important. It's a good thing that Ruby supports
    so many styles. I've programmed in several languages and I'm always curious as
    to what is considered to be `good style' by which I mean stuff like:

    - do you use {} or begin/end for blocks
    - do you use symbols or strings as keys for hashes
    - guidelines for rdoc
    - a few big classes (i.e. java style) or many small classes
    - and so on

    The advise to look at the core libs is a good one. There's a lot of code there
    and even though I don't understand all of it, it gives a good idea of how
    things work.

    More experience and more knowledge of the Ruby API is what I personally need
    now ;)

    Just-my-five-cents'ly yours

    Bas


    --
    Bas van Gils <>, http://www.van-gils.org
    [[[ Thank you for not distributing my E-mail address ]]]

    Quod est inferius est sicut quod est superius, et quod est superius est sicut
    quod est inferius, ad perpetranda miracula rei unius.
     
    Bas van Gils, Jun 13, 2007
    #15
  16. Bas van Gils

    Robert Dober Guest

    On 6/12/07, Chad Perrin <> wrote:
    <snip>
    > > That's going to depend partly on whether you run across the
    > > (relatively rare) case where the precedence difference between {} and
    > > do/end actually matters. There are also some interesting ideas on
    > > record (see archives) involving blocks with side effects vs. blocks
    > > that just calculate. But I can't remember which is supposed to be
    > > which :)

    >
    > I have yet to see a practical case where the precedence actually came
    > into play -- and I suspect that, when I do finally see such a thing,
    > readability would benefit from a refactor so that it doesn't come into
    > play after all.


    Depends a lot of your style:
    In my DSL I use at work I will write stuff like

    client :name => "allow ssh to DB", :server => "1.1.1.1" ... do
    end

    If you leave the parens away the {} just will not work, so this for
    sure is a nice feature for a DSL. That does not necessarily make it
    the best "Programming Style".
    Personally and sorry for insisting just find hat

    def recover parms = {}, &blk
    ...
    recover :from => :error do some_stuff end
    ...

    reads better (for me) than
    def recover( params ={}, &blk)
    ...
    recover( :from => :error ){ do_some_stuff }

    I dislike parens, but I am pretty alone, so I gotto refrain from
    repeating myself (still hoping for some support here, obviously ;)

    Cheers
    Robert
    > --
    > CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
    > Ben Franklin: "As we enjoy great Advantages from the Inventions of others
    > we should be glad of an Opportunity to serve others by any Invention of
    > ours, and this we should do freely and generously."

    How right he was. -- If he really said that
    >
    >



    --
    You see things; and you say Why?
    But I dream things that never were; and I say Why not?
    -- George Bernard Shaw
     
    Robert Dober, Jun 13, 2007
    #16
  17. Bas van Gils

    Guest

    Hi --

    On Wed, 13 Jun 2007, Robert Dober wrote:

    > On 6/12/07, Chad Perrin <> wrote:
    > <snip>
    >> > That's going to depend partly on whether you run across the
    >> > (relatively rare) case where the precedence difference between {} and
    >> > do/end actually matters. There are also some interesting ideas on
    >> > record (see archives) involving blocks with side effects vs. blocks
    >> > that just calculate. But I can't remember which is supposed to be
    >> > which :)

    >>
    >> I have yet to see a practical case where the precedence actually came
    >> into play -- and I suspect that, when I do finally see such a thing,
    >> readability would benefit from a refactor so that it doesn't come into
    >> play after all.

    >
    > Depends a lot of your style:
    > In my DSL I use at work I will write stuff like
    >
    > client :name => "allow ssh to DB", :server => "1.1.1.1" ... do
    > end
    >
    > If you leave the parens away the {} just will not work, so this for
    > sure is a nice feature for a DSL. That does not necessarily make it
    > the best "Programming Style".
    > Personally and sorry for insisting just find hat
    >
    > def recover parms = {}, &blk
    > ...
    > recover :from => :error do some_stuff end
    > ...
    >
    > reads better (for me) than
    > def recover( params ={}, &blk)
    > ...
    > recover( :from => :error ){ do_some_stuff }
    >
    > I dislike parens, but I am pretty alone, so I gotto refrain from
    > repeating myself (still hoping for some support here, obviously ;)


    It's not a contest -- not even a debate. Ultimately people should do
    what they want. I like to steer people, especially newcomers, to the
    traditional style, in the hope that that's what they will decide they
    want to do, partly just because it *is* the traditional style, and
    partly because on the whole it looks so great.

    That's all there is to it. You already know everything you need to
    know, and you can decide what to do. It doesn't matter who (including
    me) says what (and we already have ways to determine what Matz does).

    In other words, let's not get into one of these interminable threads
    where people try to "argue" and "convince" each other. It's just not
    that kind of situation. (And neither are 99.9999% of such threads :)


    David

    --
    * Books:
    RAILS ROUTING (new! http://safari.awprofessional.com/9780321509246)
    RUBY FOR RAILS (http://www.manning.com/black)
    * Ruby/Rails training
    & consulting: Ruby Power and Light, LLC (http://www.rubypal.com)
     
    , Jun 13, 2007
    #17

  18. > > I have yet to see a practical case where the precedence actually came
    > > into play -- and I suspect that, when I do finally see such a thing,
    > > readability would benefit from a refactor so that it doesn't come into
    > > play after all.

    >
    > assert_not_nil @enum.find do
    > # ... a few lines of search code here ...
    > end


    I think Chad's point stands. It seems whatever is encapsulated in the
    enum's find search code would be better off as a method on that
    object. That would make the test cleaner and then there won't be any
    worry about block style precedence.

    --
    -yossef
     
    Yossef Mendelssohn, Jun 13, 2007
    #18
  19. On Jun 13, 2007, at 7:37 AM, Yossef Mendelssohn wrote:

    >
    >>> I have yet to see a practical case where the precedence actually
    >>> came
    >>> into play -- and I suspect that, when I do finally see such a thing,
    >>> readability would benefit from a refactor so that it doesn't come
    >>> into
    >>> play after all.

    >>
    >> assert_not_nil @enum.find do
    >> # ... a few lines of search code here ...
    >> end

    >
    > I think Chad's point stands. It seems whatever is encapsulated in the
    > enum's find search code would be better off as a method on that
    > object. That would make the test cleaner and then there won't be any
    > worry about block style precedence.


    As long as your custom method doesn't take a block...

    James Edward Gray II
     
    James Edward Gray II, Jun 13, 2007
    #19
  20. Bas van Gils

    Robert Dober Guest

    On 6/13/07, <> wrote:
    > Hi --
    >


    >
    > It's not a contest --

    100% agree
    >not even a debate.

    100% surprised (maybe I do not grasp the semantics of debate, it means
    discussion, right?)
    > Ultimately people should do
    > what they want. I like to steer people, especially newcomers, to the
    > traditional style, in the hope that that's what they will decide they
    > want to do, partly just because it *is* the traditional style, and
    > partly because on the whole it looks so great.

    Sorry for intervening with that, but I will just be clear again:
    David's the guy to follow when in doubt, if you prefer my style you
    prefer it anyway but be warned neverheless :(.

    David has probably read and written 100 times the Ruby Code I have
    read and written (catching up though;). As he I do not think it is a
    contest, maybe I was confusing the ML with a chat forum a little
    bit...
    >
    > That's all there is to it. You already know everything you need to
    > know, and you can decide what to do. It doesn't matter who (including
    > me) says what (and we already have ways to determine what Matz does).
    >
    > In other words, let's not get into one of these interminable threads
    > where people try to "argue" and "convince" each other. It's just not
    > that kind of situation. (And neither are 99.9999% of such threads :)

    I was not trying to do this but you make me aware that I was talking
    too much, point taken.

    Over and out ;)
    Robert
    --
    You see things; and you say Why?
    But I dream things that never were; and I say Why not?
    -- George Bernard Shaw
     
    Robert Dober, Jun 13, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. earthling
    Replies:
    0
    Views:
    388
    earthling
    Mar 15, 2005
  2. Johan Tibell
    Replies:
    66
    Views:
    1,048
    Chris Torek
    Aug 7, 2006
  3. mzdude
    Replies:
    19
    Views:
    533
    James Kanze
    Aug 14, 2009
  4. Ken Varn
    Replies:
    0
    Views:
    472
    Ken Varn
    Apr 26, 2004
  5. Anders Wegge Keller

    Conditional declaration (A matter of style)

    Anders Wegge Keller, Oct 13, 2012, in forum: C Programming
    Replies:
    3
    Views:
    365
    Kaz Kylheku
    Oct 13, 2012
Loading...

Share This Page