File Manager - BorneoXploit

Editing: stylekey.html

<?xml version="1.0" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<link rev="made" href="mailto:root@localhost" />
</head>

<body>

<ul id="index">
 <li><a href="#Perltidy-Style-Key">Perltidy Style Key</a>
 <ul>
 <li><a href="#Before-You-Start">Before You Start</a></li>
 <li><a href="#Use-as-Filter">Use as Filter?</a></li>
 <li><a href="#Line-Length-Setting">Line Length Setting</a></li>
 <li><a href="#Indentation-in-Code-Blocks">Indentation in Code Blocks</a></li>
 <li><a href="#Continuation-Indentation">Continuation Indentation</a></li>
 <li><a href="#Tabs">Tabs</a></li>
 <li><a href="#Opening-Block-Brace-Right-or-Left">Opening Block Brace Right or Left?</a></li>
 <li><a href="#Opening-Braces-Right">Opening Braces Right</a></li>
 <li><a href="#Cuddled-Else">Cuddled Else?</a></li>
 <li><a href="#Opening-Braces-Left">Opening Braces Left</a></li>
 <li><a href="#Opening-Sub-Braces">Opening Sub Braces</a></li>
 <li><a href="#Block-Brace-Vertical-Tightness">Block Brace Vertical Tightness</a></li>
 <li><a href="#Closing-Block-Brace-Indentation">Closing Block Brace Indentation</a></li>
 <li><a href="#Indentation-Style-for-Other-Containers">Indentation Style for Other Containers</a></li>
 <li><a href="#Welding">Welding</a></li>
 <li><a href="#Opening-Vertical-Tightness">Opening Vertical Tightness</a></li>
 <li><a href="#Closing-Token-Placement">Closing Token Placement</a></li>
 <li><a href="#Stack-Opening-Tokens">Stack Opening Tokens</a></li>
 <li><a href="#Stack-Closing-Tokens">Stack Closing Tokens</a></li>
 <li><a href="#Define-Horizontal-Tightness">Define Horizontal Tightness</a></li>
 <li><a href="#Spaces-between-function-names-and-opening-parens">Spaces between function names and opening parens</a></li>
 <li><a href="#Spaces-between-Perl-keywords-and-parens">Spaces between Perl keywords and parens</a></li>
 <li><a href="#Statement-Termination-Semicolon-Spaces">Statement Termination Semicolon Spaces</a></li>
 <li><a href="#For-Loop-Semicolon-Spaces">For Loop Semicolon Spaces</a></li>
 <li><a href="#Block-Comment-Indentation">Block Comment Indentation</a></li>
 <li><a href="#Outdenting-Long-Quotes">Outdenting Long Quotes</a></li>
 <li><a href="#Many-Other-Parameters">Many Other Parameters</a></li>
 <li><a href="#Example-.perltidyrc-files">Example .perltidyrc files</a></li>
 <li><a href="#Additional-Information">Additional Information</a></li>
 </ul>
 </li>
</ul>

<h1 id="Perltidy-Style-Key">Perltidy Style Key</h1>

When perltidy was first developed, the main parameter choices were the number of indentation spaces and if the user liked cuddled else&#39;s. As the number of users has grown so has the number of parameters. Now there are so many that it can be difficult for a new user to find a good initial set. This document is one attempt to help with this problem, and some other suggestions are given at the end.

Use this document to methodically find a starting set of perltidy parameters to approximate your style. We will be working on just one aspect of formatting at a time. Just read each question and select the best answer. Enter your parameters in a file named .perltidyrc (examples are listed at the end). Then move it to one of the places where perltidy will find it. You can run perltidy with the parameter -dpro to see where these places are for your system.

<h2 id="Before-You-Start">Before You Start</h2>

Before you begin, experiment using just <code>perltidy filename.pl</code> on some of your files. From the results (which you will find in files with a .tdy extension), you will get a sense of what formatting changes, if any, you&#39;d like to make. If the default formatting is acceptable, you do not need a .perltidyrc file.

The default is based on the recommendations in the <a href="https://perldoc.perl.org/perlstyle">Perl style guide</a>. It is worth noting that, although many variations are possible with the available parameters, this style has some significant advantages when small sections of code are sent to perltidy from within an editor. The reason is that perltidy can usually format a small container spanning multiple lines of code provided that the parens, braces and brackets are balanced. For the default style, the number of lines required to make a balanced selection of code is generally less than for other styles. For example, if a cuddled style is used, then an entire <code>if-elsif-</code> chain must be selected for formatting rather than an individual <code>elsif</code> block. This can be tedious and time consuming.

<h2 id="Use-as-Filter">Use as Filter?</h2>

Do you almost always want to run perltidy as a standard filter on just one input file? If yes, use -st and -se.

<h2 id="Line-Length-Setting">Line Length Setting</h2>

Perltidy will set line breaks to prevent lines from exceeding the maximum line length.

Do you want the maximum line length to be 80 columns? If no, use -l=n, where n is the number of columns you prefer.

When setting the maximum line length, something to consider is that perltidy will use this to decide when a list of items should be broken into multiple lines. So if it is set excessively large, lists may be so wide that they are hard to read.

<h2 id="Indentation-in-Code-Blocks">Indentation in Code Blocks</h2>

In the block below, the variable <code>$anchor</code> is one indentation level deep and is indented by 4 spaces as shown here:

<pre><code> if ( $flag eq &quot;a&quot; ) {
 $anchor = $header;
 }</code></pre>

If you want to change this to be a different number n of spaces per indentation level, use -i=n.

<h2 id="Continuation-Indentation">Continuation Indentation</h2>

Look at the statement beginning with <code>$anchor</code>:

<pre><code> if ( $flag eq &quot;a&quot; ) {
 $anchor =
 substr( $header, 0, 6 )
 . substr( $char_list, $place_1, 1 )
 . substr( $char_list, $place_2, 1 );
 }</code></pre>

The statement is too long for the line length (80 characters by default), so it has been broken into 4 lines. The second and later lines have some extra &quot;continuation indentation&quot; to help make the start of the statement easy to find. The default number of extra spaces is 2. If you prefer a number n different from 2, you may specify this with -ci=n. It is probably best if it does not exceed the value of the primary indentation.

The default, and recommendation, is to represent leading whitespace with actual space characters. However, if you prefer to entab leading whitespace of lines of code with one tab character for each n spaces, use -et=n. The value of n should be set to be the same as used by your display software. If there is a disagreement, then vertical alignment will not be displayed correctly.

Please note that this number n has nothing to do with the number of spaces for one level of indentation, which is specified separately with -i=n.

<h2 id="Opening-Block-Brace-Right-or-Left">Opening Block Brace Right or Left?</h2>

Opening and closing curly braces, parentheses, and square brackets are divided into two separate categories and controlled separately in most cases. The two categories are (1) code block curly braces, which contain perl code, and (2) everything else. Basically, a code block brace is one which could contain semicolon-terminated lines of perl code. We will first work on the scheme for code block curly braces.

Decide which of the following opening brace styles you prefer for most blocks of code (with the possible exception of a sub block brace which will be covered later):

If you like opening braces on the right, like this, go to <a href="#Opening-Braces-Right">&quot;Opening Braces Right&quot;</a>.

<pre><code> if ( $flag eq &quot;h&quot; ) {
 $headers = 0;
 }</code></pre>

If you like opening braces on the left, like this, go to <a href="#Opening-Braces-Left">&quot;Opening Braces Left&quot;</a>.

<pre><code> if ( $flag eq &quot;h&quot; )
 {
 $headers = 0;
 }</code></pre>

<h2 id="Opening-Braces-Right">Opening Braces Right</h2>

In a multi-line if test expression, the default is to place the opening brace on the left, like this:

<pre><code> if ( $bigwasteofspace1 &amp;&amp; $bigwasteofspace2
 || $bigwasteofspace3 &amp;&amp; $bigwasteofspace4 )
 {
 big_waste_of_time();
 }</code></pre>

This helps to visually separate the block contents from the test expression.

An alternative is to keep the brace on the right even for multiple-line test expressions, like this:

<pre><code> if ( $bigwasteofspace1 &amp;&amp; $bigwasteofspace2
 || $bigwasteofspace3 &amp;&amp; $bigwasteofspace4 ) {
 big_waste_of_time();
 }</code></pre>

If you prefer this alternative, use -bar.

<h2 id="Cuddled-Else">Cuddled Else?</h2>

Do you prefer this Cuddled Else style

<pre><code> if ( $flag eq &quot;h&quot; ) {
 $headers = 0;
 } elsif ( $flag eq &quot;f&quot; ) {
 $sectiontype = 3;
 } else {
 print &quot;invalid option: &quot; . substr( $arg, $i, 1 ) . &quot;\n&quot;;
 dohelp();
 }</code></pre>

instead of this default style?

<pre><code> if ( $flag eq &quot;h&quot; ) {
 $headers = 0;
 }
 elsif ( $flag eq &quot;f&quot; ) {
 $sectiontype = 3;
 }
 else {
 print &quot;invalid option: &quot; . substr( $arg, $i, 1 ) . &quot;\n&quot;;
 dohelp();
 }</code></pre>

If yes, you should use -ce. Now skip ahead to <a href="#Opening-Sub-Braces">&quot;Opening Sub Braces&quot;</a>.

<h2 id="Opening-Braces-Left">Opening Braces Left</h2>

Use -bl if you prefer this style:

<pre><code> if ( $flag eq &quot;h&quot; )
 {
 $headers = 0;
 }</code></pre>

Use -bli if you prefer this indented-brace style:

<pre><code> if ( $flag eq &quot;h&quot; )
 {
 $headers = 0;
 }</code></pre>

The number of spaces of extra indentation will be the value specified for continuation indentation with the -ci=n parameter (2 by default).

<h2 id="Opening-Sub-Braces">Opening Sub Braces</h2>

By default, the opening brace of a sub block will be treated the same as other code blocks. If this is okay, skip ahead to <a href="#Block-Brace-Vertical-Tightness">&quot;Block Brace Vertical Tightness&quot;</a>.

If you prefer an opening sub brace to be on a new line, like this:

<pre><code> sub message
 {
 # -sbl
 }</code></pre>

use -sbl. If you prefer the sub brace on the right like this

<pre><code> sub message {

# -nsbl
 }</code></pre>

use -nsbl.

If you wish to give this opening sub brace some indentation you can do that with the parameters -bli and -blil which are described in the manual.

<h2 id="Block-Brace-Vertical-Tightness">Block Brace Vertical Tightness</h2>

If you chose to put opening block braces of all types to the right, skip ahead to <a href="#Closing-Block-Brace-Indentation">&quot;Closing Block Brace Indentation&quot;</a>.

If you chose to put braces of any type on the left, the default is to leave the opening brace on a line by itself, like this (shown for -bli, but also true for -bl):

<pre><code> if ( $flag eq &quot;h&quot; )
 {
 $headers = 0;
 }</code></pre>

But you may also use this more compressed style if you wish:

<pre><code> if ( $flag eq &quot;h&quot; )
 { $headers = 0;
 }</code></pre>

If you do not prefer this more compressed form, go to <a href="#Opening-Sub-Braces">&quot;Opening Sub Braces&quot;</a>.

Otherwise use parameter -bbvt=n, where n=1 or n=2. To decide, look at this snippet:

<pre><code> # -bli -bbvt=1
 sub _directives
 {
 {
 &#39;ENDIF&#39; =&gt; \&amp;_endif,
 &#39;IF&#39; =&gt; \&amp;_if,
 };
 }

# -bli -bbvt=2
 sub _directives
 { {
 &#39;ENDIF&#39; =&gt; \&amp;_endif,
 &#39;IF&#39; =&gt; \&amp;_if,
 };
 }</code></pre>

The difference is that -bbvt=1 breaks after an opening brace if the next line is unbalanced, whereas -bbvt=2 never breaks.

If you were expecting the &#39;ENDIF&#39; word to move up vertically here, note that the second opening brace in the above example is not a code block brace (it is a hash brace), so the -bbvt does not apply to it (another parameter will).

<h2 id="Closing-Block-Brace-Indentation">Closing Block Brace Indentation</h2>

The default is to place closing braces at the same indentation as the opening keyword or brace of that code block, as shown here:

<pre><code> if ($task) {
 yyy();
 } # default</code></pre>

If you chose the -bli style, however, the default closing braces will be indented one continuation indentation like the opening brace:

If you prefer to give closing block braces one full level of indentation, independently of how the opening brace is treated, for example like this:

use -icb.

This completes the definition of the placement of code block braces.

<h2 id="Indentation-Style-for-Other-Containers">Indentation Style for Other Containers</h2>

You have a choice of two basic indentation schemes for non-block containers. The default is to use a fixed number of spaces per indentation level (the same number of spaces used for code blocks, which is 4 by default). Here is an example of the default:

<pre><code> $dbh = DBI-&gt;connect(
 undef, undef, undef,
 {
 PrintError =&gt; 0,
 RaiseError =&gt; 1
 }
 );</code></pre>

In this default indentation scheme, a simple formula is used to find the indentation of every line. Notice how the first &#39;undef&#39; is indented 4 spaces (one level) to the right, and how &#39;PrintError&#39; is indented 4 more spaces (one more level) to the right.

The alternate is to let the location of the opening paren (or square bracket, or curly brace) define the indentation, like this:

<pre><code> $dbh = DBI-&gt;connect(
 undef, undef, undef,
 {
 PrintError =&gt; 0,
 RaiseError =&gt; 1
 }
 );</code></pre>

The first scheme is completely robust. The second scheme often looks a little nicer, but be aware that deeply nested structures it can be spoiled if the line length limit is exceeded. Also, if there are comments or blank lines within a complex structure perltidy will temporarily fall back on the default indentation scheme. You may want to try both on large sections of code to see which works best.

Also note that a disadvantage of this second scheme is that small changes in code, such as a change in the length of a sub name, can cause changes in many lines of code. For example, if we decide to change the name <code>connect</code> to <code>connect_to_destination</code>, then all of the call args would have to move right by 15 spaces. This can produce a lot of lines of differences when changes are committed.

If you prefer the first (default) scheme, no parameter is needed.

If you prefer the latter scheme, use --line-up-parentheses, or -lp. There is an alternative version of this option named --extended-line-up-parentheses, or -xlp which can also be used. For simplicity, the name -lp will refer to either of these options in the following text.

<h2 id="Welding">Welding</h2>

The following snippet is displayed with the default formatting:

<pre><code> $opt_c = Text::CSV_XS-&gt;new(
 {
 binary =&gt; 1,
 sep_char =&gt; $opt_c,
 always_quote =&gt; 1,
 }
 );</code></pre>

For this type of structure, where an inner container is nested within an outer container, we can get a more compact display with the parameter --weld-nested-containers, or -wn:

<pre><code> # perltidy -wn
 $opt_c = Text::CSV_XS-&gt;new( {
 binary =&gt; 1,
 sep_char =&gt; $opt_c,
 always_quote =&gt; 1,
 } );</code></pre>

The name of the parameter comes from the idea that the two opening and two closing tokens have been &#39;welded&#39; together to act as a single unit. The indentation spaces of the contents has also been reduced by one level.

This is a nice transformation because it is symmetric at the opening and closing, and leaves a sort of &#39;sandwich&#39; structure 0which is still quite readable.

Some parameters available for asymmetric compressions, at just the opening or closing of complex structures, are described in the next sections.

<h2 id="Opening-Vertical-Tightness">Opening Vertical Tightness</h2>

The information in this section applies mainly to the -lp style but it also applies in some cases to the default style. It will be illustrated for the -lp indentation style.

The default -lp indentation style ends a line at the opening tokens, like this:

Here is a tighter alternative, which does not end a line with the opening tokens:

<pre><code> $dbh = DBI-&gt;connect( undef, undef, undef,
 { PrintError =&gt; 0,
 RaiseError =&gt; 1
 }
 );</code></pre>

The difference is that the lines have been compressed vertically without any changes to the indentation. This can almost always be done with the -lp indentation style, but only in limited cases for the default indentation style.

If you prefer the default, skip ahead to <a href="#Closing-Token-Placement">&quot;Closing Token Placement&quot;</a>.

Otherwise, use -vt=n, where n should be either 1 or 2. To help decide, observe the first three opening parens in the following snippet and choose the value of n you prefer. Here it is with -lp -vt=1:

<pre><code> if (
 !defined(
 start_slip( $DEVICE, $PHONE, $ACCOUNT, $PASSWORD,
 $LOCAL, $REMOTE, $NETMASK, $MTU
 )
 )
 &amp;&amp; $continuation_flag
 )
 {
 do_something_about_it();
 }</code></pre>

And here it is again formatted with -lp -vt=2:

<pre><code> if ( !defined( start_slip( $DEVICE, $PHONE, $ACCOUNT, $PASSWORD,
 $LOCAL, $REMOTE, $NETMASK, $MTU
 )
 )
 &amp;&amp; $continuation_flag
 )
 {
 do_something_about_it();
 }</code></pre>

The -vt=1 style tries to display the structure by preventing more than one step in indentation per line. In this example, the first two opening parens were not followed by balanced lines, so -vt=1 broke after them.

The -vt=2 style does not limit itself to a single indentation step per line.

Note that in the above example the function &#39;do_something_about_it&#39; started on a new line. This is because it follows an opening code block brace and is governed by the flag previously set in <a href="#Block-Brace-Vertical-Tightness">&quot;Block Brace Vertical Tightness&quot;</a>.

<h2 id="Closing-Token-Placement">Closing Token Placement</h2>

You have several options for dealing with the terminal closing tokens of non-blocks. In the following examples, a closing parenthesis is shown, but these parameters apply to closing square brackets and non-block curly braces as well.

The default behavior for parenthesized relatively large lists is to place the closing paren on a separate new line. The flag -cti=n controls the amount of indentation of such a closing paren.

The default, -cti=0, for a line beginning with a closing paren, is to use the indentation defined by the next (lower) indentation level. This works well for the default indentation scheme:

<pre><code> # perltidy
 @month_of_year = (
 &#39;Jan&#39;, &#39;Feb&#39;, &#39;Mar&#39;, &#39;Apr&#39;, &#39;May&#39;, &#39;Jun&#39;,
 &#39;Jul&#39;, &#39;Aug&#39;, &#39;Sep&#39;, &#39;Oct&#39;, &#39;Nov&#39;, &#39;Dec&#39;
 );</code></pre>

but it may not look very good with the -lp indentation scheme:

<pre><code> # perltidy -lp
 @month_of_year = (
 &#39;Jan&#39;, &#39;Feb&#39;, &#39;Mar&#39;, &#39;Apr&#39;, &#39;May&#39;, &#39;Jun&#39;,
 &#39;Jul&#39;, &#39;Aug&#39;, &#39;Sep&#39;, &#39;Oct&#39;, &#39;Nov&#39;, &#39;Dec&#39;
 );</code></pre>

An alternative which works well with -lp indentation is -cti=1, which aligns the closing paren vertically with its opening paren, if possible:

<pre><code> # perltidy -lp -cti=1
 @month_of_year = (
 &#39;Jan&#39;, &#39;Feb&#39;, &#39;Mar&#39;, &#39;Apr&#39;, &#39;May&#39;, &#39;Jun&#39;,
 &#39;Jul&#39;, &#39;Aug&#39;, &#39;Sep&#39;, &#39;Oct&#39;, &#39;Nov&#39;, &#39;Dec&#39;
 );</code></pre>

Another alternative, -cti=3, indents a line with leading closing paren one full indentation level:

<pre><code> # perltidy -lp -cti=3
 @month_of_year = (
 &#39;Jan&#39;, &#39;Feb&#39;, &#39;Mar&#39;, &#39;Apr&#39;, &#39;May&#39;, &#39;Jun&#39;,
 &#39;Jul&#39;, &#39;Aug&#39;, &#39;Sep&#39;, &#39;Oct&#39;, &#39;Nov&#39;, &#39;Dec&#39;
 );</code></pre>

If you prefer the closing paren on a separate line like this, note the value of -cti=n that you prefer and skip ahead to <a href="#Define-Horizontal-Tightness">&quot;Define Horizontal Tightness&quot;</a>.

Finally, the question of paren indentation can be avoided by placing it at the end of the previous line, like this:

<pre><code> @month_of_year = (
 &#39;Jan&#39;, &#39;Feb&#39;, &#39;Mar&#39;, &#39;Apr&#39;, &#39;May&#39;, &#39;Jun&#39;,
 &#39;Jul&#39;, &#39;Aug&#39;, &#39;Sep&#39;, &#39;Oct&#39;, &#39;Nov&#39;, &#39;Dec&#39; );</code></pre>

Perltidy will automatically do this to save space for very short lists but not for longer lists.

Use -vtc=n if you prefer to usually do this, where n is either 1 or 2. To determine n, we have to look at something more complex. Observe the behavior of the closing tokens in the following snippet:

Here is -lp -vtc=1:

<pre><code> $srec-&gt;{&#39;ACTION&#39;} = [
 $self-&gt;read_value(
 $lookup-&gt;{&#39;VFMT&#39;},
 $loc, $lookup, $fh
 ),
 $self-&gt;read_value(
 $lookup-&gt;{&#39;VFMT2&#39;},
 $loc, $lookup, $fh
 ) ];</code></pre>

Here is -lp -vtc=2:

<pre><code> $srec-&gt;{&#39;ACTION&#39;} = [
 $self-&gt;read_value(
 $lookup-&gt;{&#39;VFMT&#39;},
 $loc, $lookup, $fh ),
 $self-&gt;read_value(
 $lookup-&gt;{&#39;VFMT2&#39;},
 $loc, $lookup, $fh ) ];</code></pre>

Choose the one that you prefer. The difference is that -vtc=1 leaves closing tokens at the start of a line within a list, which can assist in keeping hierarchical lists readable. The -vtc=2 style always tries to move closing tokens to the end of a line.

If you choose -vtc=1, you may also want to specify a value of -cti=n (previous section) to handle cases where a line begins with a closing paren.

<h2 id="Stack-Opening-Tokens">Stack Opening Tokens</h2>

In the following snippet the opening hash brace has been placed alone on a new line.

<pre><code> $opt_c = Text::CSV_XS-&gt;new(
 {
 binary =&gt; 1,
 sep_char =&gt; $opt_c,
 always_quote =&gt; 1,
 }
 );</code></pre>

If you prefer to avoid isolated opening tokens by &quot;stacking&quot; them together with other opening tokens like this:

<pre><code> $opt_c = Text::CSV_XS-&gt;new( {
 binary =&gt; 1,
 sep_char =&gt; $opt_c,
 always_quote =&gt; 1,
 }
 );</code></pre>

use -sot.

<h2 id="Stack-Closing-Tokens">Stack Closing Tokens</h2>

Likewise, in the same snippet the default formatting leaves the closing paren on a line by itself here:

<pre><code> $opt_c = Text::CSV_XS-&gt;new(
 {
 binary =&gt; 1,
 sep_char =&gt; $opt_c,
 always_quote =&gt; 1,
 }
 );</code></pre>

If you would like to avoid leaving isolated closing tokens by stacking them with other closing tokens, like this:

<pre><code> $opt_c = Text::CSV_XS-&gt;new(
 {
 binary =&gt; 1,
 sep_char =&gt; $opt_c,
 always_quote =&gt; 1,
 } );</code></pre>

use -sct.

The -sct flag is somewhat similar to the -vtc flags, and in some cases it can give a similar result. The difference is that the -vtc flags try to avoid lines with leading opening tokens by &quot;hiding&quot; them at the end of a previous line, whereas the -sct flag merely tries to reduce the number of lines with isolated closing tokens by stacking multiple closing tokens together, but it does not try to hide them.

The manual shows how all of these vertical tightness controls may be applied independently to each type of non-block opening and opening token.

Also, note that --weld-nested-containers, or -wn, mentioned previously, operates like the combination of -sot and -sct and also reduces the indentation level of the contents.

<h2 id="Define-Horizontal-Tightness">Define Horizontal Tightness</h2>

Horizontal tightness parameters define how much space is included within a set of container tokens.

For parentheses, decide which of the following values of -pt=n you prefer:

<pre><code> if ( ( my $len_tab = length( $tabstr ) ) &gt; 0 ) { # -pt=0
 if ( ( my $len_tab = length($tabstr) ) &gt; 0 ) { # -pt=1 (default)
 if ((my $len_tab = length($tabstr)) &gt; 0) { # -pt=2</code></pre>

For n=0, space is always used, and for n=2, space is never used. For the default n=1, space is used if the parentheses contain more than one token.

For square brackets, decide which of the following values of -sbt=n you prefer:

<pre><code> $width = $col[ $j + $k ] - $col[ $j ]; # -sbt=0
 $width = $col[ $j + $k ] - $col[$j]; # -sbt=1 (default)
 $width = $col[$j + $k] - $col[$j]; # -sbt=2</code></pre>

For curly braces, decide which of the following values of -bt=n you prefer:

<pre><code> $obj-&gt;{ $parsed_sql-&gt;{ &#39;table&#39; }[0] }; # -bt=0
 $obj-&gt;{ $parsed_sql-&gt;{&#39;table&#39;}[0] }; # -bt=1 (default)
 $obj-&gt;{$parsed_sql-&gt;{&#39;table&#39;}[0]}; # -bt=2</code></pre>

For code block curly braces, decide which of the following values of -bbt=n you prefer:

<pre><code> %bf = map { $_ =&gt; -M $_ } grep { /\.deb$/ } dirents &#39;.&#39;; # -bbt=0 (default)
 %bf = map { $_ =&gt; -M $_ } grep {/\.deb$/} dirents &#39;.&#39;; # -bbt=1
 %bf = map {$_ =&gt; -M $_} grep {/\.deb$/} dirents &#39;.&#39;; # -bbt=2</code></pre>

<h2 id="Spaces-between-function-names-and-opening-parens">Spaces between function names and opening parens</h2>

The default is not to place a space after a function call:

<pre><code> myfunc( $a, $b, $c ); # default</code></pre>

If you prefer a space:

<pre><code> myfunc ( $a, $b, $c ); # -sfp</code></pre>

use -sfp.

<h2 id="Spaces-between-Perl-keywords-and-parens">Spaces between Perl keywords and parens</h2>

The default is to place a space between only these keywords and an opening paren:

<pre><code> my local our and or eq ne if else elsif until unless
 while for foreach return switch case given when</code></pre>

but no others. For example, the default is:

If you want a space between all Perl keywords and an opening paren,

use -skp. For detailed control of individual keywords, see the manual.

<h2 id="Statement-Termination-Semicolon-Spaces">Statement Termination Semicolon Spaces</h2>

The default is not to put a space before a statement termination semicolon, like this:

If you prefer a space, like this:

enter -sts.

<h2 id="For-Loop-Semicolon-Spaces">For Loop Semicolon Spaces</h2>

The default is to place a space before a semicolon in a for statement, like this:

<pre><code> for ( @a = @$ap, $u = shift @a ; @a ; $u = $v ) { # -sfs (default)</code></pre>

If you prefer no such space, like this:

<pre><code> for ( @a = @$ap, $u = shift @a; @a; $u = $v ) { # -nsfs</code></pre>

enter -nsfs.

<h2 id="Block-Comment-Indentation">Block Comment Indentation</h2>

Block comments are comments which occupy a full line, as opposed to side comments. The default is to indent block comments with the same indentation as the code block that contains them (even though this will allow long comments to exceed the maximum line length).

If you would like block comments indented except when this would cause the maximum line length to be exceeded, use -olc. This will cause a group of consecutive block comments to be outdented by the amount needed to prevent any one from exceeding the maximum line length.

If you never want block comments indented, use -nibc.

If block comments may only be indented if they have some space characters before the leading <code>#</code> character in the input file, use -isbc.

The manual shows many other options for controlling comments.

<h2 id="Outdenting-Long-Quotes">Outdenting Long Quotes</h2>

Long quoted strings may exceed the specified line length limit. The default, when this happens, is to outdent them to the first column. Here is an example of an outdented long quote:

<pre><code> if ($source_stream) {
 if ( @ARGV &gt; 0 ) {
 die
 &quot;You may not specify any filenames when a source array is given\n&quot;;
 }
 }</code></pre>

The effect is not too different from using a here document to represent the quote. If you prefer to leave the quote indented, like this:

<pre><code> if ($source_stream) {
 if ( @ARGV &gt; 0 ) {
 die
 &quot;You may not specify any filenames when a source array is given\n&quot;;
 }
 }</code></pre>

use -nolq.

<h2 id="Many-Other-Parameters">Many Other Parameters</h2>

This document has only covered the most popular parameters. The manual contains many more and should be consulted if you did not find what you need here.

<h2 id="Example-.perltidyrc-files">Example .perltidyrc files</h2>

Now gather together all of the parameters you prefer and enter them in a file called .perltidyrc.

Here are some example .perltidyrc files and the corresponding style.

Here is a little test snippet, shown the way it would appear with the default style.

<pre><code> for (@methods) {
 push (
 @results,
 {
 name =&gt; $_-&gt;name,
 help =&gt; $_-&gt;help,
 }
 );
 }</code></pre>

You do not need a .perltidyrc file for this style.

Here is the same snippet

<pre><code> for (@methods)
 {
 push(@results,
 { name =&gt; $_-&gt;name,
 help =&gt; $_-&gt;help,
 }
 );
 }</code></pre>

for a .perltidyrc file containing these parameters:

You do not need to place just one parameter per line, but this may be convenient for long lists. You may then hide any parameter by placing a <code>#</code> symbol before it.

And here is the snippet

<pre><code> for (@methods) {
 push ( @results,
 { name =&gt; $_-&gt;name,
 help =&gt; $_-&gt;help,
 } );
 }</code></pre>

for a .perltidyrc file containing these parameters:

<h2 id="Additional-Information">Additional Information</h2>

For further information see the perltidy documentation at <a href="http://perltidy.sourceforge.net">Sourceforge</a> or at <a href="https://metacpan.org/pod/distribution/Perl-Tidy/bin/perltidy">metacpan</a>. or at <a href="https://perltidy.github.io/perltidy/">GitHub</a>

The source code is maintained at <a href="https://github.com/perltidy/perltidy">GitHub</a>.

</body>

</html>

Cancel