¿Es un problema tener diferentes estilos de codificación HTML dentro del equipo?

7

Yo con otros 2 amigos son nuevos en el desarrollo web. Estamos aprendiendo HTML, CSS, Javascript y estamos creando sitios web simples para tener una idea de cosas diferentes. Y como HTML es solo un marcado y no un lenguaje de programación, tenemos estilos muy diferentes en evolución. Quiero decir que cada vez que miramos el código del otro, tendemos a dedicar una buena cantidad de tiempo a comprender por qué el otro hace eso.

Ahora queremos construir un sitio web más grande juntos y mi pregunta es: ¿es un problema tener estilos muy diferentes en un equipo para desarrollo web (específicamente)?

    
pregunta carambir 24.02.2012 - 10:11

6 respuestas

5

Es parte de la competencia de un autor de HTML poder leer el marcado HTML escrito en diferentes estilos (por ejemplo, anidamiento, mayúsculas ~ minúsculas, comillas alrededor de los valores de los atributos).

En un proyecto grande puede ser útil decidir sobre estos asuntos. Más importante aún, se necesitan decisiones sobre problemas de nivel superior, como el uso de etiquetas, la denominación de atributos de id y clase, el uso de hojas de estilo y scripts externos en comparación con los estilos y scripts incrustados, y el cumplimiento de las especificaciones HTML (HTML 4.01 ~ XHTML 1.0 ~ HTML5 ~ algo más).

    
respondido por el Jukka K. Korpela 24.02.2012 - 10:20
16

Todavía necesitas mantener HTML / CSS. Como dices:

  

tendemos a dedicar una buena cantidad de tiempo a comprender por qué el otro hace eso

El hecho de que esté marcado no significa que deba ignorar las buenas prácticas de trabajo en equipo.

Si estandariza cómo hacer las cosas, esa carga de mantenimiento se reducirá significativamente.

    
respondido por el Oded 24.02.2012 - 10:19
2

Si vas a estar trabajando regularmente en el código del otro, necesitarás poder leerlo. Otras personas pueden incluso necesitar leerlo.

Puedes aprender a leer diferentes estilos de código, pero el problema surge cuando tienes que cambiar la mentalidad cuando miras diferentes secciones de código. Hay un costo muy notable involucrado en este cambio . A veces es inevitable, como pasar de leer un idioma funcional a leer código orientado a objetos, pero cuando tiene que cambiar la forma de leer solo para leer páginas aleatorias del código de su sitio, se acumula rápidamente.

Si ambos necesitan trabajar en el código del otro con regularidad, ese costo se sumará, y probablemente entrará en algunas discusiones sobre el estilo del código: "¿Por qué% $ ^% estás haciendo que ? "

Además, es importante que incluso si todas sus páginas HTML están separadas y no necesitan ser coherentes en la forma en que los ID de uso, las clases, etc., su CSS y su backend hacen consistencia . Para que su CSS tenga sentido, debe averiguar cómo va a utilizar las clases frente a los ID y su nombre para los elementos. Sus formularios necesitarán algunos estándares porque los nombres de las variables que usa para sus formularios regresan a la capa del servidor y deben asignarse bien a las entradas de la base de datos cuando sea relevante.

Ciertamente, tampoco descartaría la noción de código legible ya que es un lenguaje de marcado en lugar de un lenguaje de programación; si importa algo, más en el marcado porque su código no está compilado, y el marcado no semántico podría mostrarse incorrectamente o tener problemas de accesibilidad.

    
respondido por el Ben Brocka 24.02.2012 - 16:28
0

Solo hay un lugar donde se reúnen las preocupaciones del lado del servidor y del lado del cliente, y es el HTML. Debería ser la parte más limpia, limpia, consistente y aplastada de carbón para hacer diamantes en tan solo unos minutos, de forma retentiva de todas las aplicaciones web.

Imagina que agarras y reestructuras una cadena desde innerHTML. ¿Cuánto más fácil es cuando sabes que siempre habrá comillas dobles en cada atributo y cada elemento de estilo singular tendrá ese cierre '/'? Cuando es tarde en la noche y está intentando revisar un código, ¿qué tan útil es poder separar fácilmente las identificaciones y las clases que tienen una convención de guión bajo o guión de la propiedad tradicionalmente en camello y los nombres var?

Y realmente, cuánto más fácil es simplemente leer HTML cuando todo sigue las mismas convenciones.

No es difícil mantener el HTML limpio y consistente, y hay demasiadas victorias para no hacerlo. Los desarrolladores del lado del servidor que tratan el HTML como un medio disponible para un fin no están entendiendo la aplicación web desde una perspectiva holística de la OMI. Y su código también suele ser descuidado.

    
respondido por el Erik Reppen 17.10.2013 - 09:04
-1

este es un problema dentro de nuestro equipo, donde hay dos desarrolladores html diferentes que tienen diferentes estilos de codificación, pero no les imponemos nada específico, para que puedan trabajar de manera eficiente y feliz. Y nunca hemos experimentado un problema donde los dos son completamente incapaces de entender el html del otro.

Lo mismo es cierto para cualquier estilo de programación.

Básicamente, solo necesitas tener consideraciones especiales sobre "documentar el código". Y todo estará bien para ir.

    
respondido por el Shaheer 24.02.2012 - 11:56
-1

No me obsesionaría demasiado, especialmente con HTML.

He trabajado en muchos lugares con estándares de codificación, y nunca se han respetado de forma rígida.

Eso no quiere decir que no esté de acuerdo con tenerlos así, solo que con el tiempo, a menos que se apliquen estrictamente, la gente pronto se apartará de ellos.

    
respondido por el ozz 24.02.2012 - 16:16

Lea otras preguntas en las etiquetas