Asp Forum - [FYKA] Plz comment

Balwinder S Dheeman

5/27/2005 2:33:00 PM

Dear Rubiest!

I'm working on a Ruby source code formatting and, or beautification
utility (http://rindent.ruby...) 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... Visit: http://count...

20 Answers

Dave Burt

5/27/2005 2:58:00 PM

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.ruby...) 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

Ralph \"PJPizza\" Siegler

5/27/2005 3:00:00 PM

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.ruby...) 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... Visit: http://count...
>

Gavin Kistner

5/27/2005 3:01:00 PM

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:

1.2.1 and 2.2.2

Nikolai Weibull

5/27/2005 3:05:00 PM

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:/...!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Ara.T.Howard

5/27/2005 3:06:00 PM

Austin Ziegler

5/27/2005 3:07:00 PM

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

Sam Roberts

5/27/2005 3:10:00 PM

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

Thomas Kirchner

5/27/2005 3:19:00 PM

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

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

dave

5/27/2005 7:44:00 PM

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.

threeve.org

5/27/2005 8:00:00 PM

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

comp.lang.ruby

[FYKA] Plz comment