I would love to do more #Perl and #RakuLang coding. Have done some Perl over the last couple of weeks again. But what brings me back to #Ruby most of the time is the better #LSP support for my Editor. E.g. renaming variables, code-actions, etc. That's just a superior experience :-( #PerlNavigator and #perltidy are OK, but not perfect.
Will soon publish a new blog post about "Perl new features" and how I used them.
@deflarerOfClouds #GitHub has hosted #PerlTidy development for a long time. Please continue to file bug reports there: https://GitHub.com/perltidy/perltidy/issues
You might even consider making a reasonable case to move the project’s remaining assets off #SourceForge. Impotently whinging about it here doesn’t change anything.
@eliasp @ColinTheMathmo BTW #Perl has two well-known tools to encourage and enforce #programming style and best practices, respectively:
• #PerlTidy: https://perltidy.github.io/perltidy
• #PerlCritic: http://perlcritic.com
Your project or team can use their reasonable defaults or further configure them to reflect and maintain the consistent application of your preferences. They also integrate with editors/IDEs, source control management, and author #testing.
@ovid Either of the perltidy options:
-nwrs='A'
or
--no-want-right-space='A'
ought to do it. “A” is the token #perltidy uses for #Perl attribute separators according to the output of `perltidy --dump-token-types`.
Feel free to put either in your .perltidyrc file. I prefer to use long option names as they’re more self-documenting or at least easier to search for.
@jens @RL_Dane @stoerdebegga One reason I choose #Perl is its expressivity without being too “large” of a language. (This last is why I still haven’t wrapped my head around #RakuLang—they threw so much into its core.)
I use #PerlCritic and #PerlTidy to set fairly strict defaults, but both have escape hatches for code islands that need to bend the rules for whatever reason (e.g. better modeling or critical-path performance, or sometimes fencing off legacy code to be brought up to spec later).
@jens @RL_Dane @stoerdebegga #PerlTidy will help you with standardizing on line length and other formatting: https://metacpan.org/dist/Perl-Tidy/view/bin/perltidy
And this core #PerlCritic policy will enforce it: https://metacpan.org/pod/Perl::Critic::Policy::CodeLayout::RequireTidyCode
@jens @RL_Dane @stoerdebegga (I also think every #CPAN distribution should include #perltidy and #perlcritic configs and author tests to encourage consistently-written contributions.)
@chrisjrob @snonux @Perl #PerlTidy and #PerlCritic also help with readable, maintainable, and consistent #Perl code. I like to joke that I don’t have a style, I have a perlcritic policy.
Let me remove your excuses for not using #PerlCritic or #PerlTidy:
1) Use `## no critic` to fence in legacy or experiments in #Perl coding standards from perlcritic https://metacpan.org/dist/Perl-Critic/view/bin/perlcritic#BENDING-THE-RULES
2) Use `#<<<` and `#>>>` to fence in legacy or experiments in code formatting from perltidy https://metacpan.org/dist/Perl-Tidy/view/bin/perltidy#Skipping-Selected-Sections-of-Code
3) Use Test::Perl::Critic::Progressive to gradually enforce coding standards https://metacpan.org/pod/Test::Perl::Critic::Progressive
