[sf-perl] perltidy frustration
Kevin Frost
biztos at mac.com
Mon Feb 11 15:30:18 PST 2013
FWIW YMMV and all that, but: my main argument, separate from PBP, for a 78-char line width has always been this:
There *will* be situations where you are studying code *diffs* in narrow and/or unpredictable-width environments.
The most common are:
* Overhead projectors.
* E-mails.
* Printouts.
If you go with 78 characters you have 80 including the diffing symbol and space, you have a very good chance of having legible and consistent output in the different environments.
Granted, this argument is equally applicable to 77 and 81 character widths, but 80 (with diff) is just easier to remember, at least for anyone over a certain age. As an exact number it is arbitrary, but as a ballpark figure (really, within a couple characters) it is not at all arbitrary.
Damian's version of the argument goes like this, as you probably already know:
> In these modern days of high-resolution 30-inch screens, anti-aliased fonts, and laser eyesight correction, it's entirely possible to program in a terminal window that's 300 columns wide.
>
> Please don't.
>
> Given the limitations of printed documents, legacy VGA display devices, presentation software, and unreconstructed managerial optics, it isn't reasonable to format code to a width greater than 80 columns. And even an 80-column line width is not always safe, given the text-wrapping characteristics of some terminals, editors, and mail systems.
>
> Setting your right margin at 78 columns maximizes the usable width of each code line whilst ensuring that those lines appear consistently on the vast majority of display devices.
If you haven't tried the diff-reviewing argument you might want to. I think it would be pretty easy to show why 78 beats 120 in that context.
Or you might want to just suffer through the existing standards until you have more clout. ;-)
cheers
-- f.
On Feb 12, 2013, at 12:16 AM, Michael Friedman wrote:
> Kevin,
>
> I'm 100% with you. My last office used PBP style. Alas, I'm not in control of the style at my new office and have to conform to their idiosyncratic existing system. I've tried to convince them to change, but to no avail. Maybe when I've been here a bit longer I'll have more pull, but I just started a couple of months ago.
>
> The main impediment to the PBP kind of stacking you point out is the 120 character line length. Shortening it makes the code wrap much better, to my eyes, but I'm not allowed to change that setting. Maybe I'll bring up that issue again...
>
> Thanks,
> -- Mike
>
> On Feb 11, 2013, at 3:11 PM, Kevin Frost <biztos at mac.com> wrote:
>
>> For your second example, are you worried about it merging lines on that $req->div call?
>>
>> I find this pretty readable, from the latest perltidy on 5.12.3 with PBP options:
>>
>> return $req->div(
>> { id => $id,
>> class => "mod_stack $class size_$size",
>> },
>> $req->div(
>> { class => 'mod_stack_layer' },
>> $req->div(
>> { class => 'mod_stack_layer' },
>> $req->div( { class => 'mod_stack_content' }, $content ),
>> ),
>> ),
>> );
>>
>> So that last div() method call is not quite as bunched up.
>>
>> As for your .perltidyrc, I have after many years come to the conclusion that, while I am sure I am capable of writing The World's Best Perltidyrc, so are a bunch of other people and we'd never really agree. Thus best to use the Perl Best Practices defaults, because they are well-known and well-documented and you can spend the energy coding instead of arguing about style. Yes, this means using some policies you may disagree with, but it's for the greater good!
>>
>> You may of course disagree with that statement, but if you have control over the policies or perhaps are just laboring under some legacy prima donna's code style standards I really encourage you to give it some serious thought.
>>
>> cheers
>>
>> -- frosty
>>
>> On Feb 11, 2013, at 7:31 PM, Michael Friedman wrote:
>>
>>> I'm trying to get my new office (Polyvore.com -- we're hiring, BTW) to adopt perltidy for their existing, but complicated, code style standards. I've managed to get it relatively close, but I'm running into a wall with two particular cases. Since a number of SFPM members seem to be masters of perltidy, I wondered if anyone might have an idea of what I can try to get these to work. (My .perltidyrc is at the bottom of this email.)
>>>
>>> Thanks for any advice!
>>> -- Mike Friedman
>>>
>>> First case: How do I get perltidy to line up equal signs with other equal-like things, like ||=, //=, and so on? The lining-up-of-equals doesn't seem to be controllable by any of the flags I could find. The BEFORE code is turned into the AFTER code by perltidy with my options.
>>>
>>> BEFORE:
>>> $params->{_default_sort} = '-count';
>>> $params->{_sort_map} = TAG_SORT;
>>> $params->{_limit} ||= Cons::MAX_CLEAN_TAGS;
>>> $sql = _limit_order($sql, $params);
>>>
>>> AFTER:
>>> $params->{_default_sort} = '-count';
>>> $params->{_sort_map} = TAG_SORT;
>>> $params->{_limit} ||= Cons::MAX_CLEAN_TAGS;
>>> $sql = _limit_order($sql, $params);
>>>
>>>
>>>
>>> Second case: The BEFORE code is turned into the AFTER code. The statement about 'mod_stack_layer' is arguably more readable before than after, but I can't get perltidy to not merge the lines as it does. For other reasons I'm not allowed to shorten the line length < 120 characters or to make all lists vertical. I know I could put in a format-skipping marker (#<<< do not let perltidy touch this), but this construction occurs often enough to make that painful.
>>>
>>> Any ideas on how I can get this to stay broken the old way?
>>>
>>> BEFORE:
>>> sub render_stack {
>>> my ($resp, $item, $options) = @_;
>>> my $req = $resp->request();
>>>
>>> my $size = $options->{size} || 's';
>>> my $class = $options->{class} || '';
>>> my $renderer = $options->{renderer} || \&render_item;
>>>
>>> my $content = &$renderer($resp, $item, { size => $size });
>>>
>>> my $id = $options->{id} || Request::dom_unique_id();
>>>
>>> return $req->div({
>>> id => $id,
>>> class => "mod_stack $class size_$size",
>>> },
>>> $req->div({ class => 'mod_stack_layer' },
>>> $req->div({ class => 'mod_stack_layer' },
>>> $req->div({ class => 'mod_stack_content' }, $content),
>>> ),
>>> ),
>>> );
>>> }
>>>
>>> AFTER:
>>> sub render_stack {
>>> my ($resp, $item, $options) = @_;
>>> my $req = $resp->request();
>>>
>>> my $size = $options->{size} || 's';
>>> my $class = $options->{class} || '';
>>> my $renderer = $options->{renderer} || \&render_item;
>>>
>>> my $content = &$renderer($resp, $item, { size => $size });
>>>
>>> my $id = $options->{id} || Request::dom_unique_id();
>>>
>>> return $req->div({
>>> id => $id,
>>> class => "mod_stack $class size_$size",
>>> },
>>> $req->div(
>>> { class => 'mod_stack_layer' },
>>> $req->div({ class => 'mod_stack_layer' }, $req->div({ class => 'mod_stack_content' }, $content),),
>>> ),
>>> );
>>> }
>>>
>>>
>>>
>>>
>>>
>>> .perltidyrc:
>>> -l=120 # Max line width of 120 cols
>>> -i=4 # Indent is 4 spaces
>>> -ci=2 # Continuation indent is also 4
>>> #-st # Output to STDOUT
>>> -se # Errors to STDERR
>>> -vt=2 # Max vertical tightness for opening blocks
>>> -cti=0 # No extra indentation for closing brackets
>>> -ce # Use "cuddled" else
>>> -bar # Open brace always on right
>>> -pt=2 # Max parens tightness
>>> -bt=1 # Medium brace tightness
>>> -bvt=0 # Min non-code-block brace tightness
>>> -sbt=2 # Max square bracket tightness
>>> -bbt=1 # Medium block brace tightness
>>> -sot # Stack opening tokens
>>> -sct # Stack closing tokens
>>> -nsfs # No space before semicolons
>>> -nolq # Don't outdent long quoted strings
>>> -nbbc # No blank line before comment line
>>> -msc=1 # Minimum space to trailing comment
>>> -wbb="% + - * / x != == >= <= =~ !~ < > | & = **= += *= &= <<= &&= -= /= |= >>= ||= .= %= ^= x="
>>> # Break before all operators, not just the defaults
>>>
>>> _______________________________________________
>>> SanFrancisco-pm mailing list
>>> SanFrancisco-pm at pm.org
>>> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>>
>
More information about the SanFrancisco-pm
mailing list