Is there a way to get ScalaStyle (or any other automation tool) to fix some of the warnings it finds?
For example --
Line contains a tab (shock!!)
There should be a space before the plus (+) sign
File must end with newline character
At a stretch
Public method must have explicit type
As of right now, Scalastyle does not have a way to automatically fix errors. However, it looks like Scalafix might. This is from their documentation:
A scalafix “Rule” can report lint messages and provide auto-fix patches to violations of some kind of rule/coding style/convention/breaking change.
Sounds promising! I have not had a chance to use it yet, but since this question has gotten no replies in almost three years, it seemed worth adding this as a possible solution to your problem if anyone else has a similar issue.
Related
How do I stop Netbeans (8.2) automatically "fixing" imports, on every keystroke?
For example,
deleting an import statement halfway through typing the statement [presumably because 'import x' isn't used when you are trying to type 'import x.y' ].
Removing all the imports when I type a ", /*. {, or anything that makes the rest of the program syntactically invalid [presumably because it is "not using" the imports.
It is annoying to have to 'fix-imports' on almost every keystroke, but awful when fix-imports gets it wrong (eg. a program that using java.awt.* and java.util.List, but not java.awt.List)
To be honset I don't get your question exactly. What you describe seems not to be the default behaviour of NetBeans.
From your question it seems that you're writing your imports on your own. This is not necessary. When you want to use an non imported class just use the autocompletion (Ctrl+Space) or organize imports (Ctrl+Shift+i).
I've never had any of the issues that you describe. You might have installed some additional plugins.
The particular plugin that seemed to be causing the problem is
https://github.com/rsmz/AutoSaveModified
It saves every 1 second but that causes imports to be fixed every 1 second.
So I have some formatting rule to follow, such as :
Space on each side of operator (*, =, +, %, etc)
No space at the end of a line
No more than 80 chars per line
Is there a way to highlight in red line containing formating error?
The eclipse auto-formating tool is no good because either :
It will change to many line (old code not written by me)
or it won't (only my code)
Because I must follow some "colorfull" guideline :
You must change formating error relative to operators in old code but nothing else
Your code must be correctly formated.
Any ideas?
Thanks
You can select which lines of code you want to format. The Eclipse formatting tool doesn't have to run across the entire file. To do this: select the lines you want to format, then press Ctrl-Shift-F.
You could try using the Eclipse Checkstyle Plugin.
You'll need to configure it with just the rules that you need (the default configuration is very strict, so create a new one with just the rules you care about).
This will highlight all lines with formatting issues. I don't think it's possible to ignore old code using the plugin.
Talk to whoever created that coding guideline. It does not make sense in the long run, because editing code in Eclipse will always apply all current formatting rules (which violates that guideline) or none, if you disable the formatter (which leads to you writing bad code).
If there is really no way around that guideline, then you should split your workflow into 2 phases: Reformat all existing code one time to fulfill that operator guideline. You may use any tool you like, even just a regular expression search and replace might be fine.
After that has been done, configure Eclipse to auto-format only changed lines, but always apply all formattings to each changed line. There is no good reason to not re-format the other 75 characters in an existing line of code, if you already touched 5 characters of it.
In some code coverage tools you can "hide" certain lines of code from the coverage tool, so that those lines do not count towards the coverage totals. For example, some code might be run only in circumstances that are hard or impossible to test (such as certain hardware failures). Thus, you might get 100% coverage reported even though some code was not exercised.
Setting aside for the moment whether this is wise, is this sort of thing possible with Perl's Devel::Cover?
(Devel::Cover can ignore entire files, but I am interested in ignoring just a few lines in a single file.)
A lot of uncoverable code features have been implemented but they are not documented because I wasn't sure of the interface. However, it's been a few years since anything changed in that area.
Probably the easiest way to see how to use the features is to look at tests/uncoverable in the distribution (see https://github.com/pjcj/Devel--Cover/blob/master/test/uncoverable). If you can't or don't want to change your code you can use the .uncoverable file (see https://github.com/pjcj/Devel--Cover/blob/master/tests/.uncoverable) and the cover options as mentioned by toolic.
If you do this, be sure to use the basic_html report which will mark a construct as in error if you tag it as uncoverable but it gets executed anyway.
I really should get around to tidying everything up and documenting it.
According to the TODO file on CPAN, this capability is not currently supported, but the developers see it as a valuable addition:
Enhancements:
Marking of unreachable code - commandline tool and gui.
The cover script mentions promising options: -add_uncoverable_point and -delete_uncoverable_point.
I know I risk asking a speculative question, however, inspired by this recent question I wonder which editor does the best job of syntax highlighting Perl. Being well aware of the difficulties (impossibilities) of parsing Perl I know there will not be a perfect case. Still I wonder if there is a clear leader in faithful representation.
N.B. I use gedit and it works fine, but with known issues.
Komodo Edit does a good job and also scans your modules (including those installed via CPAN) and does well at generating autocomplete data for them.
I'm a loyal vim user and rarely encounter anything odd with the native syntax.vim, except for these cases (I'll edit in more if/when I find them; others please feel free also):
!!expression is better written !!!!expression (everything after two ! is rendered as a comment quoted string; four ! brings everything back to normal)
m## or s### renders everything after the # as a comment; I usually use {} as a delimiter when avoiding / for leaning toothpick syndrome
some edge cases for $hash{key} where key is not a simple alphanumeric string - although it's safer to enclose such key names in '' anyway so as to not have to look up the exact cases for when a bareword is treated as a key name
I haven't used it, but Padre should be good since it's written in Perl. IIRC It uses PPI for parsing
jEdit...with the tweaks that I have amassed over the years. It's got the most customizable syntax highlighting I've ever seen.
I use Emacs in CPerl mode. I think it does a terrific job, although similar to Ether's answer, it's not perfect. What's more, I usually use Htmlize to publish highlighted code to the web. It's kind of annoying to use fancier forums like this one that do their own syntax highlighting, since it's not really any easier and the results aren't as good.
One I am aware of is Perl::Critic
And my googling has resulted in no results on multiple attempts so far. :-(
Does anyone have any recommendations here?
Any resources to configure Perl::Critic as per our coding standards and run it on code base would be appreciated.
In terms of setting up a profile, have you tried perlcritic --profile-proto? This will emit to stdout all of your installed policies with all their options with descriptions of both, including their default values, in perlcriticrc format. Save and edit to match what you want. Whenever you upgrade Perl::Critic, you may want to run this command again and do a diff with your current perlcriticrc so you can see any changes to existing policies and pick up any new ones.
In terms of running perlcritic regularly, set up a Test::Perl::Critic test along with the rest of your tests. This is good for new code.
For your existing code, use Test::Perl::Critic::Progressive instead. T::P::C::Progressive will succeed the first time you run it, but will save counts on the number of violations; thereafter, T::P::C::Progressive will complain if any of the counts go up. One thing to look out for is when you revert changes in your source control system. (You are using one, aren't you?) Say I check in a change and run tests and my changes reduce the number of P::C violations. Later, it turns out my change was bad, so I revert to the old code. The T::P::C::Progressive test will fail due to the reduced counts. The easiest thing to do at this point is to just delete the history file (default location t/.perlcritic-history) and run again. It should reproduce your old counts and you can write new stuff to bring them down again.
Perl::Critic has a lot of policies that ship with it, but there are a bunch of add-on distributions of policies. Have a look at Task::Perl::Critic and
Task::Perl::Critic::IncludingOptionalDependencies.
You don't need to have a single perlcriticrc handle all your code. Create separate perlcriticrc files for each set of files you want to test and then a separate test that points to each one. For an example, have a look at the author tests for P::C itself at http://perlcritic.tigris.org/source/browse/perlcritic/trunk/Perl-Critic/xt/author/. When author tests are run, there's a test that runs over all the code of P::C, a second test that applies additional rules just on the policies, and a third one that criticizes P::C's tests.
I personally think that everyone should run at the "brutal" severity level, but knock out the policies that they don't agree with. Perl::Critic isn't entirely self compliant; even the P::C developers don't agree with everything Conway says. Look at the perlcriticrc files used on Perl::Critic itself and search the Perl::Critic code for instances of "## no critic"; I count 143 at present.
(Yes, I'm one of the Perl::Critic developers.)
There is perltidy for most stylistic standards. perlcritic can be easily configured using a .perlcritic file. I personally use the it at level one, but I've disabled a few policies.
In addition to 'automated frameworks', I highly recommend Damian Conway's Perl Best Practices. I don't agree with 100% of what he suggests, but most of the time he's bang on.
The post above mentioning Devel::Prof probably really means Devel::Cover (to get the code coverage of a test suite).
Like:
http://metacpan.org/pod/Perl::Critic
http://www.slideshare.net/joshua.mcadams/an-introduction-to-perl-critic/
Looks like a nice tool!
A nice combination is perlcritic with EPIC for Eclipse - hit CTRL-SHIFT-C (or your preferred configured shortcut) and your code is marked up with warning indicators wherever perlcritic has found something to complain about. Much nicer than remembering to run it before checkin. And as normal with perlcritic, it will pick up your .perlcriticrc so you can customise the rules. We keep our .perlcriticrc in version control so everyone gets the same standards.
In addition to the cosmetic best practices, I always find it useful to run Devel::Prof on my unit test suite to check test coverage.