[FYKA] Plz comment

ruby-talk
1

Dear Rubiest!

I'm working on a Ruby source code formatting and, or beautification utility (http://rindent.rubyforge.org/) for ruby programmers and, or developers.

Hence, I'm looking forward to your valuable ideas on how do I format the following code structures:

1) *begin*

1.1.1) as per matz:

  begin
    expr..
  [rescue [error_type,..]
    expr..]..
  [else
    expr..]
  [ensure
    expr..]
  end

1.2.1) but I prefer:

  begin
      expr..
    [rescue [error_type,..]
      expr..]..
  [else # a hanging 'else' clause
    expr..]
  [ensure # a hanging 'ensure' clause
    expr..]
  end

1.2.2) but I also like:

  begin
      expr..
    [rescue [error_type,..]
      expr..]..
    [else
      expr..]
    [ensure
      expr..]
  end

2) *case*

2.1.1) as per matz:

  case expr
  [when expr [, expr]...[then]
    expr..]..
  [else
    expr..]
  end

2.2.1) but I prefer:

  case expr
    [when expr [, expr]...[then]
      expr..]..
  [else # a hanging 'else' clause
    expr..]
  end

2.2.2) but I also like:

  case expr
    [when expr [, expr]...[then]
      expr..]..
    [else
      expr..]
  end

Whichever of above appeals you better? Or do any of you have better ideas on these? What would you expact more from such a utility? Feedback of yours shall highly be appreciated.

Regards,

···

--
Dr Balwinder Singh Dheeman Registered Linux User: #229709
CLLO (Chief Linux Learning Officer) Machines: #168573, 170593, 259192
Anu's Linux@HOME Distros: Ubuntu, Fedora, Knoppix
More: http://anu.homelinux.net/~bsd/ Visit: http://counter.li.org/

2

I vote with the indenting you've attributed to matz in all of these. I don't
see that any of these structures call for double-indenting.

Cheers,
Dave

"Dr Balwinder S Dheeman" <bsd.SANSPAM@cto.homelinux.net> asked:

···

Dear Rubiest!

I'm working on a Ruby source code formatting and, or beautification
utility (http://rindent.rubyforge.org/\) for ruby programmers and, or
developers.

Hence, I'm looking forward to your valuable ideas on how do I format the
following code structures:

1) *begin*

1.1.1) as per matz:

begin
  expr..
[rescue [error_type,..]
  expr..]..
[else
  expr..]
[ensure
  expr..]
end

1.2.1) but I prefer:

begin
    expr..
  [rescue [error_type,..]
    expr..]..
[else # a hanging 'else' clause
  expr..]
[ensure # a hanging 'ensure' clause
  expr..]
end

1.2.2) but I also like:

begin
    expr..
  [rescue [error_type,..]
    expr..]..
  [else
    expr..]
  [ensure
    expr..]
end

2) *case*

2.1.1) as per matz:

case expr
[when expr [, expr]...[then]
  expr..]..
[else
  expr..]
end

2.2.1) but I prefer:

case expr
  [when expr [, expr]...[then]
    expr..]..
[else # a hanging 'else' clause
  expr..]
end

2.2.2) but I also like:

case expr
  [when expr [, expr]...[then]
    expr..]..
  [else
    expr..]
end

3

Dr. Dheeman,

why not do them all, in other words, a configurable beautification utility, with each of those formats you listed being out-of-the box sample configuration files. Like matz.yml.sample and dr_dheeman.yml.sample?

Ralph "PJPizza" Siegler

···

On Fri, May 27, 2005 at 11:45:20PM +0900, Dr Balwinder S Dheeman wrote:

Dear Rubiest!

I'm working on a Ruby source code formatting and, or beautification
utility (http://rindent.rubyforge.org/\) for ruby programmers and, or
developers.

Hence, I'm looking forward to your valuable ideas on how do I format the
following code structures:

1) *begin*

1.1.1) as per matz:

  begin
    expr..
  [rescue [error_type,..]
    expr..]..
  [else
    expr..]
  [ensure
    expr..]
  end

1.2.1) but I prefer:

  begin
      expr..
    [rescue [error_type,..]
      expr..]..
  [else # a hanging 'else' clause
    expr..]
  [ensure # a hanging 'ensure' clause
    expr..]
  end

1.2.2) but I also like:

  begin
      expr..
    [rescue [error_type,..]
      expr..]..
    [else
      expr..]
    [ensure
      expr..]
  end

2) *case*

2.1.1) as per matz:

  case expr
  [when expr [, expr]...[then]
    expr..]..
  [else
    expr..]
  end

2.2.1) but I prefer:

  case expr
    [when expr [, expr]...[then]
      expr..]..
  [else # a hanging 'else' clause
    expr..]
  end

2.2.2) but I also like:

  case expr
    [when expr [, expr]...[then]
      expr..]..
    [else
      expr..]
  end

Whichever of above appeals you better? Or do any of you have better
ideas on these? What would you expact more from such a utility? Feedback
of yours shall highly be appreciated.

Regards,
--
Dr Balwinder Singh Dheeman Registered Linux User: #229709
CLLO (Chief Linux Learning Officer) Machines: #168573, 170593, 259192
Anu's Linux@HOME Distros: Ubuntu, Fedora, Knoppix
More: http://anu.homelinux.net/~bsd/ Visit: http://counter.li.org/

4

1.2.1 and 2.2.2

···

On May 27, 2005, at 8:45 AM, Dr Balwinder S Dheeman wrote:

Hence, I'm looking forward to your valuable ideas on how do I format the following code structures:

5

Dr Balwinder S Dheeman wrote:

Hence, I'm looking forward to your valuable ideas on how do I format the
following code structures:

1) *begin*

1.1.1 is what I use.

2) *case*

Again, 2.1.1 is most logical, to me anyway,
        nikolai

···

--
Nikolai Weibull: now available free of charge at http://bitwi.se/\!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

6

Hence, I'm looking forward to your valuable ideas on how do I format the
following code structures:
1) *begin*
1.1.1) as per matz:

        begin
          expr..
        [rescue [error_type,..]
          expr..]..
        [else
          expr..]
        [ensure
          expr..]
        end

I prefer this, because the rescue, else, and ensure clauses belong to
the begin/end block and are not subordinate to it. The expressions for
those clauses are subordinate, but the clauses themselves are not. I
think that matz has these correct.

2.1.1) as per matz:

        case expr
        [when expr [, expr]...[then]
          expr..]..
        [else
          expr..]
        end

See above.

You can make this configurable, but the defaults should follow Matz's
style as much as is possible.

-austin

···

On 5/27/05, Dr Balwinder S Dheeman <bsd.SANSPAM@cto.homelinux.net> wrote:
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

7

Personally, I prefer either matz's way or your third way (where the
things inside the block are at the same indentation level). To me,
that's important in clarifying the block. It lets you know that all
elements at this indentation level are of the same structure, whether
it's a block, case, if, etc. If you have the "else" further left than
the "rescue", or similar, my eyes would naturally ignore the rescue as
part of that semantic block.

Also, I'll be interested in seeing how your project comes along. Ruby is
naturally beautiful, but I have a tendency to write compact (ugly) code.
I think it'd be hard for a utility to beautify code that is ugly not
because of its spacing but because of the
(compact/ugly/archaic/compressed) style used.

Just as a simple example - would it turn C-style (if x ? yes : no) into
longer if/else blocks? Things like this are "ugly" because of the
concept used, not its placement in the text. Of course, it's possible to
just ignore things like this and beautify the things you're sure about.

Tom

···

* On May 27 23:45, Dr Balwinder S Dheeman (ruby-talk@ruby-lang.org) wrote:

Whichever of above appeals you better? Or do any of you have better
ideas on these? What would you expact more from such a utility?
Feedback of yours shall highly be appreciated.

8

Dear Rubiest!

I'm working on a Ruby source code formatting and, or beautification utility (http://rindent.rubyforge.org/\) for ruby programmers and, or developers.

Hence, I'm looking forward to your valuable ideas on how do I format the following code structures:

1) *begin*

1.1.1) as per matz:

  begin
    expr..
  [rescue [error_type,..]
    expr..]..
  [else
    expr..]
  [ensure
    expr..]
  end

1.2.1) but I prefer:

  begin
      expr..
    [rescue [error_type,..]
      expr..]..
  [else # a hanging 'else' clause
    expr..]
  [ensure # a hanging 'ensure' clause
    expr..]
  end

1.2.2) but I also like:

  begin
      expr..
    [rescue [error_type,..]
      expr..]..
    [else
      expr..]
    [ensure
      expr..]
  end

vote: 1.1.1

2) *case*

2.1.1) as per matz:

  case expr
  [when expr [, expr]...[then]
    expr..]..
  [else
    expr..]
  end

2.2.1) but I prefer:

  case expr
    [when expr [, expr]...[then]
      expr..]..
  [else # a hanging 'else' clause
    expr..]
  end

2.2.2) but I also like:

  case expr
    [when expr [, expr]...[then]
      expr..]..
    [else
      expr..]
  end

vote: 2.1.1

why? because it makes it much easier to determine which 'when' goes with
which 'case' and which 'rescue' goes with which 'begin' in deeply nested code.

eg. (1.1.1)

   begin
     begin
       begin
         begin
         rescue
         else
         ensure
         end
       rescue
       else
       ensure
       end
     rescue
     else
     ensure
     end
   rescue
   else
   ensure
   end

just becomes madness if begin/rescue/end aren't lined up horizontally and are
100 lines apart as in

eg. (1.2.1)

   begin
     begin
       begin
         begin
           rescue
         else
         ensure
         end
         rescue
       else
       ensure
       end
       rescue
     else
     ensure
     end
     rescue
   else
   ensure
   end

or even 1.2.2

   begin
     begin
       begin
         begin
           rescue
           else
           ensure
           end
         rescue
         else
         ensure
         end
       rescue
       else
       ensure
       end
     rescue
     else
     ensure
   end

none of them are easy - but with 1.1.1 and a folding editor it's a least quite
managable.

cheers - and thanks for working on this project!

-a

···

On Fri, 27 May 2005, Dr Balwinder S Dheeman wrote:
--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
My religion is very simple. My religion is kindness.
--Tenzin Gyatso

===============================================================================

9

I'm for Matz, his style is more compact.

···

--

here are more things in heaven and earth,

horatio, than are dreamt of in your philosophy.

10

Dr Balwinder S Dheeman wrote:

1.1.1) as per matz:

    begin
      expr..
    [rescue [error_type,..]
      expr..]..
    [else
      expr..]
    [ensure
      expr..]
    end

This one.

2.2.2) but I also like:

    case expr
      [when expr [, expr]...[then]
        expr..]..
      [else
        expr..]
    end

And this one.

Reasons are that I think that it is a bad idea to use multiple different indentation levels when there is no nesting going on.

While you could decide to align the case with the when and else in the last one I feel that it stands out better this way without obfuscating start or end. With this you can also do this:

speed = case direction
   when :left then -5
   else +5
end

But having options is a good choice for restyling tools.

11

Picking the "best" option for your users might keep some users away
from using your tool. I strongly suggest you leave the formatting
style as a choice for the user.

Cheers,
Ed

···

On 5/27/05, Dr Balwinder S Dheeman <bsd.SANSPAM@cto.homelinux.net> wrote:

Dear Rubiest!

I'm working on a Ruby source code formatting and, or beautification
utility (http://rindent.rubyforge.org/\) for ruby programmers and, or
developers.

Hence, I'm looking forward to your valuable ideas on how do I format the
following code structures:

[snip]

--
Encontrá a "Tu psicópata favorito" http://tuxmaniac.blogspot.com

"Tener una amiga en Ginebra es como tener quinotos en almibar o uvas en ron."
"Programming is like sex... make one mistake, and support it the rest
of your life."
"Defeat is an accomplishment not even the best of us could achieve."

12

Dr Balwinder S Dheeman wrote:

Dear Rubiest!

I'm working on a Ruby source code formatting and, or beautification utility (http://rindent.rubyforge.org/\) for ruby programmers and, or developers.

Hence, I'm looking forward to your valuable ideas on how do I format the following code structures:

1) *begin*

1.1.1) as per matz:

    begin
      expr..
    [rescue [error_type,..]
      expr..]..
    [else
      expr..]
    [ensure
      expr..]
    end

1.2.1) but I prefer:

    begin
        expr..
      [rescue [error_type,..]
        expr..]..
    [else # a hanging 'else' clause
      expr..]
    [ensure # a hanging 'ensure' clause
      expr..]
    end

1.2.2) but I also like:

    begin
        expr..
      [rescue [error_type,..]
        expr..]..
      [else
        expr..]
      [ensure
        expr..]
    end

2) *case*

2.1.1) as per matz:

    case expr
    [when expr [, expr]...[then]
      expr..]..
    [else
      expr..]
    end

2.2.1) but I prefer:

    case expr
      [when expr [, expr]...[then]
        expr..]..
    [else # a hanging 'else' clause
      expr..]
    end

2.2.2) but I also like:

    case expr
      [when expr [, expr]...[then]
        expr..]..
      [else
        expr..]
    end

Whichever of above appeals you better? Or do any of you have better ideas on these? What would you expact more from such a utility? Feedback of yours shall highly be appreciated.

Regards,

my $0.02 ==> ever since Pascal I've formatted my code to make the block as a whole visible in one glance. Therefor I indent everything IN the block relative to the beginning of the block (that includes the "end" statement). That way my eyes can "travel" swiftly from block to block, a block simply ends where my eyes catch the next "out-dentation". It works for *me*...

> 1.2.3) as per me:
>
> begin
> expr..
> [rescue [error_type,..]
> expr..]..
> [else
> expr..]
> [ensure
> expr..]
> end

Since the rescue, else and ensure statements are at the level of the block, I put them at the same indentation. They can themselves "lead in" a block which will be indented relative to the lead in statement. Works like a charm, again, for *me*...

> 2.2.3) as per me:
>
> case expr
> [when expr [, expr]...[then]
> expr..]..
> [else
> expr..]
> end
>

Luc

13

Quoting dave@burt.id.au, on Sat, May 28, 2005 at 12:00:20AM +0900:

I vote with the indenting you've attributed to matz in all of these. I don't
see that any of these structures call for double-indenting.

How matz does it.

The only point of consistent indenting its that it be... consistent.

If I was inventing from scratch, I might do as you prefer, too, but as
I code in ruby, I do as Matz does.

Cheers,
Sam

14

If I had to pick, I'd pick Matz's style as well. The other identation
options don't really make any sense because related elements aren't
always on the same level.

What would be ideal is to make a tool that can be setup with arbitrary
rules and can change as my style preference or standards (or those
imposed on me by a customer/project) change.

Jason

15

Thomas Kirchner wrote:

Whichever of above appeals you better? Or do any of you have better ideas on these? What would you expact more from such a utility? Feedback of yours shall highly be appreciated.

Personally, I prefer either matz's way or your third way (where the things inside the block are at the same indentation level). To me, that's important in clarifying the block. It lets you know that all elements at this indentation level are of the same structure, whether it's a block, case, if, etc. If you have the "else" further left than the "rescue", or similar, my eyes would naturally ignore the rescue as part of that semantic block.

Also, I'll be interested in seeing how your project comes along. Ruby is naturally beautiful, but I have a tendency to write compact (ugly) code. I think it'd be hard for a utility to beautify code that is ugly not because of its spacing but because of the (compact/ugly/archaic/compressed) style used.

You know me too am a newbie to Ruby as yet, that's why one in while I look at Ruby code which others have written. I saw a lot of inconsistancy in placing commas, spaces and tabs (even if most of the editors now a days come with syntax highlighting and other such features) people ignore and, or skip over while concentarting on the real target. I would prefer keeping the code as compact as possible

Just as a simple example - would it turn C-style (if x ? yes : no) into longer if/else blocks? Things like this are "ugly" because of the concept used, not its placement in the text. Of course, it's possible to just ignore things like this and beautify the things you're sure about.

I shall try making the 'rindent' as configurable as possible.

···

* On May 27 23:45, Dr Balwinder S Dheeman (ruby-talk@ruby-lang.org) wrote:

--
Dr Balwinder Singh Dheeman Registered Linux User: #229709
CLLO (Chief Linux Learning Officer) Machines: #168573, 170593, 259192
Anu's Linux@HOME Distros: Ubuntu, Fedora, Knoppix
More: http://anu.homelinux.net/~bsd/ Visit: http://counter.li.org/

16

Ralph "PJPizza" Siegler wrote:

Dr. Dheeman,

why not do them all, in other words, a configurable beautification utility, with each of those formats you listed being out-of-the box sample configuration files. Like matz.yml.sample and dr_dheeman.yml.sample?

+1, I shall :slight_smile:

···

--
Dr Balwinder Singh Dheeman Registered Linux User: #229709
CLLO (Chief Linux Learning Officer) Machines: #168573, 170593, 259192
Anu's Linux@HOME Distros: Ubuntu, Fedora, Knoppix
More: http://anu.homelinux.net/~bsd/ Visit: http://counter.li.org/

17

Edgardo Hames wrote:

···

On 5/27/05, Dr Balwinder S Dheeman <bsd.SANSPAM@cto.homelinux.net> wrote:

Dear Rubiest!

I'm working on a Ruby source code formatting and, or beautification
utility (http://rindent.rubyforge.org/\) for ruby programmers and, or
developers.

Hence, I'm looking forward to your valuable ideas on how do I format the
following code structures:

[snip]

Picking the "best" option for your users might keep some users away
from using your tool. I strongly suggest you leave the formatting
style as a choice for the user.

That's a good point, other posters have also suggested similary. I will make matz's style (most common) as default, but users may opt for other available style if they wish and, or like so.

--
Dr Balwinder Singh Dheeman Registered Linux User: #229709
CLLO (Chief Linux Learning Officer) Machines: #168573, 170593, 259192
Anu's Linux@HOME Distros: Ubuntu, Fedora, Knoppix
More: http://anu.homelinux.net/~bsd/ Visit: http://counter.li.org/

18

Luc Dubois wrote:

Dr Balwinder S Dheeman wrote:

Dear Rubiest!

I'm working on a Ruby source code formatting and, or beautification utility (http://rindent.rubyforge.org/\) for ruby programmers and, or developers.

Hence, I'm looking forward to your valuable ideas on how do I format the following code structures:

1) *begin*

1.1.1) as per matz:

    begin
      expr..
    [rescue [error_type,..]
      expr..]..
    [else
      expr..]
    [ensure
      expr..]
    end

1.2.1) but I prefer:

    begin
        expr..
      [rescue [error_type,..]
        expr..]..
    [else # a hanging 'else' clause
      expr..]
    [ensure # a hanging 'ensure' clause
      expr..]
    end

1.2.2) but I also like:

    begin
        expr..
      [rescue [error_type,..]
        expr..]..
      [else
        expr..]
      [ensure
        expr..]
    end

2) *case*

2.1.1) as per matz:

    case expr
    [when expr [, expr]...[then]
      expr..]..
    [else
      expr..]
    end

2.2.1) but I prefer:

    case expr
      [when expr [, expr]...[then]
        expr..]..
    [else # a hanging 'else' clause
      expr..]
    end

2.2.2) but I also like:

    case expr
      [when expr [, expr]...[then]
        expr..]..
      [else
        expr..]
    end

Whichever of above appeals you better? Or do any of you have better ideas on these? What would you expact more from such a utility? Feedback of yours shall highly be appreciated.

Regards,

my $0.02 ==> ever since Pascal I've formatted my code to make the block as a whole visible in one glance. Therefor I indent everything IN the block relative to the beginning of the block (that includes the "end" statement). That way my eyes can "travel" swiftly from block to block, a block simply ends where my eyes catch the next "out-dentation". It works for *me*...

> 1.2.3) as per me:
>
> begin
> expr..
> [rescue [error_type,..]
> expr..]..
> [else
> expr..]
> [ensure
> expr..]
> end

Since the rescue, else and ensure statements are at the level of the block, I put them at the same indentation. They can themselves "lead in" a block which will be indented relative to the lead in statement. Works like a charm, again, for *me*...

> 2.2.3) as per me:
>
> case expr
> [when expr [, expr]...[then]
> expr..]..
> [else
> expr..]
> end
>

Luc

Oops! There is one indent that got eaten by my Thunderbird editor (tab expansion going wrong I guess), it should look like:

> 1.2.3) as per me:
>
> begin
> expr..
> [rescue [error_type,..]
> expr..]..
> [else
> expr..]
> [ensure
> expr..]
> end

> 2.2.3) as per me:
>
> case expr
> [when expr [, expr]...[then]
> expr..]..
> [else
> expr..]
> end

Sorry 'bout that! I hope this goes accross correctly.

Luc

19

Hi --

Quoting dave@burt.id.au, on Sat, May 28, 2005 at 12:00:20AM +0900:

I vote with the indenting you've attributed to matz in all of these. I don't
see that any of these structures call for double-indenting.

How matz does it.

The only point of consistent indenting its that it be... consistent.

If I was inventing from scratch, I might do as you prefer, too, but as
I code in ruby, I do as Matz does.

I agree strongly. Ruby has a beautiful and perfectly useable
traditional/Matz style. It can be exhilerating to realize you're
"allowed" to indent things differently, give your methods camelCase
names, put semicolons at the end of each line (because you "come from"
C or Perl), and all of that. But only in the short run. In the long
run, the traditional style is going to come across as more attractive
as well as more consistent. (Didn't a lot of us start looking closely
at Ruby in part because of how it looked?)

David

···

On Sat, 28 May 2005, Sam Roberts wrote:

--
David A. Black
dblack@wobblini.net

20

I would prefer keeping the code as compact as possible

Well, that's the problem - you don't always want it as compact as
possible. If you're trying to beautify ruby code you're going to need
some smart logic for when to expand and when to contract. You don't want
everything turning out like the IORCC :slight_smile:
(http://iorcc.dyndns.org/\)

I shall try making the 'rindent' as configurable as possible.

Cool! I look forward to seeing the results.
Tom

···

* On May 28 10:15, Dr Balwinder S Dheeman (ruby-talk@ruby-lang.org) wrote: