I often do "all of the above" (except "leave long lines 'as is' for readability", since I find such longs lines anything but easy to read). As an example, here is an approach that you probably haven't considered, just going to an extreme that I usually wouldn't go to:

    my $key= join '\\',
        'Micr­osoft',
        'Win­dows NT',
        'Curren­tVersion',
        '­Terminal Server',
        'In­stall',
        'Sof­tware',
        'Mic­rosoft',
        'Wi­ndows',
        'Cur­rentVersio­n',
        'RunOnce­Ex';
[download]

yes, your example could be extreme, but it is IMO more readable then this code from Win32::TieRegistry


    $Registry->Delimiter("/");
    $tip18= $Registry->{"HKEY_LOCAL_MACHINE/Software/Microsoft/"
               . 'Windows/CurrentVersion/Explorer/Tips//18'};
[download]


When I wrote "break the line" I mean this type of splitting. Break my eyes if I read 200 lines of such code :-)

UPDATE: IMO your code is more readable because I read it in _one_ direction, from up to bottom, and not in Z-style.

Your question begs another question - what is your audience? If you contributing to a specific project, you may find that it has its own guidelines or rules, so it would therefore be a good idea to enquire. If, on the other hand, you are writing for yourself, write it in such a way that you can read (and understand) it when you come back to it later.

Personally, I cannot understand why so many insist on 80 column lines. How many programmers nowadays still use 80x24 terminals? As I write stuff primarily that nobody else will see, I tend to use 132 column lines. This is perfectly readable in gvim on my 21 inch wide-screen monitor (and I use big fonts) and never wraps when the editor is maximised - which it always is. (And it will still print correctly on an old wide-carriage dot matrix printer ;-)

I also use a 2 column tab setting - this can keep lines to a more sensible length when there are many levels of indent.

To conclude, I'd say work to what your audience wants/expects and if that audience is just you, go with what you are comfortable with and what suits your monitor.

++ My current terminal is 62x180 (I use YaKuake with 100% width, 100% height). I normally limit the lines to 140 just because after that they become harder to follow (the line breaks normally organize a call to a sub that has a lot of parameters, or a lot of named params) and the extra 40 leave space for other stuff (like to-line-end comments) :-)
[]s, HTH, Massa (κς,πμ,πλ)

Thanks all!

@smiffy - good question. The code written by me and only I maintain it, but I try to leave it readable as possible for others. I cannot image somebody will print my code on the paper (so I never do).

@Perlbotics: I thought about replacing with variables too, it could be an option, but it could decrease reading speed too. Thanks for idea replace only a part of parameter.

I see many of you can accept 132/140 width, so I will do the same, and split the parameter only if it longer then 140 characters.

Thanks for quick help!

I tend not to observe the archaic 78 column restriction religously, but if you have to, I find this easy to format and quite readable:

process_key_r16a_type(
    $partition, $mountpoint, "software",
    "Microsoft\\Windows NT\\CurrentVersion\\Terminal Server\\Install"
    . "\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx"
);
[download]

Basically, I second smiffy's recommendation, but would use a 4 character TAB ;-).

While reading your example, I find the double backslashes more offending. It is IMHO less readable, esp. as the double backslash has some meaning for similar looking UNC paths.
Since you do not interpolate yet, you could use single quotes instead of the interpolating double quotes, which saves you 9 characters for the given example and the key looks more natural too. Together with string concatenation, you can break the lines at semantic borders:

process_key_r16a_type ($partition,$mountpoint,"software",
     'Microsoft\Windows NT\CurrentVersion'
    .'\Terminal Server\Install'
    .'\Software\Microsoft\Windows\CurrentVersion'
    .'\RunOnceEx'
);
[download]

process_key_r16a_type ($partition,$mountpoint,"software",
    $MS_NT_CUR  
    .'Terminal Server\Install'
    .'\Software\Microsoft\Windows\CurrentVersion'
    .'\RunOnceEx'
);
[download]

process_key_r16a_type_arefflavour ($partition,$mountpoint,"software",
    [ 'Microsoft\Windows NT\CurrentVersion',
      '\Terminal Server\Install',
      '\Software\Microsoft\Windows\CurrentVersion',
      '\RunOnceEx'
    ]
);
[download]

process_key_r16a_type (
  $partition,
  $mountpoint,
  "software",
  $cnf->param(q{torturous_path}),
) or die qq{good try, no cigar};
[download]

Or use an IDE or editor which does the word wrapping for you.

I wouldn't follow that approach because I like to be able to print out my source code (two up), spread it out on a table and get a visual handle on what's what. Yes, even if the printing gadget also wraps the code.

It's a personal preference.

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

replace long parameters with variables

That's the one I'd probably use, either by using some sort of join, or even writing a quick little module that handles those long paths .. I don't know how closely or loosely packed the destination locations are, but I expect many of the locations are close by and you could use some higher up node as a common starting point.