Laravel Pint é a novidade da equipe Laravel. Um excelente wrapper para o PHP CS Fixer, que é minha ferramenta de padrões de código preferida.

Já escrevi sobre o lançamento do Laravel Pint quando foi lançado. Por padrão, ele seguirá o laravel padrão original, um padrão personalizado pela equipe do Laravel.

Mas o que fazemos se quisermos algo diferente? Vamos nos aprofundar um pouco.

Se você ler a documentação, verá que ela é muito informativa sobre o que você pode fazer com o Laravel Pint. É possível implementar muitas regras em um prático arquivo JSON, mas quais funcionam bem e o que você deve fazer?

Vou mostrar a você minha configuração pessoal do Laravel Pint e explicar o que e por que escolhi essas configurações.

# Alinhar comentários multilinha

Esta regra align_multiline_comment permitirá que você corrija quaisquer comentários que eu chamar de "errados". Todos eles estão desalinhados e com aparência estranha. Não é algo significativo em termos do seu código, mas é um incômodo ao lê-lo, pois seus olhos serão atraídos para ele em vez do que você deseja focar.

# Recuo de matriz

A regra array_indentation permitirá que você corrija quaisquer arrays que esteja criando e que, por algum motivo, tenham "travado" novamente. Outra regra de limpeza de código que corrigirá onde espaços podem estar sendo usados ​​no lugar errado, etc.

# Sintaxe de matriz

Esta array_syntax regra pode não ser necessária, dependendo da idade do seu código. Ela alterará a array() sintaxe antiga para a nova [] . Eu a mantenho caso eu tenha código antigo ou esteja trabalhando com vários desenvolvedores que podem cair em velhos hábitos.

# Linha em branco após namespace

A blank_line_after_namespace regra é uma regra de manutenção que eu uso para garantir que sempre haja uma linha em branco sob a declaração de namespace em qualquer classe.

# Linha em branco após a tag de abertura

A blank_line_after_opening_tag regra é semelhante à anterior, mas impõe uma linha em branco após a tag PHP de abertura. Gosto de manter meu código organizado e uniforme - essas regras permitem isso.

# Combine emissões consecutivas

A combine_consecutive_issets regra me ensinou que eu poderia usar mais de um argumento em uma verificação de isset — o que era algo novo para mim. Isso converterá qualquer código que combine uma ou mais verificações de isset em uma verificação limpa.

// before
if (isset($a) && isset($b))
 
// after
if (isset($a, $b))

# Combinar Unsets Consecutivos

A combine_consecutive_unsets regra é como a regra acima, algo que eu não sabia que podia fazer - e me obriga a usar um código melhor.

// before
unset($a);
unset($b);
 
// after
unset($a, $b);

# Espaço Concat

A concat_space regra é uma das minhas favoritas. Ela força espaços entre qualquer concatenação de strings — o que é uma das coisas que detesto não ver. Gosto que meu código tenha espaço, não fique todo espremido, como se o espaço o tornasse lento.

// before
$name = $request->get('name');
$message = 'Hello '.$name;
 
// after
$message = 'Hello ' . $name;

# Declarar Parênteses

A declare_parentheses regra é quase o oposto da regra acima. Sempre que uso uma declare declaração, quero garantir que não haja espaços desnecessários ao redor dela.

// before
declare( strict_type = 1 );
 
// after
declare(strict_types=1);

# Declarar Tipos Estritos

Esta declare_strict_types regra é essencial para mim. Com a quantidade de tipos que utilizo no meu código, também gosto de garantir que a tipagem estrita esteja habilitada. Esta é uma regra útil para forçar isso na sua base de código sem precisar se lembrar de adicioná-la sempre. Ótimo para Laravel, pois você não precisa modificar seus stubs para adicioná-los!

declare(strict_types=1);

# Variável de string explícita

explicit_string_variable Adoro adicionar essa regra, pois torna meu código muito mais fácil de ler. Sempre que você usar variáveis ​​implícitas no seu código, isso as tornará explícitas, como a seguir:

$name = 'Steve';
 
$implicit = "Hello, $name";
$explicit = "Hello {$name}";

# Aula Final

Essa final_class é uma regra que vou assombrar o Michael Dyrynda. Ela força todas as suas classes a serem finais na sua aplicação. Tenha cuidado, porém, pois isso tornará todas as classes finais, o que pode levar a quebras se usar pest ou estender o Controlador base no Laravel. Felizmente para mim, não me preocupo tanto com isso, pois não uso muita herança.

# Classe interna final

A final_internal_class regra é uma maneira de combater a regra acima. Se você não quiser que uma classe seja final porque planeja estendê-la, certifique-se de que esta regra esteja definida false em sua configuração. Isso fará com que a regra final ignore esta e que as classes internas não devem ser finais.

{
  "final_internal_class": false
}

# Tipos Estritos Totalmente Qualificados

A fully_qualified_strict_types regra forçará você a importar a classe como uma instrução use no seu código em vez de declarar o nome da classe totalmente qualificado como um tipo em métodos etc. Isso mantém o código limpo, e código limpo é código feliz.

// before
public function __invoke(\Illuminate\Http\Request $request)
 
// after
public function __invoke(Request $request)

Há muitas outras regras que eu uso, então, em vez de entediá-lo com cada uma delas, compartilharei minha configuração. Dê também uma olhada no site de configuração do PHP CS para que você possa ver quais são as regras e o que elas fazem.

Aqui está minha configuração atual , mas lembre-se de que eu a ajusto com frequência, pois acredito que os padrões de código devem ser uma coisa viva. Deve ser algo que você reavalie constantemente para ver se ainda atende às suas necessidades.