Skip to main content
added 69 characters in body
Source Link
janos
  • 113k
  • 15
  • 154
  • 396

Readability

At some places you'reThe writing style is seriously hurting readability at some places, but especially here:

_constrain: function(step){
    step = parseInt(step) || 0;
    if(step>this.options.steps.length) {return this.options.steps.length+1;} else
    if(step<0) {return 0;} else
    {return step;}
}

This should have been reallyWith the if, else if, else nicely laid out, this becomes:

_constrain: function(step) {
    step = parseInt(step) || 0;
    if (step > this.options.steps.length) {
        return this.options.steps.length + 1;
    } else if (step < 0) {
        return 0;
    } else {
        return step;
    }
}

When laid out like this, it's easier to see new opportunities for simplification. For example:

_constrain: function(step) {
    step = parseInt(step) || 0;
    if (step > this.options.steps.length) {
        return this.options.steps.length + 1;
    }
    return step < 0 ? 0 : step;
}

Parsing integers

The documentation of parseInt says to always specify a radix parameter:

parseInt(step, 10);

Inconsistent writing style

Sometimes you write if statements like this:

if(step===this.options.step){

And sometimes like this:

if( rebind ){
    this._bind();
}
if( update ){
    this.update();
}

It looks as if the code had been written by 2 different people. It would be better to pick one style and stick with it. Which one you pick is a matter of taste, my preference is as you can see in earlier examples.

Ternary on boolean

This is just silly:

var jumpable = ($(e.target).parents('.jumpable').length)?true:false;

Instead of the ternary operator (or if-else) on boolean-y expressions, you can be more direct:

var jumpable = $(e.target).parents('.jumpable').length > 0;

Readability

At some places you're seriously hurting readability:

_constrain: function(step){
    step = parseInt(step) || 0;
    if(step>this.options.steps.length) {return this.options.steps.length+1;} else
    if(step<0) {return 0;} else
    {return step;}
}

This should have been really:

_constrain: function(step) {
    step = parseInt(step) || 0;
    if (step > this.options.steps.length) {
        return this.options.steps.length + 1;
    } else if (step < 0) {
        return 0;
    } else {
        return step;
    }
}

When laid out like this, it's easier to see new opportunities for simplification. For example:

_constrain: function(step) {
    step = parseInt(step) || 0;
    if (step > this.options.steps.length) {
        return this.options.steps.length + 1;
    }
    return step < 0 ? 0 : step;
}

Parsing integers

The documentation of parseInt says to always specify a radix parameter:

parseInt(step, 10);

Inconsistent writing style

Sometimes you write if statements like this:

if(step===this.options.step){

And sometimes like this:

if( rebind ){
    this._bind();
}
if( update ){
    this.update();
}

It looks as if the code had been written by 2 different people. It would be better to pick one style and stick with it. Which one you pick is a matter of taste, my preference is as you can see in earlier examples.

Ternary on boolean

This is just silly:

var jumpable = ($(e.target).parents('.jumpable').length)?true:false;

Instead of the ternary operator (or if-else) on boolean-y expressions, you can be more direct:

var jumpable = $(e.target).parents('.jumpable').length > 0;

Readability

The writing style is seriously hurting readability at some places, but especially here:

_constrain: function(step){
    step = parseInt(step) || 0;
    if(step>this.options.steps.length) {return this.options.steps.length+1;} else
    if(step<0) {return 0;} else
    {return step;}
}

With the if, else if, else nicely laid out, this becomes:

_constrain: function(step) {
    step = parseInt(step) || 0;
    if (step > this.options.steps.length) {
        return this.options.steps.length + 1;
    } else if (step < 0) {
        return 0;
    } else {
        return step;
    }
}

When laid out like this, it's easier to see new opportunities for simplification. For example:

_constrain: function(step) {
    step = parseInt(step) || 0;
    if (step > this.options.steps.length) {
        return this.options.steps.length + 1;
    }
    return step < 0 ? 0 : step;
}

Parsing integers

The documentation of parseInt says to always specify a radix parameter:

parseInt(step, 10);

Inconsistent writing style

Sometimes you write if statements like this:

if(step===this.options.step){

And sometimes like this:

if( rebind ){
    this._bind();
}
if( update ){
    this.update();
}

It looks as if the code had been written by 2 different people. It would be better to pick one style and stick with it. Which one you pick is a matter of taste, my preference is as you can see in earlier examples.

Ternary on boolean

This is just silly:

var jumpable = ($(e.target).parents('.jumpable').length)?true:false;

Instead of the ternary operator (or if-else) on boolean-y expressions, you can be more direct:

var jumpable = $(e.target).parents('.jumpable').length > 0;
deleted 195 characters in body
Source Link
janos
  • 113k
  • 15
  • 154
  • 396

Readability

At some places you're seriously hurting readability:

_constrain: function(step){
    step = parseInt(step) || 0;
    if(step>this.options.steps.length) {return this.options.steps.length+1;} else
    if(step<0) {return 0;} else
    {return step;}
}

This should have been really:

_constrain: function(step) {
    step = parseInt(step) || 0;
    if (step > this.options.steps.length) {
        return this.options.steps.length + 1;
    } else if (step < 0) {
        return 0;
    } else {
        return step;
    }
}

When laid out like this, it's easier to see new opportunities for simplification. For example:

_constrain: function(step) {
    step = parseInt(step) || 0;
    if (step > this.options.steps.length) {
        return this.options.steps.length + 1;
    }
    return step < 0 ? 0 : step;
}

Parsing integers

The documentation of parseInt says to always specify a radix parameter:

parseInt(step, 10);

Inconsistent writing style

Sometimes you write if statements like this:

if(step===this.options.step){

And sometimes like this:

if( rebind ){
    this._bind();
}
if( update ){
    this.update();
}

It looks as if the code had been written by 2 different people. It would be better to pick one style and stick with it. Which one you pick is a matter of taste, my preference is as you can see in earlier examples.

Ternary on boolean

This is just silly:

var jumpable = ($(e.target).parents('.jumpable').length)?true:false;

Instead of the ternary operator (or if-else) on boolean-y expressions, you can be more direct:

var jumpable = $(e.target).parents('.jumpable').length > 0;

Naming

I find the term "jump" a bit strange throughout the code, because jumping intuitively means a leap bigger than a step, but it seems to me that you're really just stepping.

Readability

At some places you're seriously hurting readability:

_constrain: function(step){
    step = parseInt(step) || 0;
    if(step>this.options.steps.length) {return this.options.steps.length+1;} else
    if(step<0) {return 0;} else
    {return step;}
}

This should have been really:

_constrain: function(step) {
    step = parseInt(step) || 0;
    if (step > this.options.steps.length) {
        return this.options.steps.length + 1;
    } else if (step < 0) {
        return 0;
    } else {
        return step;
    }
}

When laid out like this, it's easier to see new opportunities for simplification. For example:

_constrain: function(step) {
    step = parseInt(step) || 0;
    if (step > this.options.steps.length) {
        return this.options.steps.length + 1;
    }
    return step < 0 ? 0 : step;
}

Parsing integers

The documentation of parseInt says to always specify a radix parameter:

parseInt(step, 10);

Inconsistent writing style

Sometimes you write if statements like this:

if(step===this.options.step){

And sometimes like this:

if( rebind ){
    this._bind();
}
if( update ){
    this.update();
}

It looks as if the code had been written by 2 different people. It would be better to pick one style and stick with it. Which one you pick is a matter of taste, my preference is as you can see in earlier examples.

Ternary on boolean

This is just silly:

var jumpable = ($(e.target).parents('.jumpable').length)?true:false;

Instead of the ternary operator (or if-else) on boolean-y expressions, you can be more direct:

var jumpable = $(e.target).parents('.jumpable').length > 0;

Naming

I find the term "jump" a bit strange throughout the code, because jumping intuitively means a leap bigger than a step, but it seems to me that you're really just stepping.

Readability

At some places you're seriously hurting readability:

_constrain: function(step){
    step = parseInt(step) || 0;
    if(step>this.options.steps.length) {return this.options.steps.length+1;} else
    if(step<0) {return 0;} else
    {return step;}
}

This should have been really:

_constrain: function(step) {
    step = parseInt(step) || 0;
    if (step > this.options.steps.length) {
        return this.options.steps.length + 1;
    } else if (step < 0) {
        return 0;
    } else {
        return step;
    }
}

When laid out like this, it's easier to see new opportunities for simplification. For example:

_constrain: function(step) {
    step = parseInt(step) || 0;
    if (step > this.options.steps.length) {
        return this.options.steps.length + 1;
    }
    return step < 0 ? 0 : step;
}

Parsing integers

The documentation of parseInt says to always specify a radix parameter:

parseInt(step, 10);

Inconsistent writing style

Sometimes you write if statements like this:

if(step===this.options.step){

And sometimes like this:

if( rebind ){
    this._bind();
}
if( update ){
    this.update();
}

It looks as if the code had been written by 2 different people. It would be better to pick one style and stick with it. Which one you pick is a matter of taste, my preference is as you can see in earlier examples.

Ternary on boolean

This is just silly:

var jumpable = ($(e.target).parents('.jumpable').length)?true:false;

Instead of the ternary operator (or if-else) on boolean-y expressions, you can be more direct:

var jumpable = $(e.target).parents('.jumpable').length > 0;
Source Link
janos
  • 113k
  • 15
  • 154
  • 396

Readability

At some places you're seriously hurting readability:

_constrain: function(step){
    step = parseInt(step) || 0;
    if(step>this.options.steps.length) {return this.options.steps.length+1;} else
    if(step<0) {return 0;} else
    {return step;}
}

This should have been really:

_constrain: function(step) {
    step = parseInt(step) || 0;
    if (step > this.options.steps.length) {
        return this.options.steps.length + 1;
    } else if (step < 0) {
        return 0;
    } else {
        return step;
    }
}

When laid out like this, it's easier to see new opportunities for simplification. For example:

_constrain: function(step) {
    step = parseInt(step) || 0;
    if (step > this.options.steps.length) {
        return this.options.steps.length + 1;
    }
    return step < 0 ? 0 : step;
}

Parsing integers

The documentation of parseInt says to always specify a radix parameter:

parseInt(step, 10);

Inconsistent writing style

Sometimes you write if statements like this:

if(step===this.options.step){

And sometimes like this:

if( rebind ){
    this._bind();
}
if( update ){
    this.update();
}

It looks as if the code had been written by 2 different people. It would be better to pick one style and stick with it. Which one you pick is a matter of taste, my preference is as you can see in earlier examples.

Ternary on boolean

This is just silly:

var jumpable = ($(e.target).parents('.jumpable').length)?true:false;

Instead of the ternary operator (or if-else) on boolean-y expressions, you can be more direct:

var jumpable = $(e.target).parents('.jumpable').length > 0;

Naming

I find the term "jump" a bit strange throughout the code, because jumping intuitively means a leap bigger than a step, but it seems to me that you're really just stepping.