Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added eslint and fixed all errors #36

Merged
merged 7 commits into from
Mar 22, 2018

Conversation

rhbvkleef
Copy link
Contributor

@rhbvkleef rhbvkleef commented Mar 10, 2018

Closes #3

This PR adds eslint, and fixes the errors discovered by it. The preset used is based of the one used by the P5.js project, but has some modifications. Here is a non-exhaustive list of rules added:

  • allow-parens: In arrow functions, don't add parentheses with 1 argument, always add them otherwise.
  • brace-style: Opening brace on same line as relevant keyword, closing one on the same line of next relevant keyword, if there is any. (e.g. else)
  • comma-dangle: In multi-line arrays, objects, ...: the last value requires a comma behind it.
  • keyword-spacing: spaces around all keywords
  • max-len: Maximum line-length is 100 chars
  • max-params: Maximum parameters on one line is 6
  • no-cond-assign: Don't allow assignment of variable inside conditional, unless an extra pair of brackets is added.
  • eqeqeq: In most comparisons, require a triple equals
  • no-use-before-define: Require a variable defenition to happen before usage (except for functions)
  • new-cap: Require class names and constructor names to be capitalized. ("Bird", not "bird")
  • no-caller: Disallow arguments.caller and arguments.callee
  • no-undef: Don't allow usage of undefined variables
  • no-unused-vars: Don't allow defining and assigning of unused variables
  • no-empty: Don't allow empty code blocks
  • no-console: Don't allow console statements (console.log)
  • quotes: Require single quotes
  • semi: Require trailing semicolons
  • space-before-blocks: Require whitespace before opening curly brace

In addition to that, "eslint:recommended" adds all rules that have a checkmark in fromt of them on
this (https://eslint.org/docs/rules/) page and p5 and p5/dom add globals exported by P5 and P5.dom.

Copy link
Member

@shiffman shiffman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you so much for submitting this!

bird.js Outdated
@@ -3,6 +3,9 @@
// http://patreon.com/codingtrain
// Code for: https://youtu.be/cXgA1d_E-jY

/* global birdSprite */

// eslint-disable-next-line no-unused-vars
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a way to do this in a config file? I would like the code to have minimal comments to reduce any noise as I use it as the basis for the neuro-evolution tutorials.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had been searching for a while, a possibility is to move everything into a global comment. I am currently looking at whether it can be hidden in the .eslintrc (at which point I'll run a base configuration for you to extend) but haven't found that yet.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apart from the fact that I think that the global asset thing is poor code-style, I don't think eslint has an easy way to configure usage checking globally. (using "no-unused-vars": ["error", {"vars":'local"}]) would be an option but that would miss a lot of critical linting errors. In the commit that I am pushing right now, I also replaced the disable-next-line clauses with exported clauses, as they are a bit clearer.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can live with the globals though I would probably prefer to put them in a config file and not have anything related to eslint in the code itself. But if having these comments is standard JavaScript practice then maybe it's good to have that here and expose viewers to this option when linting! What about also adding something that says:

/* comments for eslint configuration */

There's probably a better way to phrase that. What do you think @meiamsome?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can add globals to the config file for simplicity in this case, but I am not sure what is the best course of action.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to try that unless anyone objects! @rhbvkleef do you want to add that to this pul request? I'm also happy to merge and refactor after if you prefer.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even though I personally disagree with configurations like this, I added them as you requested.

bird.js Outdated
@@ -19,7 +22,13 @@ class Bird {

show() {
// draw the icon CENTERED around the X and Y coords of the bird object
image(this.icon, this.x - (this.width / 2), this.y - (this.height / 2), this.width, this.height);
image(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My preferred style is to actually leave this in one line of code. (Don't hate me!)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll adjust the eslintrc

pipe.js Outdated
@@ -18,9 +21,15 @@ class Pipe {
}

hits(bird) {
if (bird.y - (bird.height / 2) < this.top || bird.y + (bird.height / 2) > this.bottom) {
if (
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here, one line.

pipePeakSprite = loadImage("./graphics/pipe_body.png");
birdSprite = loadImage("graphics/train.png");
bgImg = loadImage("graphics/background.png");
pipeBodySprite = loadImage('./graphics/pipe_body.png');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yay single quotes! ❤️

@@ -38,9 +45,9 @@ function draw() {
// second copy of the image right next to it
// once the second image gets to the 0 point, we can reset bgX to
// 0 and go back to drawing just one image.
if(bgX <= -bgImg.width + width){
if (bgX <= -bgImg.width + width) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yay spaces! 😍

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have personally never understood spaces after if/for/when - the brackets are a part of the keyword construct so why would they be separated? It would be like having function calls as loadImage ('...');, which, although syntactically valid, I have never seen anyone use.

(Note this isn't a request to change, I'm just wondering what the reasoning behind this is)

Copy link
Member

@shiffman shiffman Mar 11, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haha, interesting point! In my mind the space actually distinguishes the structure from a function call -- if, for, and while being special control structures? But this may just be what I tell myself to sleep at night as the missing space sends me into a panic spiral.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my reasoning, a branch construct has three or more parts, which are space separated: the keyword, the condition and the code-block. Additionally an else/elseif can be added. For me this sounds like reason to add spacing.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, interesting. Those both sound like good reasoning. I think I'd be more likely to also be for that space convention if the form of if a b else c was allowed without the brackets (See Rust for an example when I think the syntax feels very intuitive). With them as required it feels to me like they should be attached, but thanks for telling me your thoughts!

@rhbvkleef rhbvkleef mentioned this pull request Mar 11, 2018
@rhbvkleef
Copy link
Contributor Author

When merging this, I recommend squashing. The reason is that this branch is build up from a lot of small commits, some of which don't really have descriptive names.

@rhbvkleef
Copy link
Contributor Author

@shiffman Still planning on merging this or close some discussions that we had. I believe they are resolved as of my last commit.

@Versatilus
Copy link
Collaborator

It looks like everything is in order. Awesome!

@Versatilus Versatilus merged commit b1e95b4 into CodingTrain:master Mar 22, 2018
@rhbvkleef rhbvkleef deleted the 3-add-linting-new branch March 25, 2018 12:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add linting!
4 participants