For new checks and feature suggestions

• shellcheck.net (i.e. the latest commit) currently gives no useful warnings about this
• I searched through https://github.com/koalaman/shellcheck/issues and didn't find anything related

Here's a snippet or screenshot that shows the problem:

#!/bin/bash
if [ "$(find "$i" -type l | wc -l)" -eq 0 ]; then

Her

infer version v0.15.0
in my case, 0xFFFF or 0xFFFFFFFF is a common initializer and there are a lot of this semantics in our code. I would like to ignore those harmless. but if I turn off liveness checker, I worry about missing some truely harmful bugs. Does Infer provide some filtering option or method?

Feature request

Hello,

I known we must go one level per level on existing project, but for new project there is the question "Which level I want to enforce without being too hard and assuring minimum clean code".

I think level 2 is great for minmum clean code, level 5 is more great and > 5 needs typehint, from what i gather on searching on internet.

It would be nice that in the docum

One thing that's super useful for new users is code examples. Right now, the biggest problem for someone to start using PHP_CodeSniffer is lack of a list of available Sniffers with their options and examples. From what I know to get a list of all sniffs right now, you have to go through source code in src/Standards, and it's exhausting. Something like [mlocati/phpPHP-cs-fixer-configurator](htt

I have an SQL injection warning detected since updated to the latest Brakeman:

# 'from' is passed in to this method
hdws = Hardware.where("#{from}_id" => targets).select(select)

1. Should this be a warning at all? It was pointed out to me that ActiveRecord will automatically quote the column name passed in like this.

2. On the other hand, I can see why Brakeman might still consider thi

As you may have read in this blog post, we plan to deprecate TSLint in 2019 and support the migration to ESLint as the standard linter for both TypeScript & JavaScript. This will not be an immediate deprecation; on the contrary, there is a lot of work to do to ensure a smooth transition to the new tooling without any regressions. There are

Describe the issue
Needle doesn't seem to be maintained anymore. The last update was > 1 year and no issues have been answered this year. It also doesnt' seem to work on iOS JB devices with Chimera. FSecureLABS/needle#273

We should review where we use Needle and if other tools are a better alternative (e.g. objection, passionfruit).

If you locale is not English, then you may face some errors when maven verify ,the checkstyle validation cannot pass, like #7644 error.

[checkstyle] [ERROR] ……\src\test\java\com\puppycrawl\tools\checkstyle\internal\
powermock\AuditEventDefaultFormatterPowerTest.java:23:1: 
not allowed import： org.mockito.Mocki

Not sure how javadoc is managed currently. But I hope this could save some effort on every release.

Basically https://javadoc.io/doc/com.google.errorprone/error_prone_annotation will always point to the latest version published to JCenter / Central Maven.

Or you can add a badge with versions always up to date:

`[![javadoc](https://javadoc.io/badge2/com.google.errorprone/error_prone_annot

Official security updates for PHP 7.1 have stopped, so the current default of allow_method_param_type_widening => false doesn't make much sense unless a project is deliberately targeting php 7.1

https://www.php.net/manual/en/migration72.new-features.php#migration72.new-features.param-type-widening

Since we are explicitly putting version numbers in our documentation links our releases have become very noisy as you can see in #1391.
Ideally, there would be one cucumber feature that ensures that our links change as well with new versions and that would then cause a one line change per new version release.

The documentation equates two kinds of attribute declarations:

explicit:

 class Derp:
    attribute: int = 1

    @property
    def property(self) -> int: ...

and implicit:

  class Derp:
    def __init__(self):
       self.attribute: int = 1

Those two things are not about explicit v

It'd be great to have a shellcheck like wiki with some more info on each check, why its bad and what the possible fixes are. If this sounds like a good idea, I can start it off with the minimal info.

All the other categories have one-line descriptions on https://staticcheck.io/docs/checks, ST does not.

Nuxt.js's asyncData, fetch and head component properties were already added to the order-in-components rule.

There are others, though:

• key
• layout
• loading
• [middlewar

class A {
  public static function returnsVoid() : void {}
}

/** @param callable():bool $c */
function foo(callable $c) : bool {
  return $c();
}

foo([A::class, 'returnsVoid']);

Expected: Some message telling you that the supplied callable returns void where bool was expected
Actual: Message just says that a bool-returning callable was expected

https://psalm.dev/r/0b

Rule:
DoNotUseThreads

Description:
The documentation in here still shows Runnable as a problematic pattern. However, according to this issue this is no longer the case. Running the t

Reactor is starting to gain some traction so would it be possible to get something like RxNullabilityPropagator to support it?

The pylint docs are currently hosted at pylint.pycqa.org. This doesn't support HTTPS as the certificate used is for *.readthedocs.io:

➜ curl -LIsv https://pylint.pycqa.org/                              
*   Trying 104.208.221.96:443...
* TCP_NODELAY set
* Connected to pylint.pycqa.org (104.208.221.96) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certif