@tpzdsp/eslint-config-dsp
Version:
re-usable config for ESLint, Prettier and semantic-release
24 lines (15 loc) • 1.37 kB
Markdown
This PR closes #
Preview at https://pr-NUMBER-app.testing.orbis.astrosat.net/
<!--
FOR DEVELOPERS
**Code reviews** can be a complicated task, depending on the reviewer's *familiarity*|*experience* etc.
Things to focus on, in order of priority:
1. Can I understand the code and it’s intent? Code is always read a lot more than written and should be easy to understand.
1. Is the code correct, as far as I can tell? Are there ways to prove this is the case (i.e. tests/types/assertions etc)?
1. Is the architecture sound? Or are we coding ourselves into a place that will be hard to change?
1. Is the code reasonably performant? This isn’t about micro-optimizations, but sometimes equivalent code with quadratic complexity can be substituted by linear complexity with no loss on the points above.
1. Unnecessary code: Is there an option in one of the libs that makes code unnecessary? Is there code somewhere else in the code base that can now be deleted? Remember that all code is a liability.
The above are the high-level areas to look at, but it doesn't really help new reviewers with what sort of checks you should be making. I've found this [checklist](https://www.liberty.edu/media/1414/%5B6401%5Dcode_review_checklist.pdf) useful in being consistent with my reviews
LATEST COPY OF THIS TEXT:
https://github.com/astrosat/company-wiki/wiki/Code-Review
-->