Práctica recomendada para asignar un nombre al atributo Id de los elementos Dom

Question

Esto está relacionado con las convenciones de nomenclatura para el atributo id de un elemento DOM y supongo que también el atributo de nombre. En lo que respecta a JavaScript, por lo que entiendo y lo que he hecho es usar siempre camel case, excepto los nombres de las clases. Las clases están encastradas en Pascal.

Habiendo dicho que desarrollo en ASP.NET principalmente y aquí es donde me encuentro con un problema de nomenclatura para el atributo id. En ASP.NET si arrastras y sueltas un nuevo control de servidor a una página (cosa que raramente hago, soy un tipo el chico de markup), los nombres predeterminados siempre son encasillados porque tienen que ajustarse al framework .NET directrices de nombres para el código del lado del servidor.

Así que cuando se trata de nombrar el atributo id de los controles del servidor ASP.NET o simplemente elementos en el marcado, sigo la regla camel case el atributo id (directrices de nomenclatura de Javascript), pero esto entra en conflicto con las directrices de nomenclatura .NET .

Así que, uno, ¿qué carcasa hacen normalmente para el atributo id en elementos DOM y dos qué hacen los usuarios de .NET que desarrollan en ASP.NET para nombrar el atributo id?

Además de eso, cuando estoy creando elementos de formulario en el marcado, por lo general utilizan la notación húngara para las entradas de texto, como

<input type="text" id="txtUserName" /> 

o casillas de verificación como

<input type="checkbox" id="chkSelectAll" /> 

lo que sin duda va en contra Pautas de nomenclatura de códigos del lado del servidor .NET y también directrices de JavaScript.

Cualquier consejo es muy apreciado.

Answer 1

• Mantenerlo semántico. Use palabras completas, simples, (preferiblemente en inglés). No intente encontrar algo sofisticado o técnico, y no describa lo que es - lo sabemos. Describa lo que hace. La descripción del propósito agrega valor informativo.

• ¡No abrevie nada! BW_RCB01_SW significaba algo para el equipo que hizo nuestro CSS hace años, pero ahora no significa nada para mí y tengo que trabajar hacia atrás para tratar de traducir lo que BW_RCB01_SW corresponde a mis propósitos, y recordar esa traducción o documentarla algun lado. ¿Mejor? blackwhite-boxtype1-bottomleft. Es más largo pero tampoco requiere una piedra Rosetta.

• Conservar todo en minúsculas y usar guiones bajos o guiones. Yo prefiero los guiones, pero eso es totalmente una preferencia. No debe haber ningún impedimento para usar guiones, ya que no están reservados en CSS o HTML, y los ID se tratan como cadenas literales en cualquier otro idioma. La minúscula es toda la experiencia: demasiadas horas desperdiciadas preguntándose por qué diablos no se aplicará este estilo oh. pageContainerLeft no es lo mismo que pageContainerleft.

• Identificar exactamente lo que es ese elemento, pero no más. Piense seriamente sobre cada pieza de información que está incorporando en el nombre y si es necesario. En su ejemplo, ¿usted necesita para saber que es una casilla de verificación por la ID? Improbable. Ya sabes a qué elemento te refieres porque es una identificación única y tienes que codificar contra ese elemento de todos modos.

Answer 2

Estas son algunas directrices de denominación que me han ayudado con mis identificaciones y clases en el DOM:

• no incluyen el tipo en el nombre (es decir, ningún txt o chk). Puedo seleccionar esa información usando CSS o jQuery mucho más descriptivlely
• use guiones bajos como separadores en el nombre. Los guiones no siempre funcionan en otros idiomas, y la carcasa de camello es un poco difícil de leer en el marcado

Answer 3

Uno de los gurús HTML en mi último trabajo realmente recomendable delimitar identificadores de varias palabras con guiones

<input type="text" id="user-name" /> 

Estoy luchando por recordar por qué: ya no tengo acceso a esos documentos de estándares internos. Sin embargo, sé que realmente no responde a tu pregunta sobre la carcasa Pascal vs Camel.

Yo personalmente desaconsejo el uso de HN - considero que es una práctica muy aborrecible. ¿Qué sucede si necesita cambiar su matriz de casilla de verificación a un elemento de selección en su lugar? Ahora el ID del elemento tiene semántica falsa cocida al horno. Simplemente no vale la pena la molestia, IMO.

Answer 4

Nombrar tan pocos objetos como sea posible definitivamente ayuda a mantener las cosas limpias. Si puede obtener al nombrar al padre y solo refiriéndose al niño, eso será mejor (en mi opinión). Obtiene la bonificación de un poco menos de HTML renderizado para el cliente en cada página.

Para cuando tengo que nombrar elementos, prefiero todo en minúscula, con notación de subrayado. Me han engañado al no encontrar mi caso en los archivos CSS antes, así que si puedo contarlo como un problema temprano, eso es un alivio.

Los signos de subrayado son caracteres, mientras que los guiones pueden interpretarse como menos, por lo que ese es otro problema potencial: tiene sentido quedarse con los guiones bajos solamente. Flex, por ejemplo, no acepta XML con atributos nombrados con guiones (sé que estos son valores, no atributos, pero aún así una apuesta segura).

Sin embargo, estoy de acuerdo con lo anterior - no hay tipos de elementos ni posicionamiento o color como clase/id. Notación húngara == malo. Muy útil para determinar qué es una identificación. Me gusta nombrar los campos de formulario en formas específicas de objeto: user_login, user_email, user_address_state_id, user_address_country_id etc., todos pueden aparecer en un formulario de registro de usuario. Por lo general, los campos sin formato no son lo suficientemente largos como para subrayar; de lo contrario, es posible que pueda cambiarles el nombre.

Answer 5

Lo creas o no, pero he tenido problemas con los guiones como nombres de los nombres de clase id y css cuando utilizo ciertas bibliotecas de JavaScript. Esto es muy raro, pero obviamente quieres evitar algo como esto. Debido a esto uso una caja de camello o guiones bajos. Puede usar guiones bajos también.

De lo contrario, la regla general es tener nombres significativos que sean fáciles de leer y comprender. Cuando se trata de "controles", asegúrese de seguir algún tipo de convención de nomenclatura. Personalmente prefiero postfixes sobre prefijos (es decir, nameText en lugar de textName), pero trato de evitar los postfixes, ya que los encuentro demasiado detallados.

Así: 1. Nombres significativos. 2. Evita el post/prefijo. 3. Evite las abreviaturas (es decir, dirección en lugar de addr). 4. Tómese su tiempo.