¿Cuáles son las convenciones de codificación comúnmente aceptadas para hojas de estilo en cascada, JavaScript (lenguaje de programación) y HTML?

Hay suficientes convenciones para CSS, JavaScript y HTML para llenar muchos libros, pero intentaré resumir algunos de los conceptos básicos.

En términos generales, la separación debe mantenerse entre CSS (presentación), HTML (contenido) y JavaScript (funcionalidad).

El uso de archivos estáticos externos para CSS y JavaScript garantiza una separación estricta y generalmente mejora la capacidad de almacenamiento en caché y, por lo tanto, el rendimiento general del sitio. Los bloques CSS y JavaScript en línea en HTML (usando los elementos y ) son aceptables en ciertos casos, pero los estilos específicos de elementos y JS (usando el atributo “style” y el protocolo “javascript:” o el evento DOM atributos como “onclick”) están mal vistos, ya que combinan estrechamente HTML, CSS y JS.

Aquí hay algunas convenciones comunes más específicas para cada uno de los tres temas (de ninguna manera es una lista exhaustiva):

HTML

  • Use marcado semántico, en lugar de presentacional. Por ejemplo, marque los párrafos con elementos

    , use para enfatizar en lugar de , y evite usar elementos genéricos

    o cuando haya un elemento más adecuado que pueda transmitir un significado semántico. Básicamente, lo contrario de lo que verá si ve la fuente de esta respuesta creada por WYSIWYG. 😉
  • Aprenda la diferencia entre elementos de bloque, elementos en línea y elementos de bloque en línea. Esto es importante. No anide elementos de nivel de bloque dentro de elementos en línea. Siempre. Incluso si parece que funciona.
  • Utilice encabezados (

    ,

    , etc.) para definir un esquema del documento. Esto mejorará la accesibilidad y permitirá que su documento conserve cierta estructura semántica incluso en ausencia de estilos de presentación.

  • Use tablas para marcar datos tabulares, pero no para crear un diseño. Solo se debe usar CSS para el diseño.
  • Use elementos
  • Use texto de enlace descriptivo, proporcione atributos “alt” significativos para imágenes no decorativas, use roles WAI-ARIA para demarcar regiones en la página cuyo propósito no puede transmitirse fácilmente únicamente a través del marcado semántico, y garantizar una fácil navegación por el teclado (no suponga que el usuario es capaz de usar un mouse). Estas cosas mejorarán significativamente la accesibilidad, si se hacen con cuidado y de manera consistente.
  • Utilice la mejora progresiva, para que los usuarios con JavaScript deshabilitado o sin un complemento de navegador en particular no vean contenido muerto o engañoso que solo sea útil si esas funciones están disponibles.


CSS

  • Aprovecha la cascada. No declare estilos varias veces cuando los mismos estilos se pueden compartir entre múltiples selectores. Utilice la herencia y el acoplamiento suelto para minimizar la redundancia y maximizar la reutilización.
  • Lea la viñeta anterior nuevamente. Y otra vez. Y una cuarta vez. Reutilizar reutilizar reutilizar! No puedo enfatizar esto lo suficiente. Esta es una de las fortalezas más grandes y más olvidadas de CSS.
  • Evite los selectores demasiado específicos que se dirigen a elementos individuales a menos que sea absolutamente necesario. La especificidad innecesaria resulta en redundancia.
  • Comprende cómo funciona la precedencia CSS. Si te encuentras usando! Important para asegurarte de que los estilos se apliquen, lo estás haciendo mal y deberías repensar cómo has organizado tu CSS.
  • Evite usar nombres de clase e identificadores que impliquen estilo, como .redBox o #purpleText. Si alguna vez decide cambiar el color del cuadro o el texto, se le dejará un nombre que contradiga el estilo real y cree confusión.
  • Evite usar la propiedad “display” para cambiar un elemento en línea a un elemento de nivel de bloque, o viceversa. Esto crea confusión y puede conducir a errores.
  • Aprenda las diferencias entre posicionamiento estático, relativo, absoluto y fijo. Esto es importante.
  • No abuses del posicionamiento absoluto. Es poderoso, pero también es restrictivo y puede crear serios problemas de accesibilidad y mantenibilidad si se usa incorrectamente.

JavaScript

  • JavaScript no es Java, a pesar del nombre. Si escribe JS como escribe Java, puede funcionar, pero apestará y será un dolor horrible de mantener.
  • JS es un lenguaje prototípico, no un lenguaje clásico. Aprende lo que eso significa. Si bien puede moldearlo en la forma de un lenguaje clásico y usarlo en un estilo clásico, es mucho más poderoso y más flexible si aprende a aprovechar la herencia prototípica y otras bellezas que los prototipos hacen posible.
  • JS es un lenguaje orientado a objetos, aunque puede usarlo como un lenguaje de procedimiento. Si lo está utilizando como un lenguaje de procedimiento, no está obteniendo el valor de su dinero.
  • Las funciones tienen alcance léxico. Nada más lo hace. Ni bloques, ni objetos, ni nada; solo funciones.
  • Las funciones son objetos de primera clase y llevan consigo su contexto de ejecución, lo que significa que pueden usarse para crear cierres. Aprenda qué es un cierre y por qué es útil. Esta es, con mucho, una de las características más poderosas del lenguaje.
  • JavaScript y el Modelo de objetos de documento (DOM) no son lo mismo. No los confundas. El DOM es simplemente una API de navegador que está expuesta a JavaScript para permitirle trabajar con un documento.
  • Cuando crea variables o funciones en el ámbito global en JS basado en navegador, en realidad las está creando en el objeto de ventana. No contamine el alcance global; ajusta tus variables y funciones en un objeto de cierre o espacio de nombres.
  • La naturaleza dinámica de JavaScript significa que puede crear (y en algunos casos redefinir) propiedades y métodos de las características principales del lenguaje, como el Objeto mismo. Por ejemplo, agregar un método de “recorte” a String.prototype proporcionará ese método a todas las instancias de String que no lo anulen. No abuses de este poder; modificar las funciones del lenguaje principal no se debe hacer a la ligera, sin importar cuántas bibliotecas Ajax lo hagan.

Reitero una vez más que no se trata de una lista completa, pero espero haber cubierto lo básico para darle una idea de los tipos de convenciones que existen.

Aparecerá una y otra vez, pero personalmente creo que dos de las reglas más estrictas de Crockford pueden ayudarlo a evitar dolores de cabeza de JavaScript en el futuro. Son:

  • ===: Úselo religiosamente. Puedes flotar por la vida usando == todo el día. Entonces, un día tendrás un error que es imposible de rastrear debido a las suposiciones ==. Te volverás loco y perderás tu casa, esposa e hijos. Todo podría haberse evitado si hubiera usado ===.
  • Use solo una declaración var por función. Esto hace dos cosas: (1) te obliga a escribir código limpio y a mantener tus métodos pequeños, especializados y fácilmente comprobables. Desarrolla una sensación de cuándo un método es “demasiado largo” y se divide en dos o tres. Y (2) le impide hacer cosas tontas como declarar funciones anónimas dentro de los bucles. Esta práctica es más común de lo que piensas.

Si te obligas a corregir JavaScript de la manera de Good Parts, serás una persona más feliz por eso. Sin embargo, al principio habrá dolor.

La lista de Ryan es bastante completa en el sentido de JS, pero agregaría que para CSS debe leer sobre CSS orientado a objetos ( http://oocss.org/ ) Esto promoverá la reutilización.