Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: CPAN's perltidy to the rescue!

by ruzam (Curate)
on Jul 13, 2012 at 18:36 UTC ( #981698=note: print w/ replies, xml ) Need Help??


in reply to CPAN's perltidy to the rescue!

I honestly believe that mandated style guides for coding are a waste of time. It's so easy to just run all code through perltidy (or the like) and automatically format every line up to a common standard. No reason to chastise coders for their evil non standard ways, or hoist meetings and style reviews on an otherwise productive day. Just let programmers do their thing and then perltidy it before sharing.

If the world spent more time using pertidy and less time endlessly arguing coding standards, we'd all get more work done.


Comment on Re: CPAN's perltidy to the rescue!
Re^2: CPAN's perltidy to the rescue!
by Anonymous Monk on Jul 13, 2012 at 18:38 UTC
    WHOOOSH
Re^2: CPAN's perltidy to the rescue!
by learnedbyerror (Beadle) on Jul 18, 2012 at 15:13 UTC

    reuzam, isn't it amazing how much energy a simple thank you can create - LOL!

    I also am a strong proponent of using perltidy. I have been cranking perl code since version 2.0 came out - I guess that makes me a dinosaur. Over the years, I have used a whole bunch of different development environments, tools and appraoches to perl and other languages. Without exception, I have returned to the following kit

    • vim/gvim
    • perl-support for vim
    • perltidy
    • perlcritic

    I am not saying categorically that this is the best approach in the world, but it is best for me. As a younger code wrangler, I used to get very carried away with how code should be structured and formatted. I thought my ideas were the best, and often they were in the case in which we were working. I felt like my creativity was in how the code was structured and that code should be presented in its absolute best light. As I age, I come to realize that the best way to present good code is in the end result. All the rest is just hubris.

    Results to me mean:

    • The delivered solution meets/exceeds users/consumers needs
    • The code is structured in a way that easily understood and adequately commented

    While perltidy can't directly help with the former, it can be a great tool with the latter. perl-support in vim does a great job with syntax highlighting and helping me insure that all opening {[( are closed. While developing, I inherently tab here and there and do a bit of formatting; however, I don't sweat the formatting. Before each and every save, I \rs (compile the code to make sure my syntax is clean) and \ry (run perltidy from within vim) and then save.

    I love that I don't spend practically "no" time worrying about formatting code. While I don't necessarily love every little thing about perltidy ( like the earlier comment on qw formatting ), overall it is great. I can readily see the structure and the flow of code -- it makes my visual cortex happy!

    And one last thought, if you are arguiing about how code format interferes with your creativity, stop, get a drink, maybe an adult one, and reassess what creativity is and your ability to be creative;)

    lbe

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://981698]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (6)
As of 2014-09-24 02:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (244 votes), past polls