kapost/kapost_deploy

View on GitHub
lib/kapost_deploy/plugins/slack_github_diff.rb

Summary

Maintainability
A
0 mins
Test Coverage

KapostDeploy::Plugins::SlackGithubDiff#initialize calls 'config.app' 2 times
Open

                     ahead_releases: KapostDeploy::Heroku::AppReleases.new(config.app, token: config.heroku_api_token))

        self.ahead_app = config.app

Duplication occurs when two fragments of code look nearly identical, or when two fragments of code have nearly identical effects at some conceptual level.

Reek implements a check for Duplicate Method Call.

Example

Here's a very much simplified and contrived example. The following method will report a warning:

def double_thing()
  @other.thing + @other.thing
end

One quick approach to silence Reek would be to refactor the code thus:

def double_thing()
  thing = @other.thing
  thing + thing
end

A slightly different approach would be to replace all calls of double_thing by calls to @other.double_thing:

class Other
  def double_thing()
    thing + thing
  end
end

The approach you take will depend on balancing other factors in your code.

KapostDeploy::Plugins::SlackGithubDiff#initialize calls 'config.to' 2 times
Open

                     behind_releases: KapostDeploy::Heroku::AppReleases.new(config.to, token: config.heroku_api_token),
                     ahead_releases: KapostDeploy::Heroku::AppReleases.new(config.app, token: config.heroku_api_token))

        self.ahead_app = config.app
        self.behind_app = config.to

Duplication occurs when two fragments of code look nearly identical, or when two fragments of code have nearly identical effects at some conceptual level.

Reek implements a check for Duplicate Method Call.

Example

Here's a very much simplified and contrived example. The following method will report a warning:

def double_thing()
  @other.thing + @other.thing
end

One quick approach to silence Reek would be to refactor the code thus:

def double_thing()
  thing = @other.thing
  thing + thing
end

A slightly different approach would be to replace all calls of double_thing by calls to @other.double_thing:

class Other
  def double_thing()
    thing + thing
  end
end

The approach you take will depend on balancing other factors in your code.

KapostDeploy::Plugins::SlackGithubDiff#initialize calls 'config.options' 2 times
Open

                     notifier: KapostDeploy::Slack::Notifier.new(config.options.fetch(:slack_config, nil)),
                     behind_releases: KapostDeploy::Heroku::AppReleases.new(config.to, token: config.heroku_api_token),
                     ahead_releases: KapostDeploy::Heroku::AppReleases.new(config.app, token: config.heroku_api_token))

        self.ahead_app = config.app

Duplication occurs when two fragments of code look nearly identical, or when two fragments of code have nearly identical effects at some conceptual level.

Reek implements a check for Duplicate Method Call.

Example

Here's a very much simplified and contrived example. The following method will report a warning:

def double_thing()
  @other.thing + @other.thing
end

One quick approach to silence Reek would be to refactor the code thus:

def double_thing()
  thing = @other.thing
  thing + thing
end

A slightly different approach would be to replace all calls of double_thing by calls to @other.double_thing:

class Other
  def double_thing()
    thing + thing
  end
end

The approach you take will depend on balancing other factors in your code.

KapostDeploy::Plugins::SlackGithubDiff#initialize calls 'config.heroku_api_token' 2 times
Open

                     behind_releases: KapostDeploy::Heroku::AppReleases.new(config.to, token: config.heroku_api_token),
                     ahead_releases: KapostDeploy::Heroku::AppReleases.new(config.app, token: config.heroku_api_token))

Duplication occurs when two fragments of code look nearly identical, or when two fragments of code have nearly identical effects at some conceptual level.

Reek implements a check for Duplicate Method Call.

Example

Here's a very much simplified and contrived example. The following method will report a warning:

def double_thing()
  @other.thing + @other.thing
end

One quick approach to silence Reek would be to refactor the code thus:

def double_thing()
  thing = @other.thing
  thing + thing
end

A slightly different approach would be to replace all calls of double_thing by calls to @other.double_thing:

class Other
  def double_thing()
    thing + thing
  end
end

The approach you take will depend on balancing other factors in your code.

KapostDeploy::Plugins::SlackGithubDiff#configured? performs a nil-check
Open

        !git_config.nil? && notifier.configured?

A NilCheck is a type check. Failures of NilCheck violate the "tell, don't ask" principle.

Additionally, type checks often mask bigger problems in your source code like not using OOP and / or polymorphism when you should.

Example

Given

class Klass
  def nil_checker(argument)
    if argument.nil?
      puts "argument isn't nil!"
    end
  end
end

Reek would emit the following warning:

test.rb -- 1 warning:
  [3]:Klass#nil_checker performs a nil-check. (NilCheck)

KapostDeploy::Plugins::SlackGithubDiff#behind_sha1 has the name 'behind_sha1'
Open

      def behind_sha1

An Uncommunicative Method Name is a method name that doesn't communicate its intent well enough.

Poor names make it hard for the reader to build a mental picture of what's going on in the code. They can also be mis-interpreted; and they hurt the flow of reading, because the reader must slow down to interpret the names.

KapostDeploy::Plugins::SlackGithubDiff#ahead_sha1 has the name 'ahead_sha1'
Open

      def ahead_sha1

An Uncommunicative Method Name is a method name that doesn't communicate its intent well enough.

Poor names make it hard for the reader to build a mental picture of what's going on in the code. They can also be mis-interpreted; and they hurt the flow of reading, because the reader must slow down to interpret the names.

KapostDeploy::Plugins::SlackGithubDiff has the variable name '@ahead_sha1'
Open

        @ahead_sha1 ||= ahead_releases.latest_deploy_version

An Uncommunicative Variable Name is a variable name that doesn't communicate its intent well enough.

Poor names make it hard for the reader to build a mental picture of what's going on in the code. They can also be mis-interpreted; and they hurt the flow of reading, because the reader must slow down to interpret the names.

KapostDeploy::Plugins::SlackGithubDiff has the variable name '@behind_sha1'
Open

        @behind_sha1 ||= behind_releases.latest_deploy_version

An Uncommunicative Variable Name is a variable name that doesn't communicate its intent well enough.

Poor names make it hard for the reader to build a mental picture of what's going on in the code. They can also be mis-interpreted; and they hurt the flow of reading, because the reader must slow down to interpret the names.

Put empty method definitions on a single line.
Open

      def after
      end

This cop checks for the formatting of empty method definitions. By default it enforces empty method definitions to go on a single line (compact style), but it can be configured to enforce the end to go on its own line (expanded style).

Note: A method definition is not considered empty if it contains comments.

Example: EnforcedStyle: compact (default)

# bad
def foo(bar)
end

def self.foo(bar)
end

# good
def foo(bar); end

def foo(bar)
  # baz
end

def self.foo(bar); end

Example: EnforcedStyle: expanded

# bad
def foo(bar); end

def self.foo(bar); end

# good
def foo(bar)
end

def self.foo(bar)
end

There are no issues that match your filters.

Category
Status