Prefácio:
O estilo de codificação de uma linguagem de programação é muito importante para um software de manutenção de longo prazo, especialmente no trabalho em equipe. Se uma equipe usa um estilo de codificação unificado e padronizado, poderá melhorar o nível de colaboração e a eficiência do trabalho da equipe. No coração do guia de estilo de programação estão as regras básicas de formatação que determinam como escrever código de alto nível. Este guia vem do livro "JavaScript sustentável", com base nas "especificações de codificação de idiomas Java" e nas especificações de programação JavaScript de Crockford, bem como em algumas das experiências e preferências pessoais de Nicolas. O objetivo de escrever este artigo é aprofundar sua impressão e fazer com que mais pessoas entendam o estilo de codificação JS e melhore sua qualidade de codificação. Para mais informações, leia "escrevendo JavaScript sustentável".
1. Recado
O nível de cada linha é composto de 4 espaços, evitando o recuo usando a guia.
// bom método de escrita se (true) {Dosomething ();}2. comprimento da linha
Cada linha não deve exceder 80 caracteres de comprimento. Se uma linha exceder 80 caracteres, ela deve ser quebrada após um operador. A próxima linha deve adicionar dois níveis de indentação (8 caracteres).
// bom método de escrita doSomething (argumento1, argumento2, aegment3, argumentos4, argumentos5); // Método de escrita ruim: doSomething recuado (argumento1, argumento2, aegment3, argumento4, argumento5);
3. Valor original
As sequências devem sempre usar cotações duplas e manter uma linha, evitando o uso de barras para iniciar uma linha na string.
Os números devem usar números inteiros decimais e algoritmos científicos representam números inteiros, números inteiros hexadecimais ou decimais de ponto flutuante decimal. Pelo menos um número deve ser retido antes e depois do decimal. Evite usar quantidades diretas octais.
O valor especial nulo deve ser evitado, exceto nos seguintes casos.
• Usado para inicializar uma variável, que pode receber um valor a um objeto.
• Usado para comparar com uma variável inicializada, que pode ser ou não um objeto.
• Quando o parâmetro de uma função deverá ser um objeto, ela é passada como um parâmetro.
• Quando o valor de retorno da função deverá ser um objeto, ela é desmaiada como o valor de retorno.
Evite usar valores especiais indefinidos. Para determinar se uma variável é definida, o operador do tipo of que deve ser usado.
4. Espaçamento do operador
Um espaço deve ser usado antes e depois do orçamento binário para manter a expressão arrumada. Os operadores incluem operadores de atribuição e operadores lógicos.
// Boa escrita para (var i = 0; i <contagem; i ++) {process (i);} // escrita ruim: espaço perdido para (var i = 0; i <count; i ++) {process (i);}5. Espaçamento de suporte
Ao usar colchetes, não deve haver espaço imediatamente após o suporte esquerdo e imediatamente antes do suporte fechado.
// Boa escrita para (var i = 0; i <contagem; i ++) {process (i);} // escrita ruim: existem espaços extras em ambos os lados do parâmetro para (var i = 0; i <contagem; i ++) {process (i);}6. Medição direta de objetos
A quantidade direta do objeto deve ter o seguinte formato.
• Os aparelhos esquerdos iniciais devem ser mantidos na mesma linha que a expressão.
• O valor do nome de cada atributo deve ser mantido recuado, e o primeiro atributo deve ser uma nova linha após a cinta encaracolada esquerda.
• O valor do nome de cada atributo deve ser usado sem cotações, seguido por um cólon (antes do espaço), seguido de um valor.
• Se o valor do atributo for um tipo de função, o corpo da função deve iniciar uma nova linha no nome do atributo e uma linha em branco deve ser retida antes e depois.
• As linhas em branco podem ser inseridas antes e depois de um conjunto de propriedades relacionadas para melhorar a legibilidade do código.
• A cinta direita final deve ocupar uma linha exclusivamente.
// bom método de escrita var object = {key1: value1, key2: value2, func: function () {// doSomething}, key3: value3}; // Método de escrita ruim: itens inapropriados Val1: FUNCOTELA2, FUNCOTE2, TAPELO1, TAPELO2, TAPELO2, Método de Bad Drening: Falta em vazão em torno do corpo Var1: // doSomething}, Key3: value3};Quando o literal do objeto é usado como um parâmetro de função, se o valor for uma variável, o aparelho de partida deve estar na mesma linha que o nome da função. Todas as outras regras listadas anteriormente também se aplicam.
// bom método de escrita doSomething ({Key1: value1, key2: value2}); // Método de escrita ruim: todos os códigos doSomething ({key1: value1, key2: value2});7. Comentários
Usar comentários concisos e claros pode ajudar outras pessoas a entender seu código. Os comentários devem ser usados nas seguintes situações.
• O código é obscuro.
• Códigos que podem ser confundidos com erro.
• Código necessário, mas não óbvio, específico do navegador.
• Para objetos, métodos ou propriedades, é necessário gerar documentos (usando comentários apropriados do documento).
Comentários de linha única
Comentários de linha única devem ser usados para ilustrar uma linha de código ou um conjunto de códigos relacionados. Pode haver três maneiras de usar comentários de linha única.
• Comentários exclusivos para explicar a próxima linha de código.
• Comentários no final da linha de código para explicar o código antes dele.
• Várias linhas para comentar um bloco de código.
// Good writing if (condition) { // If the code is executed here, it means that all security checks have been passed;}// Bad writing: There is no blank line before the comment if (condition) { // If the code is executed here, it means that all security checks have been passed;}// Bad writing: Incorrect indentation if (condition) {// If the code is executed here, it means that all security checks have been Passado;} // Redação ruim: Comentários de várias linhas devem ser usados // Este pedaço de código é usado para ** julgamento // então se (condição) {// se o código for executado aqui, significa que todas as verificações de segurança foram passadas, se houve uma boa escrita; quando se quismentos, quando se quisesse, quando se quisesse, se houve uma boa escrita: quando se quisesse, quando se quisesse, se houve uma boa escrita: quando se quismentos, quando se quisesse, quando se quisesse, se houve uma boa escrita: quando se quismentos, quando se destacou; passou permitido (); // execute a função **} // escrita ruim: não há espaços suficientes entre o código e o comentário se (condição) {// se o código for executado aqui, significa que todas as verificações de segurança foram passadas permitidas (); // Execute a função **} // Boa escrita: Ao comentar um bloco de código, você deve entrar em contato para usar um comentário de linha única e os comentários de várias linhas não devem ser usados neste caso. // if (condição) {// permitido (); // execute ** função //}Comentários de várias linhas
Comentários de várias linhas devem ser usados quando o código precisar de mais texto para interpretar. Cada comentário de várias linhas tem pelo menos três linhas da seguinte maneira:
1. A primeira linha inclui apenas o início do comentário /*. Não deve haver outro texto nesta linha.
2. As seguintes linhas começam com * e permanecem alinhadas à esquerda. Estes podem ser descritos em palavras.
3. A última linha começa com */ e permanece alinhada com a linha anterior. Não deve haver outro texto.
A primeira linha de um comentário de várias linhas deve manter o mesmo nível de indentação que descreve o código. Cada linha subsequente deve ter o mesmo nível de indentação e um espaço anexado (para manter adequadamente os caracteres * alinhados). Uma linha em branco deve ser reservada antes de cada código de várias linhas.
// Bom método de escrita, se (condição) {/** se o código for executado aqui* significa que todas as detecções de segurança foram aprovadas*/ permitido ();}Declaração de comentário
Às vezes, os comentários podem ser usados para declarar informações adicionais em um código de código. O formato dessas declarações começa com uma única palavra e é imediatamente seguido por um cólon. As declarações que podem ser usadas são as seguintes.
TODO: O código de descrição ainda não foi concluído. Deve incluir o que você deseja fazer a seguir.
Hack: mostra que a implementação do código tomou um atalho. Deve incluir razões pelas quais os hacks são usados. Isso também pode indicar que pode haver uma solução melhor para o problema.
XXX: Explique que o código é problemático e deve ser corrigido o mais rápido possível.
FIXME: Explique que o código é problemático e deve ser corrigido o mais rápido possível. É um pouco segundo para xxx.
Revisão: Os códigos de instrução precisam ser revisados em possíveis alterações.
Essas declarações podem ser usadas em um ou mais comentários e devem seguir as mesmas regras de formatação que o tipo de comentário geral.
8. Nomeação
Variáveis e funções devem ter cuidado ao nomeá -las. A nomeação deve ser limitada a caracteres alfabéticos numéricos e sublinhados (_) pode ser usado em alguns casos. É melhor não usar o sinal de dólar ($) ou barragem (/) em qualquer nomeação.
A nomeação variável deve estar em formato de nomeação de camelo, com a primeira letra minúscula e a primeira letra de cada palavra maiúscula. A primeira palavra do nome da variável deve ser um substantivo (não um verbo) para evitar confusão com a mesma função. Não use sublinhados em nomes de variáveis.
// Bom método de escrita var responsCouctNumber = "test001"; // Método de escrita ruim: comece com letras maiúsculas var vara contaNumber = "test001"; // Método de escrita ruim: comece com o verbo var getAccountNumber = "test001"; // Método de escrita ruim: use subscore var vara_number = "test001";
Os nomes de funções também devem estar em formato de nomeação de camelos. A primeira palavra do nome da função deve ser um verbo (não um substantivo) para evitar confusão com a mesma variável. É melhor não usar sublinhados em nomes de funções.
// Bom método de escrita função Dosomething () {// Code} // Método de escrita ruim: function Dosomething () {// Code} // Método de escrita ruim: função algo () {// Code} // Método de escrita: Use a função sublinheira Do_something () {// Code}O construtor - uma função que cria um novo objeto através do novo operador - também deve ser nomeado em formato de camelo e o primeiro caractere é capitalizado. O nome do construtor deve começar com um não verbo, porque o novo representa a operação de criar uma instância de um objeto.
// Bom método de escrita função myObject () {// code} // Método de escrita ruim: function myObject () no início das letras minúsculas {// code} // Método de escrita ruim: use a função subdescore my_object () {// código} // método de escrita: função no início do verbo getMyObject () {/ Code} Code}O nome das constantes (variáveis cujos valores não são alterados) deve ser todas as letras maiúsculas, separadas por um único sublinhado entre palavras diferentes.
// Bom método de escrita var total_count = 10; // Método de escrita ruim: formulário de camelo var totalcount = 10; // Método de escrita ruim: formulário misto var total_count = 10;
Os atributos dos objetos são os mesmos que os de variáveis. Os métodos dos objetos são os mesmos que os das funções. Se a propriedade ou método for privado, um sublinhado deve ser adicionado antes dela.
// bom método de escrita var objeto = {_count: 10,4 _getCount: function () {return this._count; }}9. declarações variáveis e de função
Declaração variável
Todas as variáveis devem ser definidas com antecedência antes do uso. Definições variáveis devem ser colocadas no início da função, usando uma variável de expressão Var uma por linha. Exceto pela primeira linha, todas as linhas devem ser recuadas mais uma camada para que os nomes de variáveis possam ser alinhados verticalmente. As definições variáveis devem ser inicializadas e os operadores de atribuição devem manter o indentação consistente. A variável inicializada deve ser antes da variável ser inicializada.
// bom método de escrita var contc = 10, name = "jeri", encontrado = false, vazio;
Declaração de função
As funções devem ser definidas com antecedência antes do uso. Uma função que não é um método (ou seja, nenhum atributo como objeto) deve usar o formato definido pela função (não a função de expressão e formato do construtor da função). Não deve haver espaço entre o nome da função e os parênteses iniciantes. Um espaço deve ser deixado entre os suportes finais e os suportes encaracolados à direita. Os aparelhos encaracolados à direita devem permanecer na mesma linha que a palavra -chave da função. Não deve haver espaço entre os colchetes de partida e final. Um espaço deve ser deixado após uma vírgula entre os nomes dos parâmetros. O corpo da função deve permanecer recuado no primeiro nível.
// Bom método de escrita função externo () {var count = 10, name = "jeri", encontrado = false, vazio; function inner () {// code} // código que chama interno ()}As funções anônimas podem ser atribuídas como métodos aos objetos ou como parâmetros para outras funções. Não deve haver espaço entre a palavra -chave da função e o suporte de partida.
// bom método de escrita object.method = function () {// code}; // Método de escrita ruim: objeto de espaço incorreto.method = function () {// code};A função chamada imediatamente deve ser embrulhada em suportes de jardim na camada externa da chamada de função.
// bom método var value = (function () {// function body return {message: "hi"}} ());Modo rigoroso
O modo rigoroso deve ser usado apenas nas funções e não deve ser usado globalmente.
// Método de escrita ruim: use o modo rigoroso "use rigoroso"; function doSomething () {// code} // bom método de escrita função doSomething () {"use strict"; // código}10. Operadores
Atribuição
Ao atribuir um valor a uma variável, se o lado direito for uma expressão contendo uma instrução de comparação, ela precisará ser envolvida entre parênteses.
// Boa escrita var sinalizador = (i <count); // gravações ruins: ausentes parênteses var band = i <count;
Operador de sinal igual
Use === (estritamente igual) e! == (estritamente desigual) em vez de == (igual) e! = (Desigual) para evitar erros de conversão do tipo fraco.
// Boa escrita var a mesma
Operador triplo
O operador ternário deve ser usado apenas em declarações de atribuição condicional e não deve ser usado como substituto para as instruções if.
// bom método de escrita var valor = condição? Valor1: value2; // Método de escrita ruim: nenhuma atribuição, se a expressão deve ser usada? doSomething (): Dosomethingelse;
11. declaração
Declaração simples
Cada linha contém apenas uma declaração no máximo. Todas as declarações simples devem terminar com um semicolon (;;).
// bom método de escrita contagem ++; a = b; // Método de escrita ruim: múltiplas expressões são escritas em uma contagem de linha ++; a = b;
Declaração de retorno
As declarações de retorno não devem ser envolvidas entre parênteses ao retornar um valor, a menos que, em alguns casos, isso possa facilitar o entendimento do valor de retorno. Por exemplo:
return; return collection.size (); retorno (tamanho> 0? Tamanho: padrão);
Declarações compostas
Uma instrução composta é uma lista de declarações anexadas em aparelhos.
• A instrução fechada deve ser recuada um nível a mais que a instrução composta.
• Os aparelhos iniciais devem estar no final da linha em que a instrução composta está localizada; Os aparelhos finais devem ocupar uma linha e permanecer recuados da mesma forma que o início da declaração composta.
• Quando uma declaração faz parte de uma estrutura de controle, como se ou para declarações, todas as declarações precisam ser incluídas em aparelhos, incluindo uma única declaração. Esta convenção facilita a adição de instruções sem nos preocuparmos em esquecer de adicionar colchetes e causar bugs.
• As palavras -chave para uma declaração como se devem iniciar, seguidas por um espaço e os aparelhos de partida devem ser seguidos por um espaço.
If Declaração
A instrução IF deve estar no seguinte formato.
if (condicionado) {declarações} if (condicionar) {declarações} else {declarações} if (condition) {declarações} else if (condition) {declarações} else {declarações}Nunca é permitido omitir os aparelhos encaracolados nas declarações if.
// Boa escrita if (condição) {Dosomething ();} // Redação ruim: Espaços inadequados se (condição) {Dosomething ();} // Bad Writing: Todo o código está em uma linha se (condição) {Dosomething (); } // Redação ruim: Todo o código está em uma linha e não há aparelhos encaracolados se (condição) dosomething ();para declaração
Para declarações de tipo, deve estar no seguinte formato.
for (inicialização; condição; atualização) {declarações} para (variável no objeto) {declarações}A parte de inicialização da declaração for não deve ter declarações variáveis.
// bom método var i, len; para (i = 0, len = 0; i <len; i ++) {// code} // escrita ruim: declare variável para (var i = 0, len = 0; i <len; i ++) {// code} // gravação: Declare variable para (var prop no objeto) {/Ao usar a instrução FOR-In, lembre-se de usar o HasOwnProperty () para verificação dupla para filtrar os membros do objeto.
enquanto declaração
As declarações da classe While devem estar no seguinte formato.
while (condição) {declarações}Declaração
As declarações da classe DO devem estar no seguinte formato.
fazer {declarações} while (condição);Declaração de interruptor
As declarações da classe Switch devem estar no seguinte formato.
Switch (Expression) {Case Expression: Declarações Padrão: Declarações}O primeiro caso sob o interruptor deve ser mantido recuado. Todos os casos, exceto o primeiro, incluindo o padrão, devem manter uma linha em branco antes dela.
Cada conjunto de declarações (exceto o padrão) deve terminar com quebra, retorno, arremesso ou ser ignorado com uma linha de comentários.
// Bom método de escrita Switch (value) {case 1:/ * cai através de */ caso 2: Dosomething (); quebrar; Caso 3: retornar verdadeiro; Padrão: jogue novo erro ("algum erro");}Se uma instrução Switch não conter um caso padrão, uma linha de comentários deverá ser substituída.
// Bom método de escrita Switch (value) {case 1:/ * cai através de */ caso 2: Dosomething (); quebrar; Caso 3: retornar verdadeiro; padrão: // sem padrão}Tente declaração
As declarações da classe de tentativa devem ser formatadas da seguinte forma.
tente {declarações} catch (variável) {declarações} try {declarações} catch (variable) {declarações} finalmente {declarações}12. Deixe branco
Adicionar linhas vazias de código entre o código relacionado à lógica pode melhorar a legibilidade do código.
Duas linhas vazias são limitadas a usar nas seguintes situações:
• Entre diferentes arquivos de código -fonte.
• Entre as definições de classe e interface.
Linhas em branco de linha única estão disponíveis apenas nos seguintes casos.
• Entre métodos.
• Entre a variável local no método e a instrução First Line.
• Antes de vários comentários de linha única ou única.
• Os blocos de código lógico no método são usados para melhorar a legibilidade do código.
Os espaços devem ser usados nas seguintes situações.
• O caso em que as palavras -chave são seguidas por colchetes devem ser separadas por espaços.
• Um espaço deve ser deixado após uma vírgula na lista de parâmetros.
• Os operandos de todos os operadores binários, exceto os pontos (.) Devem ser separados por espaços. Os operandos dos operadores de monólogos não devem ser separados por espaços em branco, como o sinal menos menos, o incremento (++), o decréscimo (-).
• As expressões da declaração for devem ser separadas por espaços.
13. O que precisa ser evitado
• Não crie novos objetos usando tipos de wrapper originais como string.
• Evite usar avaliar ().
• Evite usar com declarações. Essa declaração não existe mais no modo rigoroso e também pode ser removido nos futuros padrões do ECMAScript.
Escrito no final
Os guias acima não são totalmente seguidos durante o processo de desenvolvimento. Só podemos desenhar alguns deles para melhorar nosso estilo de codificação e tornar nosso código legível e sustentável. Em relação ao estilo de codificação, cada equipe tem suas próprias características. Enquanto a equipe for consistente, não há problema em desenvolver com eficiência. Algumas regras não são algo que devemos obedecer de maneira constante. Por exemplo, em termos de indentação, geralmente usamos a tecla TAB mais conveniente, mas não podemos garantir que a guia represente 4 espaços em qualquer ambiente. Para manter a consistência no indentação, se a tecla TAB for usada, ela deverá ser usada durante todo o processo; E também não precisamos usar "" e "", e também é possível usar ", desde que você mantenha um estilo consistente. Existem muitos outros problemas de estilo semelhantes, todos baseados na escolha pessoal.
Não há regras absolutas, apenas adequadas ou não.