Boas Práticas com PHP

Boas práticas, código limpo, recomendações da comunidade e ferramentas bacanas. Tudo isso nessa palestra que abordará tópicos indispensáveis para que você seja capaz de produzir código de qualidade, manutenível e de forma eficiente utilizando recursos da linguagem e algumas ferramentas de apoio

Transcript

1. Boas Práticas com PHP
2. Gustavo Fraga Software Developer github.com/lafraga93/ linkedin.com/in/lafraga93/ twitter.com/lafraga93/
3. composer
23. Basic Coding Standard
24. Padrão Básico de Codificação • utilizar as tags <?php ?> e/ou <?= ?> • nomes de classe em StudlyCaps • nomes de métodos em camelCase • constantes em maiúsculo com separadores em sublinhado
25. Coding Style Guide
26. arquivos • terminar com uma linha em branco no final do arquivo • omitir a tag de fechamento em arquivos contendo somente PHP
27. recuo • quatro espaços, não tab
28. linhas • no máximo 80 caracteres por linha com limite de comprimento de 120 caracteres • uma declaração por linha • linhas sem espaços em branco ao final
29. palavras chave, true, false e null • são escritas em minúsculo
30. namespace / use
32. classes, propriedades e métodos
38. estruturas de controle
45. phpcs
51. phpstan
57. como está o nosso composer.json?
59. object calisthenics
60. níveis de recuo
63. Benefícios (níveis de recuo) • código legível • extract method pattern • não agrega toda a lógica em um único método • princípio de responsabilidade única do SOLID
64. tente não utilizar o “else”
68. Benefícios (tente não utilizar o “else”) • if-else não são divertidos de ler • evita o código hadouken • early returns (tornam o código direto e objetivo, poupando leitura/execução)
69. encapsular tipos primitivos como objetos
71. tipos que possuem comportamento
74. Benefícios (encapsular tipos primitivos) • garante a validação de domínio do tipo no objeto • value object concept
75. coleções de primeira classe
76. classes específicas para coleções, onde os métodos serão exclusivos dela
80. Benefícios (coleções de primeira classe) • princípio de responsabilidade única • classe específica para operações de coleção
81. uma seta (chamada de método) por linha
82. exceto para method chaining (quando a chamada retorna o próprio o objeto)
83. Benefícios (um arrow por linha) • lei de demeter (fale apenas com seu amigos, não expõe informação) • legibilidade do código
84. não abrevie
85. abreviar nomes pq variáveis se repetem, é um forte sinal de repetição de código
86. tente não...
87. • escrever métodos com mais de +20 linhas (c/ espaços e comentários) • criar pacotes com +15 arquivos • escrever classes com +200 linhas (c/ espaços e comentários)
88. Benefícios (tente não escrever / criar) • legibilidade e manutenibilidade do código • indício que as responsabilidades estão bem definidas (nem sempre…)
89. poucas variáveis de instância
90. tente utilizar no máximo 3
91. Benefícios (poucas variáveis de instância) • alta coesão (faz aquilo que deve ser feito) e responsabilidade única • baixo acoplamento (sem dependências desnecessárias) • manutenibilidade do código
92. no getter / setter
93. se não houver vantagem em tê-los, não use!
96. Benefícios (no getter / setter) • encapsular a regra de negócio • atribui lógica com métodos significativos ao invés de métodos “burros”
97. dúvidas?
98. obrigado!