Prefacio:
El estilo de codificación de un lenguaje de programación es muy importante para un software de mantenimiento a largo plazo, especialmente en el trabajo en equipo. Si un equipo usa un estilo de codificación unificado y estandarizado, puede mejorar el nivel de colaboración y la eficiencia laboral del equipo. En el corazón de la Guía de estilo de programación hay reglas de formato básico que determinan cómo escribir código de alto nivel. Esta guía proviene del libro "Escribir JavaScript mantenible", basado en las "Especificaciones de codificación de lenguaje Java" y las especificaciones de programación JavaScript de Crockford, así como algunas de las preferencias y experiencia personal de Nicbolas. El propósito de escribir este artículo es profundizar su impresión y hacer que más personas comprendan el estilo de codificación JS y mejoren su calidad de codificación. Para obtener más información, lea "Escribir JavaScript mantenible".
1. Sangría
El nivel de cada fila está compuesto por 4 espacios, evitando la sangría usando la pestaña.
// buen método de escritura if (true) {dosomething ();}2. Longitud de la fila
Cada línea no debe exceder los 80 caracteres de longitud. Si una línea excede los 80 caracteres, debe romperse después de un operador. La siguiente línea debe agregar dos niveles de sangría (8 caracteres).
// Buen método de escritura Dosomething (argumento1, argumento2, aegment3, argumento4, argumento5); // Método de escritura mala: Dosomething de sangría (argumento1, argumento2, aegment3, argumento4, argumento5);
3. Valor original
Las cadenas siempre deben usar citas dobles y mantener una línea, evitando usar cortes para iniciar una línea en la cadena.
Los números deben usar enteros decimales, y los algoritmos científicos representan enteros, enteros hexadecimales o decimales de punto flotante decimal. Al menos un número debe conservarse antes y después del decimal. Evite usar cantidades directas octales.
Valor especial NULL debe evitarse, excepto en los siguientes casos.
• Se utiliza para inicializar una variable, que se le puede asignar un valor a un objeto.
• Se usa para comparar con una variable inicializada, que puede ser o no un objeto.
• Cuando se espera que el parámetro de una función sea un objeto, se pasa como parámetro.
• Cuando se espera que el valor de retorno de la función sea un objeto, se desmaya como el valor de retorno.
Evite usar valores especiales indefinidos. Para determinar si se define una variable, se debe utilizar el tipo de operador.
4. Espacio del operador
Se debe usar un espacio antes y después del presupuesto binario para mantener la expresión ordenada. Los operadores incluyen operadores de asignación y operadores lógicos.
// buena escritura para (var i = 0; i <count; i ++) {proceso (i);} // escritura mala: espacio perdido para (var i = 0; i <count; i ++) {proceso (i);}5. Espacio de soporte
Al usar soportes, no debe haber espacio inmediatamente después del soporte izquierdo e inmediatamente antes del soporte de cierre.
// buena escritura para (var i = 0; i <count; i ++) {proceso (i);} // escritura mala: hay espacios adicionales en ambos lados del parámetro para (var i = 0; i <count; i ++) {Process (i);}6. Medición de objeto directo
La cantidad directa del objeto debe tener el siguiente formato.
• Los aparatos ortopédicos iniciales deben mantenerse en la misma línea que la expresión.
• El valor de nombre de cada atributo debe mantenerse sangrado, y el primer atributo debe ser una nueva línea después de la abrazadera rizada izquierda.
• El valor de nombre de cada atributo debe usarse sin cotizaciones, seguido de un colon (antes del espacio), seguido de un valor.
• Si el valor del atributo es un tipo de función, el cuerpo de funciones debe iniciar una nueva línea bajo el nombre del atributo, y una línea en blanco debe retenirse antes y después.
• Las líneas en blanco se pueden insertar antes y después de un conjunto de propiedades relacionadas para mejorar la legibilidad del código.
• El aparato ortopédico derecho debe ocupar una línea exclusivamente.
// buen método de escritura var objeto = {key1: value1, key2: value2, func: function () {// dosomething}, key3: value3}; // método de escritura malo: inapropiado indentación var objeto = {key1: value1, key2: value2}; // Método de escritura: falta de líneas en blanco alrededor del cuerpo de funciones Object = {Key1: value1, value {// dosomething}, key3: value3};Cuando el objeto literal se usa como parámetro de función, si el valor es una variable, los aparatos iniciales deben estar en la misma línea que el nombre de la función. También se aplican todas las demás reglas previamente enumeradas.
// buen método de escritura Dosomething ({Key1: value1, key2: value2}); // Método de escritura incorrecta: todos los códigos dosomething ({key1: value1, key2: value2});7. Comentarios
El uso de comentarios concisos y claros puede ayudar a otros a comprender su código. Los comentarios deben usarse en las siguientes situaciones.
• El código es oscuro.
• Códigos que pueden confundirse con error.
• Código específico de navegador necesario pero no obvio.
• Para objetos, métodos o propiedades, es necesario generar documentos (utilizando comentarios de documentos apropiados).
Comentarios de una sola línea
Los comentarios de una sola línea deben usarse para ilustrar una línea de código o un conjunto de códigos relacionados. Puede haber tres formas de usar comentarios de una sola línea.
• Comentarios exclusivos para explicar la siguiente línea de código.
• Comentarios al final de la línea de código para explicar el código anterior.
• Múltiples líneas para comentar un bloque de código.
// buena escritura if (condición) {// Si el código se ejecuta aquí, significa que se han aprobado todas las verificaciones de seguridad;} // Escritura incorrecta: no hay una línea en blanco antes del comentario if (condición) {// Si el código se ejecuta aquí, significa que todas las verificaciones de seguridad se han aprobado;} // escritura incorrecta: Incorrectación de la incorrección si (condición) {// si el código se ha ejecutado aquí, se ha aprobado todo lo que se ha pasado, lo que se ha pasado, lo que se ha pasado por todas las verificaciones de seguridad;} Escritura: se deben usar comentarios de múltiples líneas // Este código de código se usa para ** juicio // luego if (condición) {// Si el código se ejecuta aquí, significa que se han aprobado todas las verificaciones de seguridad;} // Buena escritura: Cuando se comente al final de la línea, se debe mantener un espacio entre el final del código y el comentario si (condición) {// si el código se ejecuta aquí, lo que se ha pasado por todos los cheques de seguridad. // Ejecutar la función **} // Escritura deficiente: no hay suficientes espacios entre el código y el comentario if (condición) {// Si el código se ejecuta aquí, significa que todas las verificaciones de seguridad se han pasado permitidas (); // Ejecutar la función **} // buena escritura: al comentar un bloque de código, debe contactar para usar un comentario de una sola línea, y los comentarios de múltiples líneas no deben usarse en este caso. // if (condición) {// permitido (); // ejecutar ** función //}Comentarios de múltiples líneas
Los comentarios de varias líneas deben usarse cuando el código necesita más texto para interpretar. Cada comentario de múltiples líneas tiene al menos tres líneas de la siguiente manera:
1. La primera línea solo incluye el inicio de comentario /*. No debe haber otro texto en esta línea.
2. Las siguientes líneas comienzan con * y permanecen alineadas a la izquierda. Estos se pueden describir en palabras.
3. La última línea comienza con */ y permanece alineada con la línea anterior. No debe haber otro texto.
La primera línea de un comentario de múltiples líneas debe mantener el mismo nivel de sangría que describe el código. Cada línea posterior debe tener el mismo nivel de sangría y un espacio adjunto (para mantener correctamente los * caracteres alineados). Se debe reservar una línea en blanco antes de cada código múltiple.
// buen método de escritura, if (condición) {/** Si el código se ejecuta aquí* Significa que todas las detecciones de seguridad se han aprobado*/ permitido ();}Declaración de comentarios
Los comentarios a veces se pueden usar para declarar información adicional a un código. El formato de estas declaraciones comienza con una sola palabra y es seguido inmediatamente por un colon. Las declaraciones que se pueden usar son las siguientes.
TODO: El código de descripción aún no se ha completado. Debería incluir lo que desea hacer a continuación.
Hack: muestra que la implementación del código ha tomado un atajo. Debe incluir razones por las cuales se utilizan los piratas. Esto también puede indicar que puede haber una mejor solución al problema.
XXX: Explique que el código es problemático y debe solucionarse lo antes posible.
FixMe: explique que el código es problemático y debe solucionarse lo antes posible. Es un poco segundo a xxx.
Revisión: Los códigos de instrucción deben revisarse en cualquier cambio posible.
Estas declaraciones se pueden usar en uno o más comentarios y deben seguir las mismas reglas de formato que el tipo de comentario general.
8. Naming
Las variables y las funciones deben tener cuidado al nombrarlas. El nombramiento debe limitarse a caracteres alfabéticos numéricos, y los subrayadores (_) se pueden usar en algunos casos. Es mejor no usar el signo de dólar ($) o invertido (/) en ningún nombre.
El nombre de la variable debe estar en formato de nomenclatura de camello, con la primera letra minúscula y la primera letra de cada palabra en mayúsculas. La primera palabra del nombre de la variable debe ser un sustantivo (no un verbo) para evitar confusiones con la misma función. No use subrayos en nombres de variables.
// buen método de escritura var AccountNumber = "test001"; // Método de escritura incorrecta: Comience con letras mayúsculas var AccountNumber = "test001"; // Método de escritura incorrecta: Comience con el verbo var getAccountNumber = "test001"; // Método de escritura incorrecta: use subsensor
Los nombres de las funciones también deben estar en formato de nombres de camello. La primera palabra del nombre de la función debe ser un verbo (no un sustantivo) para evitar confusiones con la misma variable. Es mejor no usar subrayos en los nombres de funciones.
// buen método de escritura function dosomThething () {// código} // método de escritura malo: function doSomThething () {// código} // método de escritura malo: functing something () {// código} // método de escritura malo: use la función de ondante do_somthingthing () {// código}El constructor, una función que crea un nuevo objeto a través del nuevo operador, también debe nombrarse en formato de camello y el primer carácter está capitalizado. El nombre del constructor debe comenzar con un no verbo, porque New representa la operación de crear una instancia de un objeto.
// buen método de escritura function myObject () {// código} // método de escritura incorrecta: function myObject () al comienzo de las letras minúsculas {// código} // método de escritura incorrecta: use la función de subscorte my_object () {// código} // método de escritura mala: función al comienzo de verb getMyObject () {// code}El nombre de las constantes (variables cuyos valores no se cambian) debe ser todas las letras mayúsculas, separadas por un solo subrayador entre diferentes palabras.
// buen método de escritura var en total_count = 10; // Método de escritura incorrecta: Camel Form Var TotalCount = 10; // Método de escritura mala: Forma mixta var total_count = 10;
Los atributos de los objetos son los mismos que los de las variables. Los métodos de objetos son los mismos que los de las funciones. Si la propiedad o el método es privado, se debe agregar un subrayamiento antes.
// buen método de escritura var objeto = {_count: 10,4 _getCount: function () {return this._count; }}9. Declaraciones de funciones variables y de funciones
Declaración variable
Todas las variables deben definirse de antemano antes de su uso. Las definiciones variables deben colocarse al comienzo de la función, utilizando una variable VAR de expresión una por línea. Excepto por la primera fila, todas las filas deben sangrarse una capa más para que los nombres variables puedan alinearse verticalmente. Las definiciones de variables deben iniciarse y los operadores de asignación deben mantener una sangría consistente. La variable inicializada debe ser antes de que se inicialice la variable.
// buen método de escritura var count = 10, name = "jeri", encontrado = falso, vacío;
Declaración de funciones
Las funciones deben definirse de antemano antes de su uso. Una función que no es un método (es decir, ningún atributo como objeto) debe usar el formato definido por la función (no el formato de constructor de expresión y función de función). No debe haber espacio entre el nombre de la función y los paréntesis de inicio. Se debe dejar un espacio entre los soportes finales y los soportes rizados a la derecha. Las aparatos ortopédicos de la derecha deben permanecer en la misma línea que la palabra clave de función. No debe haber espacio entre los soportes de inicio y final. Se debe dejar un espacio después de una coma entre los nombres de los parámetros. El cuerpo de la función debe permanecer sangrado en primer nivel.
// buen método de escritura function outer () {var count = 10, name = "jeri", encontrado = falso, vacía; function inner () {// código} // código que llama inner ()}Las funciones anónimas pueden asignarse como métodos a objetos o como parámetros para otras funciones. No debe haber espacio entre la palabra clave de función y el soporte de inicio.
// buen método de escritura objeto.method = function () {// código}; // Método de escritura incorrecta: Space Incorrect Object.method = function () {// código};La función llamada inmediatamente debe envolverse en los soportes de jardín en la capa externa de la llamada de función.
// buen método var value = (function () {// function Body return {Mensaje: "Hi"}} ());Modo estricto
El modo estricto debe usarse solo dentro de las funciones y no debe usarse a nivel mundial.
// Método de escritura incorrecta: use el modo estricto "use estricto"; function dosomething () {// código} // buen método de escritura function dosomething () {"use estrict"; // código}10. Operadores
Asignación
Al asignar un valor a una variable, si el lado derecho es una expresión que contiene una declaración de comparación, debe envolverse entre paréntesis.
// buena escritura var flag = (i <count); // Escritura mala: Falta paréntesis var flager = i <Count;
Operador de signo igual
Use === (estrictamente igual) y! == (estrictamente desigual) en lugar de == (igual) y! = (Desigual) para evitar errores de conversión de tipo débil.
// buena escritura var mismo = (a === b); // buena escritura var mismo = (a == b);
Operador triple
El operador ternario debe usarse solo en declaraciones de asignación condicional y no debe usarse como un sustituto de las declaraciones de IF.
// buen método de escritura Var Value = condición? Value1: Value2; // Método de escritura incorrecta: sin asignación, si la expresión debe usarse? Dosomething (): Dosomethingelse;
11. Declaración
Declaración simple
Cada línea contiene solo una declaración como máximo. Todas las declaraciones simples deben terminar con un punto y coma (;).
// buen recuento de métodos de escritura ++; a = b; // método de escritura incorrecta: las expresiones múltiples se escriben en un recuento de líneas ++; a = b;
Declaración de retorno
Las declaraciones de devolución no deben envolverse entre paréntesis al devolver un valor, a menos que en algunos casos esto pueda hacer que el valor de retorno sea más fácil de entender. Por ejemplo:
return; return Collection.size (); return (tamaño> 0? tamaño: defaultSize);
Declaraciones compuestas
Una declaración compuesta es una lista de declaraciones encerradas en aparatos ortopédicos.
• La declaración adjunta debe sangrarse un nivel más que la declaración compuesta.
• Los aparatos iniciales deben estar al final de la línea donde se encuentra la declaración compuesta; Los aparatos ortopédicos deben ocupar una línea y permanecer sangrado igual que el comienzo de la declaración compuesta.
• Cuando una declaración es parte de una estructura de control, como si o para declaraciones, todas las declaraciones deben estar encerradas en aparatos ortopédicos, incluida una sola declaración. Esta convención nos hace más fácil agregar declaraciones sin preocuparnos por olvidar agregar soportes y causar errores.
• Las palabras clave para una declaración como si debería comenzar, seguido de un espacio, y los aparatos iniciales deben ser seguidos por un espacio.
Declaración if
La declaración IF debe estar en el siguiente formato.
if (condición) {declaraciones} if (condición) {declaraciones} else {declaraciones} if (condición) {declaraciones} else if (condición) {declaraciones} else {declaraciones}Nunca se le permite omitir aparatos rizados en declaraciones IF.
// Buena escritura if (condición) {dosomethething ();} // Escritura mala: espacios inapropiados if (condición) {dosomnething ();} // escritura mala: todo el código está en una línea if (condición) {dosomething (); } // Escritura mala: todo el código está en una línea y no hay aparatos ortopédicos si (condición) dosomething ();para la declaración
Para las declaraciones de tipo deben estar en el siguiente formato.
for (inicialización; condición; actualización) {declaraciones} para (variable en objeto) {declaraciones}La parte de inicialización de la declaración para no debe tener declaraciones variables.
// buen método var i, len; for (i = 0, len = 0; i <len; i ++) {// code} // mala escritura: declarar variable para (var i = 0, len = 0; i <len; i ++) {// código} // escrita mala: declarar variable para (var apto en objeto) {// código}Cuando use la instrucción For-In, recuerde usar aSownProperty () para verificar doble para filtrar los miembros del objeto.
Declaración
Las declaraciones de la clase While deben estar en el siguiente formato.
while (condición) {declaraciones}hacer una declaración
Las declaraciones de la clase DO deben estar en el siguiente formato.
do {declaraciones} while (condición);instrucción de cambio
Las declaraciones de la clase Switch deben estar en el siguiente formato.
Switch (Expression) {Case Expression: Declaraciones predeterminadas: declaraciones}El primer caso debajo del interruptor debe mantenerse sangrado. Cada caso, excepto el primero, incluido el valor predeterminado, debe mantener una línea en blanco antes.
Cada conjunto de declaraciones (excepto el valor predeterminado) debe terminar con el descanso, el retorno, el lanzamiento o ser omitido con una línea de comentarios.
// buen interruptor de método de escritura (valor) {case 1:/ * cae a través de */ case 2: dosomething (); romper; Caso 3: retorno verdadero; predeterminado: arrojar un nuevo error ("algún error");}Si una instrucción Switch no contiene un caso predeterminado, se debe reemplazar una línea de comentarios.
// buen interruptor de método de escritura (valor) {case 1:/ * cae a través de */ case 2: dosomething (); romper; Caso 3: retorno verdadero; predeterminado: // no predeterminado}declaración de prueba
Las declaraciones de la clase TRY deben formatearse de la siguiente manera.
Pruebe {declaraciones} catch (variable) {declaraciones} try {declaraciones} catch (variable) {declaraciones} finalmente {declaraciones}12. Deja blanco
Agregar líneas de código vacías entre el código relacionado con la lógica puede mejorar la legibilidad del código.
Dos líneas vacías se limitan al uso en las siguientes situaciones:
• Entre diferentes archivos de código fuente.
• Entre definiciones de clase y interfaz.
Las líneas en blanco de una sola línea solo están disponibles en los siguientes casos.
• Entre los métodos.
• Entre la variable local en el método y la instrucción de primera línea.
• Antes de los comentarios de múltiples o una sola línea.
• Los bloques de código lógico en el método se utilizan para mejorar la legibilidad del código.
Los espacios deben usarse en las siguientes situaciones.
• El caso en el que las palabras clave son seguidas por entre paréntesis deben separarse por espacios.
• Se debe dejar un espacio después de una coma en la lista de parámetros.
• Los operandos de todos los operadores binarios, excepto los puntos (.), Deben estar separados por espacios. Los operandos de los operadores de monología no deben estar separados por espacios en blanco, como un signo menos menos, incremento (++), disminución (-).
• Las expresiones de la declaración para los espacios deben separarse.
13. Lo que debe evitarse
• No cree nuevos objetos utilizando tipos de envoltorio originales como String.
• Evite usar eval ().
• Evite usar con declaraciones. Esta declaración ya no existe en modo estricto y también se puede eliminar en futuros estándares de ECMAScript.
Escrito al final
Las guías anteriores no se siguen completamente durante el proceso de desarrollo. Solo podemos dibujar algunos de ellos para mejorar nuestro estilo de codificación y hacer que nuestro código sea legible y mantenible. Con respecto al estilo de codificación, cada equipo tiene sus propias características. Mientras el equipo sea consistente, está bien desarrollarse de manera eficiente. Algunas reglas no son algo que debemos obedecer de manera constante. Por ejemplo, en términos de sangría, a menudo usamos la tecla Tab más conveniente, pero no podemos garantizar que la TAB represente 4 espacios en cualquier entorno. Para mantener la consistencia en la sangría, si se usa la tecla TAB, debe usarse durante todo el proceso; Y tampoco tenemos que usar "" y "", y también es posible usar ", siempre que mantenga un estilo consistente. Hay muchos otros problemas de estilo similares, todo basado en la elección personal.
No hay reglas absolutas, solo adecuadas o no.