4 ms·

What are you using for Perl and JavaScript?

mitchty 12y ago
Some help on spellcheck like stuff in perl would be perl-critic and perl-tidy. Beware using this on old code though. http://search.cpan.org/~thaljef/Perl-Critic-1.123/lib/Perl/Critic.pm http://search.cpan.org/~thaljef/Perl-Critic-1.123/lib/Perl/C... http://search.cpan.org/~shancock/Perl-Tidy-20140711/lib/Perl/Tidy.pod http://search.cpan.org/~shancock/Perl-Tidy-20140711/lib/Perl... I know nothing on javascript.
pronoiac 12y ago
For JavaScript, I like jshint: http://jshint.com http://jshint.com , as I heard jslint was too opinionated.
SwellJoe 12y ago
I'm still working on it, but Perl::Critic is good (I've been using it in vim for a while, which checks every time you save), strict and warnings is good (which would be enabled on any new Perl program, but I'm working with a 15 year old codebase, so enabling these automatically creates a bunch of new failing "tests" that need fixing). There's a few different ways to use Perl::Critic in tests, the most promising seems to be Test::Perl::Critic::Progressive, which allows gradual introduction of Critic-friendly code without turning your whole smoker page red. (Which for me, is a problem...we'd have hundreds of failing tests, which would be overwhelming and make it hard to spot tests that will affect users.) Devel::NYTProf is great for spotting performance regressions. And, since we're pushing out HTML as the result of our application scripts running, I've been working on integrating HTML::Lint (I had to patch it to allow HTML::Pluggable::HTML5 to work, but I've sent a pull request to Andy, so the next version will likely support HTML5) into our test suite. This will tell us if any script breaks in such a way that it produces invalid HTML. For JavaScript, jslint and jshint exist. I haven't started integrating or experimenting with either, yet. Our JavaScript is pretty minimal at the moment (a few thousand lines vs 500k+ lines of Perl), so it's not a priority compared to the Perl, and the Perl stuff is still in progress. JavaScript also has strict, which can catch some common problems, like the global scope "this".
diff_sky 12y ago
For javascript, eslint (http://eslint.org/ http://eslint.org/) is now what I use. It's more configurable than what has come before it and has good, clear documentation.

Some help on spellcheck like stuff in perl would be perl-critic and perl-tidy. Beware using this on old code though. http://search.cpan.org/~thaljef/Perl-Critic-1.123/lib/Perl/Critic.pm http://search.cpan.org/~thaljef/Perl-Critic-1.123/lib/Perl/C... http://search.cpan.org/~shancock/Perl-Tidy-20140711/lib/Perl/Tidy.pod http://search.cpan.org/~shancock/Perl-Tidy-20140711/lib/Perl... I know nothing on javascript.

pronoiac 12y ago

For JavaScript, I like jshint: http://jshint.com http://jshint.com , as I heard jslint was too opinionated.

SwellJoe 12y ago

I'm still working on it, but Perl::Critic is good (I've been using it in vim for a while, which checks every time you save), strict and warnings is good (which would be enabled on any new Perl program, but I'm working with a 15 year old codebase, so enabling these automatically creates a bunch of new failing "tests" that need fixing). There's a few different ways to use Perl::Critic in tests, the most promising seems to be Test::Perl::Critic::Progressive, which allows gradual introduction of Critic-friendly code without turning your whole smoker page red. (Which for me, is a problem...we'd have hundreds of failing tests, which would be overwhelming and make it hard to spot tests that will affect users.) Devel::NYTProf is great for spotting performance regressions. And, since we're pushing out HTML as the result of our application scripts running, I've been working on integrating HTML::Lint (I had to patch it to allow HTML::Pluggable::HTML5 to work, but I've sent a pull request to Andy, so the next version will likely support HTML5) into our test suite. This will tell us if any script breaks in such a way that it produces invalid HTML. For JavaScript, jslint and jshint exist. I haven't started integrating or experimenting with either, yet. Our JavaScript is pretty minimal at the moment (a few thousand lines vs 500k+ lines of Perl), so it's not a priority compared to the Perl, and the Perl stuff is still in progress. JavaScript also has strict, which can catch some common problems, like the global scope "this".

diff_sky 12y ago

For javascript, eslint (http://eslint.org/ http://eslint.org/) is now what I use. It's more configurable than what has come before it and has good, clear documentation.