Your original spacing/formatting did not come through, so I reformatted it
myself, as I'm guessing that you would have intended. I've also
interspersed my comments.
Here are some examples of issues that can arise (note: I'm not sure if my
original spacing will survive email!)
1. Integers can be a big problem. They may or may not look okay when
formatted this way. Consider:
my $low = 1;
my $delta = 2;
my $hi = 101.1;
This isn't too bad but it isn't so great either.
In this case, as a programmer, I would put an empty line between $delta and
$hi, which would then fix the "isn't so great" issue.
Consider:
my $i = 0;
my $conversion_factor = 37458978.21;
This doesn't look good at all.
This is clearly a case where a blank line between $i and $conversion_factor
would make things much more readable.
2. It is very common to have additional operations in lists of numbers,
and these may pose a problem. Consider
my $conversion_factor = 37458978.21;
my $conversion_factor2 = 167.22 * 2;
This might be okay. But consider
my $conversion_factor = 37458978.21;
my $pi2 = 3.14159 * 2;
my $pi4 = 4 * 3.14159;
my $tol = 0.00000025;
This is getting hard to read.
This is two separate issues. The $pi2 and $pi4 lines should be structured
the same (float times integer or integer times float, but not both), so
this is a problem with the programmer. Additionally, those two lines
should be separated from the two lines declaring the constants
$conversion_factor and $tol. If a programmer were to reformat it the way
I'm suggesting, then the alignment is acceptable:
my $conversion_factor = 37_458_978.21;
my $tol = 0.00_000_025;
my $pi2 = 2 * 3.14159;
my $pi4 = 4 * 3.14159;
3. Adding the extra spaces to align numbers this way in lists may cause an
entire list to be expanded in a very undesirable way.
I'm totally agreeing that this might be an issue, which is why you have the
#<<< and #>>> anchors. You might also consider a special case of those
tags:
#<<<no-align-numbers
my @perfect_numbers = (
6,
28,
496,
8_128,
33_550_336,
8_589_869_056,
137_438_691_328,
2_305_843_008_139_952_128,
2_658_455_991_569_831_744_654_692_615_953_842_176
);
#>>>
Which would reformat that code:
#<<<no-align-numbers
my @perfect_numbers = (
6,
28,
496,
8_128,
33_550_336,
8_589_869_056,
137_438_691_328,
2_305_843_008_139_952_128,
2_658_455_991_569_831_744_654_692_615_953_842_176
);
#>>>
Which is less readable, but gets my point across.
So, to summarize, a lot of your issues seem like they could be solved with
some blank lines, or perhaps a way of turning off the alignment for a
particular block of code.
Bob
On Thu, Jun 7, 2018 at 7:25 AM Steven Hancock via RT <
bug-Perl-Tidy@rt.cpan.org> wrote:
Show quoted text> <URL:
https://rt.cpan.org/Ticket/Display.html?id=125497 >
>
> Here are some examples of issues that can arise (note: I'm not sure if my
> original spacing will survive email!)
>
>
> 1. Integers can be a big problem. They may or may not look okay when
> formatted this way. Consider:
>
>
> my $low = 1;
>
> my $delta = 2;
>
> my $hi = 101.1;
>
>
> This isn't too bad but it isn't so great either.
>
>
> Consider:
>
>
> my $i = 0;
>
> my $conversion_factor = 37458978.21;
>
>
> This doesn't look good at all.
>
>
> 2. It is very common to have additional operations in lists of numbers,
>
> and these may pose a problem. Consider
>
>
> my $conversion_factor = 37458978.21;
>
> my $conversion_factor2 = 167.22 * 2;
>
>
> This might be okay. But consider
>
>
> my $conversion_factor = 37458978.21;
>
> my $pi2 = 3.14159 * 2;
>
> my $pi4 = 4 * 3.14159;
>
> my $tol = 0.00000025;
>
>
> This is getting hard to read.
>
>
>
> 3. Adding the extra spaces to align numbers this way in lists may cause an
>
> entire list to be expanded in a very undesirable way.
>
>
>
>
> On Wed, Jun 6, 2018 at 10:04 AM, Bob Kleemann via RT <
> bug-Perl-Tidy@rt.cpan.org> wrote:
>
> not
> > start with 0), decimal (a series of numbers followed by period, followed
> by
> > another series of numbers), floating point (a decimal, followed by an
> 'e',
> > followed by an integer), binary/octal/hex, and I think that's it. All of
> > the values should be aligned on the single units or the period, except
> the
> > binary/octal/hex, which should be aligned on the leading 0 (in my
> opinion,
> > I can see discussion on that point).
> >
> > On Wed, Jun 6, 2018 at 6:58 AM Steven Hancock via RT <
> > bug-Perl-Tidy@rt.cpan.org> wrote:
> >
> of
> > > values.
> > > I did look into it at one time but found that there were so many
> > > possible variations that it was hard to code.
> > > Steve
> > >
> > > On Tue, Jun 5, 2018 at 1:40 PM, Bob Kleemann via RT <
> > > bug-Perl-Tidy@rt.cpan.org> wrote:
> > >
> > > > Tue Jun 05 16:40:42 2018: Request 125497 was acted upon.
> > > > Transaction: Ticket created by rkleemann@gmail.com
> > > > Queue: Perl-Tidy
> > > > Subject: Support aligning numbers correctly
> > > > Broken in: (no value)
> > > > Severity: (no value)
> > > > Owner: Nobody
> > > > Requestors: rkleemann@gmail.com
> > > > Status: new
> > > > Ticket <URL:
https://rt.cpan.org/Ticket/Display.html?id=125497 >
> > > >
> > > >
> > > > It would be nice if numbers were aligned in a sensible way, on the
> > > decimal
> > > > point. Currently, all numbers are left-aligned, which makes sense in
> > the
> > > > simple case, but it would be nice if the following code aligned
> > properly:
> > > >
> > > > my $price = 102.99;
> > > > my $adjustment = -2.99;
> > > > my $tax = 1.0775;
> > > > my $final = ( $price + $adjustment ) * $tax;
> > > >
> > > >
> > > > Of course, there is some question about how to align some of the more
> > > > elaborate number formats:
> > > >
> > > > my $avagadro = 6.022140857E23;
> > > > my $YYYYddd = 2018.156;
> > > > my $pi = 3.14159265;
> > > >
> > > > my $green = 0x00ff00;
> > > > my $rwxrw_rw_ = 0766;
> > > > my $escape = 0b00011011;
> > > >
> > > >
> > > > I think I've aligned them in a way that makes sense here, but I could
> > see
> > > > arguments for other alignments.
> > > >
> > > > Bob
> > > >
> > > >
> > >
> > >
> >
> >
>
>
