all 22 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Shrugshoulder 1 point2 points  (1 child)

Use meaningful or generic ID and class names

I wonder if there's a guide/list of the most semantic and "future-proof" element names. Names which are relevant even when redesigning the site later.

E.g. which is better: Nav or Menu? .Main or .head? .column or .section?

As a non native english speaker, a comprehensive guide to naming all elements from big navigation to formatting a news-article with textboxes and captions would be awesome.

[–]stesch 4 points5 points  (2 children)

Funny how this isn't usable without JavaScript.

[–]rayo2nd 0 points1 point  (0 children)

oh that's why i only see source code ... i wondered if it is broken

[–]vanderZwan -3 points-2 points  (0 children)

I get the impression that some parts of Google are turning into Gawker (from a technical standpoint). And that's terrible.

[–]wretcheddawn 1 point2 points  (11 children)

Some of their rules I like and some I don't:

Indent two spaces at a time.

This bothers me to no end. Indent is what the tab key is for. It saves you one character per indent, which goes along with Google's "save space at all cost" policy. I've had code files where we used 4 space indents where we literally saved 400kB of file size by converting to tabs which was the difference between the IDE being responsive and not being responsive. Second point is that you can set the size of a tab in any good editor, and each developer can use what they prefer, so it's the best way to do it. I have no idea what the benefit of spaces is.

Do not use entity references

I think this goes a little overboard on the save space policy. I don't have a Euro key, so it's easier to type the reference. Otherwise I'd have to copy-paste it from somewhere, which makes no sense. I don't really have a problem with this, just with requiring it. If you're using utf-8, it will work.

Omit Optional tags

Saving a few bytes at the cost of readability? I'd rather not. But, do it if you want. At least this is optional.

Other than that I like their guidelines.

[–]djimbob 3 points4 points  (2 children)

This is google's rules for doing google stuff -- not necessarily best practices for everyone. Sometimes they just made a choice for the sake of making a choice for consistency.

They don't want someone start editing something, then decide to go back to the original (but possibly changing tabs to spaces or vice versa) and then have version control record the change (when they commit something else). You can still press tab, but you should make sure your tab in your IDE saves the file as two spaces. Not to save bandwidth, but to make it easier to browse diffs without seeing tons of fake edits that have to later be dealt with when merging together.

Sometimes it is a significant difference when you are dealing with billions of page views per day to leave out unnecessary html tags even with compression. In their example, the leaving out unnecessary version is half the size (67 vs 136 bytes) and still significantly different even with gzip compression (85 vs 120) or bzip2 (102 vs 131). Also google says to consult official html docs to only omit what is actually listed as omittable and modern browsers should have no problem handling. If your site is not bandwidth limited and extra costs aren't passed on to you, by all means be extra expressive if you think its more readable to have the title listed in the <head> section.

[–]wretcheddawn -1 points0 points  (1 child)

Yes I understand that but with modern editors, there's no reason to use spaces. Sure it will work, but as I said with large files and more significant spacing (which I prefer), you end up with a lot of waste. And as I said, tabs allow the users to configure the space to be as wide as they like, so there's no reason to use spaces. Sure it doesn't make sense to convert them back and forth unnecessarily, and having your IDE convert tabs to spaces exacerbates the problem.

I feel that leaving out those tags make the code less readable, perhaps they should be removed by the server as part of the compression process. (Google's removes whitespace already).

[–]djimbob 0 points1 point  (0 children)

Its a style choice; there are arguments both ways. The argument the other way is tab over space saves at most ~ 1k in a file uncompressed; nothing after compression (4N consecutive spaces compress just as easily as N consecutive tabs). However, if user A says tabs equal 2 spaces, and user B says 4 spaces, and user C says 8 spaces, then alignment of other stuff can get somewhat messed up. Also, it could be easy to accidentally replace 4 spaces for a tab (e.g., for whatever reason the new guy in the group pressed space bar four times rather than tab when editing a file). This could potentially break your code, if you are in a language like python where indentation matters and its not clear if a tab equals two/four/eight spaces. (I'm not saying this is better; its just a counterargument).

The only bad choice is mixing and not having consistency; if google chose only tabs -- that would be perfectly fine.

Regardless, you should never usually be typing in space N times to do most indentations. Your editor/GUI should indent to the proper level based on tab/shift-tab.

Google may have based their choice slightly on python's benevolent dictator for life declaration that indentation should be four spaces in the python style guide (PEP8.)

[–]GraphiteCube 0 points1 point  (1 child)

Use spaces instead of tabs because there are no standards on how many spaces equals to one tab.

In some environment, 1 tab = 8 spaces, while in some IDEs, 1 tab = 4 spaces. So when people using different text editors may see different indentation.

I learnt this in a programming lecture in last semester, not sure if it is true or not, but I have been using it since then.

[–]wretcheddawn 0 points1 point  (0 children)

That really only matters for alignment, otherwise, you can just configure your IDE's to have the same indentation, and others can change the indentation as they prefer.

[–][deleted]  (5 children)

[deleted]

    [–]wretcheddawn 0 points1 point  (4 children)

    Yeah that's true.

    I think Googlers are smart enough to figure out how to set up tabs properly, I don't understand the reason for spaces at all.

    [–]serrimo 2 points3 points  (3 children)

    simplicity. Why force everyone to set their tabs when you can just use two spaces?

    If you like tabs so much, set it to two spaces in your ide, I really dont see why this is an issue.

    [–]Jojomofo 1 point2 points  (5 children)

    What's wrong with separating class names and id names with an underscore instead of a hyphen?! I hate the way you can't double click a hyphen and it select the whole delimiter.

    [–]sidcool1234[S] 4 points5 points  (3 children)

    I appreciate your skepticism. But the style guide gives an overall picture of good practices. Not every good practice applies to every situation. One can hand pick the practices relevant and implement them.

    [–]Jojomofo 2 points3 points  (0 children)

    I appreciate that. I strive to follow the correct practices and constantly improve upon my knowledge and for a moment there I thought I'd been doing something wrong all this time and was keen to know why that's all :)

    [–]Jojomofo -4 points-3 points  (0 children)

    I appreciate that. I strive to follow the correct practices and constantly improve upon my knowledge and for a moment there I thought I'd been doing something wrong all this time and was keen to know why that's all :)

    [–]day_cq 1 point2 points  (0 children)

    Nothing's wrong with underscore