I with 2 other friends are new to web development. We are learning HTML, CSS, Javascript and are creating simple websites to get a feel of different things. And as HTML is only a markup and not a programming language we have very different styles evolving. I mean whenever we look at each other's code, we tend to put a good amount of time in understanding why the other one does that.

Now we want to build a larger website together and my question is- Is that a problem having very different styles in a team for web development(specifically)?

You give an answer in your question : " I mean whenever we look at each other's code, we tend to put a good amount of time in understanding why the other one does that". So yes, it is surely a problem :)
–
ereOnFeb 27 '12 at 7:48

6 Answers
6

It is part of an HTML author’s competence to be able to read HTML markup written in different styles (e.g., nesting, uppercase ~ lowercase, quotes around attribute values).

In a large project it may well be useful to decide on such matters. More importantly, decisions are needed on higher-level issues such as the use of tags, naming of id and class attributes, the use of external stylesheets and scripts vs. embedded styles and scripts, and conformance to HTML specs (HTML 4.01 ~ XHTML 1.0 ~ HTML5 ~ something else).

"It is part of a team member's competence to be able to write HTML markup in consistent style and manner as the rest of the team."
–
Jarrod RobersonFeb 24 '12 at 19:37

@ErikReppen, your comment looks like your answer rather than a comment on mine. Anyway, it is not consistent: you cannot be minimal and stylistically consistent at the same time. The attribute class=foo is minimal, but not consistent with class="foo bar" (or class='foo bar'), where the quotation marks are required.
–
Jukka K. KorpelaOct 17 '13 at 6:54

If you're going to be regularly working on each other's code, you're going to need to be able to read it. Other people might even need to read it.

You can learn to read different code styles, but the problem emerges when you have to switch mindsets when you're looking at different sections of code. There's a very noticeable cost involved in this switch. Sometimes it's unavoidable, like switching from reading a Functional lang to reading Object Oriented code, but when you have to switch how you read just to read random pages of your site's code, it adds up fast.

If you both need to work on each other's code regularly, that cost is going to add up, and you're probably going to get into some discussions regarding code style: "Why the %$^% are you doing that?"

Additionally it is important that even if all your HTML pages are separate and don't need to be consistent in how the use IDs, classes ect, your CSS and your backend do need consistency. For your CSS to make sense you need to work out how you're going to use classes vs IDs and your naming for elements. Your forms are going to need some standards because the variable names you use for your forms go back into the server layer, and they need to map well to database inputs where relevant.

I also certainly wouldn't discard the notion of readable code since it's a markup language rather than a programming language; if anything it matters more in markup because your code isn't compiled, and non-semantic markup might actually display improperly or have accessibility issues.

There is only one place where server-side and all client-side concerns meet and that is the HTML. It should be the most pristine, cleanest, most consistent and coal-crushed-to-diamonds-in-mere-minutes anally retentive portion of every web app.

Imagine grabbing and restructuring a string from innerHTML. How much easier is it when you know it will always be double-quotes on every attribute and every singular-style element will have that closing '/' ? When it's a late-night and you're trying to walk through some code how helpful is it to be able to easily separate ids and classes that have an underscore or dash convention from traditionally camel-cased property and var names?

And really, how much easier is it to simply read HTML when everything follows the same conventions.

It's not hard to keep HTML clean and consistent and there are too many wins not to. Server-side devs that treat the HTML as a disposable means to an end aren't understanding the web app from a holistic perspective IMO. And their code is usually sloppy too.

this is an issue within our team, where there are two different html developers who have different coding styles, but we do not force on them anything specific, so that they can work efficiently and happily. And we have never experienced a problem where the two are completely unable to understand each other's html.

The same is true for any style of programming.

Basically you just need to have special considerations on "documenting the code". And everything will be good to go.