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

Resolve most of the "gentle" level PerlCritic violations #22

Merged
merged 4 commits into from Aug 31, 2015

Conversation

Projects
None yet
2 participants
@jamessan
Contributor

jamessan commented Aug 31, 2015

  • ProhibitBarewordFileHandles
  • ProhibitExplicitReturnUndef
  • ProhibitStringyEval
  • RequireBarewordIncludes

jamessan added some commits Aug 31, 2015

Use lexical variables for filehandles instead of barewords.
Quoting PerlCritic's description:

    Using bareword symbols to refer to file handles is particularly evil
    because they are global, and you have no idea if that symbol already
    points to some other file handle.

All bareword handles were replaced with a lexical variable (e.g., my
$fh).
Remove explicit undef returns.
Quoting from PerlCritic:

    Returning C<undef> upon failure from a subroutine is pretty common.
    But if the subroutine is called in list context, an explicit C<return
    undef;> statement will return a one-element list containing
    C<(undef)>.
    …
    The solution is to just use a bare C<return> statement whenever you
    want to return failure.  In list context, Perl will then give you an
    empty list (which is false), and C<undef> in scalar context (which is
    also false).
Use block eval instead of string eval.
Quoting from PerlCritic:

    The string form of C<eval> is recompiled every time it is executed,
    whereas the block form is only compiled once.  Also, the string form
    doesn't give compile-time warnings.
Use bareword require instead of path names.
Quoting PerlCritic:

    When including another module (or library) via the C<require> or
    C<use> statements, it is best to identify the module (or library)
    using a bareword rather than explicit path.  This is because paths
    are usually not portable from one machine to another.

c9s added a commit that referenced this pull request Aug 31, 2015

Merge pull request #22 from jamessan/gentle-critic
Resolve most of the "gentle" level PerlCritic violations

@c9s c9s merged commit 208e5b0 into c9s:master Aug 31, 2015

@jamessan jamessan deleted the jamessan:gentle-critic branch Aug 31, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment