Add lint checks for common coding issues arising in code reviews.

In code reviews, I’ve noticed a lot of the same style issues come up over and over again, and in order to conserve reviewer time and give contributors faster feedback, these issues should really be addressed by pre-review lint checks. Adding these will also help maintain consistency in our codebase, and ensure that this state of affairs continues to be preserved in the future.

We can handle some of these issues by importing third-party libraries (such as pycodestyle) that might already have support for these checks, but it might also be a good idea to have a framework for adding additional custom lint checks that are specific to our codebase and aren’t easily handled by third-party libraries.

For reference, here is a partial list of the issues I’ve observed. Note to contributors: it is absolutely fine to submit a PR that gets rid of just one or two of these. Note that the corresponding lint errors will need to be fixed before the PR goes in; this should be a good test of the checker that you’ve implemented.

• JavaScript

  • Missing semicolons at end of lines (@apb7 in #4576)

  • Use of ‘==’ rather than ‘===’ – @apb7 in #4573

  • Spurious console.log() statements (@apb7 in #4564)

  • Directives should have an explicit scope key and it should not be scope: true since this leads to hard-to-maintain direct-from-parent imports – @apb7

  • All directives should have restrict: 'E'

  • There should be exactly one directive or service per file.

  • For function args within parens, indent follow-on lines by 2 additional spaces, e.g.: (@apb7 in #4588)

       var thisIsALongFunctionName = (
           argument1, argument2, argument3, argument4,
           argument5, argument6) {
         var firstLineOfFunction = 2;
    

  • Always use templateUrl instead of template (@ishucr7)

  • Align line breaks of angular dependencies with those in the stringified list just below them, and check that the dependencies match exactly

  • Unused Angular dependencies injected into a controller (eslint doesn’t catch this if the dependencies are in the middle of the argument list, but there are plugins like this one which have rules for catching this sort of thing). – @pandeykartikey #4792

  • If something within parens extends across multiple lines, break after the opening ‘(’. – @apb7

  • Check keyword spacing (e.g. between “for” and the next open paren) – @apb7 in #4697

  • Check for trailing whitespaces. – @apb7 in #4699

  • Line breaks here should match up with the line breaks in the stringified dependencies. (See @apb7 in PR #5119)

  • Check for browser.waitForAngular()

• Python

  • Have two lines above class defs – @apb7 #4522
  • Missing docstrings – @vibhor98 (see #2394)
  • Invalid / incorrectly-formatted type info in docstrings.
  • There should be no space after """ in single line docstrings.
  • Args, Returns and Raises parts of docstrings should include type information.
  • Args parts of docstrings should match the actual arg names passed to the method/function.
  • Order of args in the docstrings should match the actual arg names passed to the method/function.
  • Docstrings should have proper indentation. (Refer to PR #4988)
  • In docstrings, don’t have a space or blank line after the initial “”" – @vibhor98 (see #4572)
  • Docstrings should start and end with “”" – @vibhor98 (see #4572)
  • End docstrings and comments with periods – @bansalnitish (see [#4759])
  • Python imports should be alphabetized – @apb7 #4343
  • If something within parens extends across multiple lines, break after the opening ‘(’. (@bansalnitish #4849)
  • Keyword args should be explicitly named in calling functions – @apb7 #4752
  • Check for trailing whitespaces.
  • Pylint pragmas should be used to disable a rule for a single line only (see here).

• HTML

  • In each HTML tag, the attribute names should be unique. – @apb7 #4900
  • All directive files need to end with _directive.html in order to not cause issues during the build process. – @apb7 #4839
  • Check for trailing whitespaces. – @apb7 #4704

[apb7]

Hello, @jervis446! Sure, go ahead!
Thanks!

[DubeySandeep]

@ishucr7, You can take a look at no-inline-template rule of eslint-plugin-angular. (Also, for JS liters plugins you can follow this updated doc.)