Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > a matter of style

Reply
Thread Tools

a matter of style

 
 
Robert Dober
Guest
Posts: n/a
 
      06-12-2007
On 6/12/07, http://www.velocityreviews.com/forums/(E-Mail Removed) <(E-Mail Removed)> 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

 
Reply With Quote
 
 
 
 
Chad Perrin
Guest
Posts: n/a
 
      06-12-2007
On Tue, Jun 12, 2007 at 07:59:10PM +0900, (E-Mail Removed) 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."

 
Reply With Quote
 
 
 
 
James Edward Gray II
Guest
Posts: n/a
 
      06-12-2007
On Jun 12, 2007, at 4:47 PM, Chad Perrin wrote:

> On Tue, Jun 12, 2007 at 07:59:10PM +0900, (E-Mail Removed) 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


 
Reply With Quote
 
Chad Perrin
Guest
Posts: n/a
 
      06-12-2007
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, (E-Mail Removed) 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."

 
Reply With Quote
 
Bas van Gils
Guest
Posts: n/a
 
      06-13-2007
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 <(E-Mail Removed)>, 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.


 
Reply With Quote
 
Robert Dober
Guest
Posts: n/a
 
      06-13-2007
On 6/12/07, Chad Perrin <(E-Mail Removed)> 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

 
Reply With Quote
 
dblack@wobblini.net
Guest
Posts: n/a
 
      06-13-2007
Hi --

On Wed, 13 Jun 2007, Robert Dober wrote:

> On 6/12/07, Chad Perrin <(E-Mail Removed)> 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)

 
Reply With Quote
 
Yossef Mendelssohn
Guest
Posts: n/a
 
      06-13-2007

> > 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


 
Reply With Quote
 
James Edward Gray II
Guest
Posts: n/a
 
      06-13-2007
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

 
Reply With Quote
 
Robert Dober
Guest
Posts: n/a
 
      06-13-2007
On 6/13/07, (E-Mail Removed) <(E-Mail Removed)> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
A matter of exception reporting style mzdude C++ 19 08-14-2009 08:16 PM
Checking return values for errors, a matter of style? Johan Tibell C Programming 66 08-07-2006 05:36 PM
A matter of style and referential integrity! earthling XML 0 03-15-2005 09:01 AM
Whattsa Matter, Dark Matter?? A.Melon DVD Video 0 05-16-2004 07:05 AM
Need help with Style conversion from Style object to Style key/value collection. Ken Varn ASP .Net Building Controls 0 04-26-2004 07:06 PM



Advertisments