Padrões de codificação para WordPress [Guia]

A razão pela qual temos padrões de codificação (não apenas para o WordPress) é criar um ambiente familiar para programadores trabalhando em um projeto. WordPress, em particular, engloba uma ampla variedade de produtos. Do próprio núcleo a temas e plugins, há muito o que olhar - e muito para se confundir.

Se todo mundo formatar seu código da mesma forma, usar comentários, o mesmo estilo de documentação e assim por diante, trabalhar em conjunto se torna muito mais fácil, e a curva de aprendizado de ingressar em um novo projeto não será tão íngreme..

A necessidade de coesão no WordPress é ampliada pelo estado no qual a base de código é. O WordPress não segue uma abordagem estritamente orientada a objetos e não usa um padrão MVC. Projetos que seguem diretrizes OOP e MVC sem exceção (como o Laravel) têm consistência e melhores práticas “cozido em” devido a sua estrutura.

O WordPress está, infelizmente, maduro para codificação de spaghetti, também conhecido como fazendo o que quiser. As práticas recomendadas são difíceis de aplicar simplesmente porque os produtos que empregam códigos ruins podem funcionar tão bem (na superfície).

Seguindo os Padrões de Codificação do WordPress, você pode aprender um pouco sobre os conceitos de codificação do WordPress, criar mais produtos compatíveis com o WordPress. mostrar a comunidade que você se importa e você disputa código de alta qualidade.

Mais sobre Hongkiat.com:

10 piores pesadelos para desenvolvedores web
5 razões pelas quais o CSS pode ser a linguagem mais difícil de todas
30 programadores de reações comuns têm quando as coisas dão errado

Algumas notas sobre os padrões

Os padrões não definem certo e errado. Você pode discordar de uma regra, por exemplo, chaves sempre devem ser usadas, mesmo que não sejam necessárias. O propósito dos padrões de codificação do WordPress não é decidir se você está certo ou errado, é decidir como isso deve ser feito no WordPress..

Os padrões não estão em debate. O uso dos padrões não é o lugar para tomar uma posição contra um estilo de recuo que você não gosta. Se algo estiver nos padrões de codificação, faça isso dessa maneira. Os desenvolvedores do WordPress vão adorar você por isso! Dito isto, se você não concordar com algo lá, eleve sua voz e deixe as pessoas saberem. É sempre possível fazer as coisas melhor, mas você só deve mudar o seu estilo de codificação se os padrões permitirem.

Consistência sobre a retenção anal. Se você está nos últimos 10% do seu projeto e acaba de descobrir que está usando a convenção de nomenclatura incorreta para as classes, não mude para o meio do caminho. Na minha opinião pessoal, eu prefiro ler algo consistentemente incorreto do que algo que às vezes é correto e às vezes não. Você sempre pode escrever um script para alterar as coisas de uma só vez, ou ler o seu código no final.

Seguir padrões é difícil! Colocar uma chave na mesma linha que a função, em vez disso, uma linha abaixo é muito fácil, mesmo se você estiver acostumado a digitar antes. No entanto, quando você precisa pensar em 100 pequenas regras, todo o processo se torna um pouco propenso a erros. Apesar da minha dura postura em seguir os padrões, sou tão culpado quanto qualquer outra pessoa por cometer erros. No final do dia, a indentação incorreta não é um pecado irrevogável. Tente o seu melhor para seguir todas as regras, você aprenderá tudo a tempo.

Padrões de Codificação WordPress

Agora o WordPress tem quatro guias, um para cada idioma principal usado: PHP, HTML, Javascript e CSS. Eles fazem parte de um corpo maior de conhecimento, o Manual do Colaborador Principal. Passar por tudo levaria um tempo, então eu destaquei alguns trechos das quatro línguas que eu vejo frequentemente as pessoas erradas.

PHP

PHP é a principal linguagem do WordPress e é uma linguagem muito fracamente tipada, o que a torna madura para regulação.

Estilos de Brace

Chaves de partida devem sempre ser colocadas no final das linhas. Declarações relacionadas devem ser colocadas na mesma linha que a chave de fechamento anterior. Isso é melhor demonstrado com um exemplo de código:

if (condição) // Do Something elseif (condição) // Do Something else // Do Something

Uso generoso de espaço

Eu não sou um fã de código esmagado (eu tenho visão ruim), então este é um que eu particularmente gosto de impor. Coloque espaços depois vírgulas, e de ambos os lados lógico, comparação, corda e operadores de atribuição, depois de E se, elseif, para, para cada e interruptor declarações e assim por diante.

É mais fácil dizer onde os espaços não devem ser adicionados! As únicas vezes em que você não deve adicionar espaços é quando typecasting ou referenciando matrizes.

Uma exceção bastante confusa para a exceção é matrizes em que o chave de matriz é uma variável, neste caso, use um espaço. Este exemplo deve deixar isso claro:

function my_function ($ complete_array = null, $ key_1 = 4, $ key_2 = 'bar') if (null == $ complete_array) $ final_array = $ complete_array;  else $ key_1 = (inteiro) $ key_1; $ final_array [0] = 'isto'; $ final_array [$ key_1] = 'é'; $ final_array [$ key_2] = 'an'; $ final_array ['last'] = 'exemplo';  return $ final_array;

Convenções de Nomenclatura

Este pode ser difícil de se acostumar, especialmente se você vem de ambientes diferentes. Em poucas palavras:

Nomes variáveis deveria estar todas as letras minúsculas, palavras separadas por sublinhados
Nomes de classe Deveria usar palavras em maiúsculas separados por sublinhados. Siglas deve ser tudo maiúsculas
Constantes deveria estar tudo em maiúsculas, atacado por sublinhados
Nomes de arquivos deveria estar todas as letras minúsculas, separar com traços

Condições Yoda

Escrever condições ao contrário do que você está acostumado a evitar erros de análise. Parece um pouco estranho, mas é melhor código.

if ('Daniel' === $ name) echo 'Escrever artigo você irá';

HTML

O HTML não tem muitas regras associadas a ele, eu poderia criar bastante para tornar as coisas mais modulares. Existem apenas cinco regras que você precisa saber ao escrever HTML:

Seu código deve ser validado em relação ao validador do W3C.
As tags HTML de fechamento automático devem ter exatamente um espaço antes da barra (isso é algo que eu pessoalmente odeio, mas é uma especificação do W3C, não apenas uma perplexidade do WordPress)
Atributos e tags devem estar todos em minúsculas. A única exceção é quando os valores dos atributos são destinados ao consumo humano e, nesse caso, eles devem ser digitados naturalmente.
Todos os atributos devem ter um valor e devem ser citados (escrita não está correto)
A indentação deve ser obtida usando as guias e deve seguir a estrutura lógica.

CSS

CSS é outra linguagem fracamente tipada, então há muito trabalho a ser feito aqui também. Mesmo assim, os padrões são bem fáceis em codificadores.

Seletores

Os seletores devem ser tão qualificados quanto necessário, ser humanamente legíveis, ser todos minúsculos, com palavras separadas por traços, e os seletores de atributos devem usar aspas duplas. Aqui está um exemplo conciso:

input [type = "text"], entrada [type = "password"], .name-field background: # f1f1f1;

Ordem de Propriedade

Os padrões reconhecem a necessidade de algum espaço pessoal aqui, pois eles não prescrevem uma ordem específica para regras de CSS. O que eles Faz digamos é que você deve seguir uma estrutura semântica que faz sentido. Agrupar propriedades por seus relacionamentos ou agrupá-las em ordem alfabética, apenas não os escreva aleatoriamente.

A maior causa de aleatoriedade é a “ah eu também preciso adicionar uma margem” e, em seguida, continue a adicioná-lo ao fundo. Pegue os 3 segundos extras e adicione a regra no lugar lógico.

Exibição
Posicionamento
Modelo de caixa
Cores e Tipografia
De outros

.profile-modal display: bloco; posição: absoluta; esquerda: 100px; top: 90px; fundo: # ff9900; cor: #fff;

Formatação de Valor

Este é um lugar onde eu particularmente odeio ver inconsistências. Se você não seguir as diretrizes, ainda é melhor do que às vezes ver um espaço antes do valor; às vezes usando taquigrafia, às vezes não; às vezes usando unidades em valores 0, às vezes não, etc.

A formatação de valores é bastante complexa, mas vem naturalmente com alguma prática. Dê uma olhada no guia exato no Codex para formatar seus valores.

Javascript

Na minha experiência, o Javascript é mais propenso a ir em todo o lugar. Embora muitos desenvolvedores conheçam uma quantidade considerável de Javascript, ele foi aprendido gradualmente, como uma reflexão tardia em HTML, CSS e PHP. Quando você está apenas começando com um novo idioma, você comete muito mais erros e, se esses erros não causam erros fatais, eles podem se tornar enraizados em você..

Em muitos casos, os padrões referem-se a um limite de linha ou estado “se uma linha não for muito longa”. Refere-se ao Guia de Estilo jQuery que impõe um Limite de 100 caracteres nas linhas. O guia WordPress é baseado no guia jQuery, por isso é uma boa ideia dar uma leitura também.

Ponto e vírgula

Esta é a regra mais simples, mas é frequentemente ignorada. Nunca, nunca, omita um ponto-e-vírgula apenas porque seu código funcionará sem ele. É apenas desleixado.

Recuo

As guias devem sempre ser usadas para recuo. Você também deve recuar o conteúdo de um encerramento, mesmo se o conteúdo de um arquivo inteiro estiver contido em um. Não sei por que, mas o fechamento de alto nível sem recorrer me incomodou mesmo antes de eu ler os padrões.

Linhas de quebra

Ao quebrar cordas longas, sempre quebrar a linha depois de um operador, não deixe uma variável pendurada. Isso torna óbvio, à primeira vista, que a linha está quebrada e você não esqueceu apenas um ponto-e-vírgula.

Além disso, se uma condição for longa, divida-a em várias linhas e adicione uma guia extra antes dela. Este parece muito estranho para os meus olhos, mas a separação entre a condição e o corpo é muito visível.

if (firstCondition () && secondCondition () && thirdCondition ()) var html = 'Esta linha consiste em palavras' + n + ', portanto deve ser dividida após' + 'um operador';

Iteração de jQuery

De acordo com os padrões jQuery iteração (jQuery.each ()) só deve ser usado em objetos jQuery. Você deve usar o básico para, por / em, enquanto loops em Javascript para iterar sobre outras coleções.

Conclusão

Há muito o que observar e acompanhar e não há como alguém aplicar tudo isso de uma só vez. Você deve levar seu código o mais próximo possível dos padrões e trabalhar para segui-los exatamente.

Na minha opinião consistência é a regra mais importante. É melhor fazer algo de forma incorreta do que alternar a meio caminho. Isto é especialmente verdadeiro com as práticas de formatação, uma vez que elas não afetam a funcionalidade do seu código e - na maioria das vezes - pode ser facilmente mudado em lote mais tarde.

Você odeia um elemento dos padrões de codificação, você acha que algo deveria ser adicionado? Deixe-nos saber nos comentários!