question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Implement new linter checks

See original GitHub issue

This project is aimed at writing linters for the checks below. (Note that, per @Hudda’s audit in May 2020, all checks in this issue would need custom extensions to be developed.) The general procedure to write such linters is as follows:

  • Look at the sample code in the linked issue for the affected area.

  • Think about character by character, word by word, or line by line what would convince you that there is an error.

  • If it is in a Python file, check whether there is already a built-in pylint rule that can detect this. If not, you’ll need to write a Pylint extension…

  • See wiki page for information on writing lint checks.

  • See this page for information on writing pylint extension.

  • Run python -m scripts.run_backend_tests --test_target=scripts.linters.pylint_extensions_test for testing pylint extension against your tests.

A few general guidelines while writing such tests:

  • Try to look at the existing checks to see how others have approached the issue.
  • Look to see if there are existing lint checks out there that can be modified.

To get started, ask to be assigned to any unclaimed task. Tasks are claimed by adding the username of the claimer to the end of the task, e.g. @example.


Python

  • Enforce multiples of 4 indentation in docstring (#8165)
  • Check for proper comment indentation (#6422)
  • Add check for proper Args and Returns style, including typeinfo (#6095) @Hudda
  • Add check to multiline expressions ensuring line break after ‘(’ (#6495) @Hudda
  • Check for args-name for a non-keyword argument (#6067) @Hudda
  • Add check to ensure that pylint pragmas are used to disable any rule for a single line (#5477) @Hudda
  • Add lint check to ensure that there is an empty line between imports and fileoverview (#7830) - @donosco98
  • Add lint check to ensure that there is one blank newline below each class docstring. @Hudda
  • Detect variables that are declared but never used. @Hudda
  • Forbid usage of assertRaises; require assertRaisesRegexp instead. @Hudda
  • Enforce that PEP8 naming convention is followed. Please check the comment here to understand the use case. @sajalasati
  • Check that functions with test_only in their names are only used in _test.py files. @anmol1point0
  • Add check for excessive new lines between function definition in a class. (comment another comment)
  • Add check for newline above Args, Raises and Returns.
  • Forbid use of “if x != None” (prefer “if x is not None” instead) (#11108) @michaelw54
  • Add a lint check to ensure that there is a single space between if, elif, while and bracket (#10486) @EricZLou
  • Add a lint check to ensure that the type info of *args should be list(*).
  • Add a lint check to ensure newline after the Args:, Returns:, Raises:, Yields: in docstrings. (@MegaMind77-coder found that the check already happens via some other method - see this comment)
  • Add a lint check to ensure that there are no blank lines below the function definition. @kingjuno
  • Add a lint check to prevents usage of string concatenation, and promotes string interpolation instead. (This is a coding style guideline of the Oppia codebase - see 4th bullet point here) @tanishq67
  • All docstrings must end with a full stop. (Inspect if we already have this check or not - if we have it then here it was not caught, and if we don’t have it then find a way to enable/implement it) @tanishq67
  • Check to enforce use of Args, Returns and Raises in the docstring. (see explanation here; Depends on #11776 to be completed first)
  • Every comment should have a single space after it (so, no “#pylint: …”) (Note we already have a single line comment checker, but not sure why this check isn’t catching it) @esmith36
  • Prohibit usage of trailing comments (except for pylint pragmas) - (comment) @sajalasati (PR #13681)

Every new JS/TS lint check will be implemented in scripts/linters/custom_eslint_checks/rule/ directory if there is no eslint plugin available for that purpose.

JS/TS

E2E tests (Not available – Reserved for GSoC)

  • #13215 @AdityaDubey0
  • Not using await for .first(), .last(), or .get(i) calls on ElementArrayFinder objects @AdityaDubey0
  • Making sure all root element selectors use HTML classes that start with “protractor-test-”, e.g. element(by.css(‘.protractor-test-parent-element’)).element(by.css(‘.class-of-element-you-cannot-change’)) @AdityaDubey0
  • Keep element selectors at the tops of files. Where selectors cannot be defined at the top of the file, define locators at the top.
  • Do not define element selectors in any files outside of protractor_utils/ or extensions/
  • Only select elements using by.css(...)

CSS

HTML

CODEOWNERS

  • Ensure that CODEOWNERS lines do not have any comments after the line. comment - (#11835)
  • Have codeowners lint check saying if a line is completely superseded (and therefore redundant)

Other

  • Add check to ensure that all lines in skip_files in app.yaml reference valid files in the repository (see this line). @Hudda
  • Add newline check at end of file (#8252) @Hudda
  • Add lint checks to ensure that there are valid spaces and newlines (#7301) @Hudda
  • Lint checks for webpack config (#7414) @Hudda
  • Check that all TODO comments start with capital letter (#7182) @Hudda
  • Check for proper comment style for Python and JS files (#6163) @Hudda
  • Ensure that every file (of any type) ends with exactly one newline character. @Hudda

Issue Analytics

  • State:open
  • Created 4 years ago
  • Reactions:1
  • Comments:321 (230 by maintainers)

github_iconTop GitHub Comments

2reactions
Huddacommented, Sep 30, 2021

@kingjuno I’ve assigned you.

1reaction
Huddacommented, Oct 1, 2021

@kingjuno modify BlankLineBelowFileOverviewChecker

Read more comments on GitHub >

github_iconTop Results From Across the Web

Fix the linter and implement all the lint checks - GitHub
The project aims to fix the linter and implement new lint checks. This project is really important for the following reasons: I. Lint...
Read more >
Improve your code with lint checks - Android Developers
The lint tool checks your Android project source files for potential bugs and optimization improvements for correctness, security, performance, usability, ...
Read more >
Create a linter check - ServiceNow Docs
Select Create a new Linter Check. · On the form, fill in the fields. Table 1. Linter Check form. Fields, Description. Name, Name...
Read more >
Adding custom lint checks
In the new module, add a src folder and a build.gradle file containing the needed ... It is also possible to apply lint...
Read more >
Lint Code: What Is Linting + When To Use Lint Tools | Perforce
Linting is the automated checking of your source code for programmatic and stylistic errors. This is done by using a lint tool (otherwise...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found