Live data from Hacker News

Code Standards & Front-end Development Best Practices

na.isobar.com

11–20 of 28 posts

Re: Code Standards & Front-end Development Best Practices

#11

The difficulty with such "standards" and "best practices" is that what is standard can often be subjective. For example, under Indentation, they have: For all code languages, we require indentation to be done via soft tabs (using the space character). Hitting Tab in your text editor shall be equivalent to four spaces. Umm, who died and made you king? I don't like using 4 spaces. I find it a waste of space, literally.…

Count your blessings that you work in a language that doesn't have ambiguity around indentation rules. These poor fellas obviously don't.

Re: Code Standards & Front-end Development Best Practices

#14

Let's take a vote. All in favor of never using the term 'Best Practices' ever, ever, again? (no offense to the article's author.. actually looks really lucid and well written. I just tire of the idea that Best Practices™ exist. They don't.)

So what you're saying is "Best Practices Considered Harmful"?

Re: Code Standards & Front-end Development Best Practices

#16

The difficulty with such "standards" and "best practices" is that what is standard can often be subjective. For example, under Indentation, they have: For all code languages, we require indentation to be done via soft tabs (using the space character). Hitting Tab in your text editor shall be equivalent to four spaces. Umm, who died and made you king? I don't like using 4 spaces. I find it a waste of space, literally.…

I agree. I personally like 8 spaces, but I code in a way so others can choose their own preferences. Meaning, I use the tab character and avoid ASCII art in my source / comments. This way people can set up their tab width in their editor as they like and don't have to put up with my style de jure.

That's part of collaboration basics:

* Try to find an acceptable middle ground for the minor things and focus on coding and not politics.

* Don't be a douche.

~2¢

Re: Code Standards & Front-end Development Best Practices

#17
post #3

Earlier quoted context omitted.

But they have a standard, and this is good for consistency across their development. What may be better is "follow the standard that you are working on", meaning, don't change coding style because you prefer your own, adopt what is already there, or the norms for a project (e.g. 2 space indents for all that Ruby code we have).

Agreed. Maintaining consistency is key.

On that note, I like the parting words in Google's JavaScript Style Guide ( http://google-styleguide.googlecode.com/svn/trunk/javascript... ):

BE CONSISTENT.

If you're editing code, take a few minutes to look at the code around you and determine its style. If they use spaces around all their arithmetic operators, you should too. If their comments have little boxes of hash marks around them, make your comments have little boxes of hash marks around them too.

The point of having style guidelines is to have a common vocabulary of coding so people can concentrate on what you're saying rather than on how you're saying it. We present global style rules here so people know the vocabulary, but local style is also important. If code you add to a file looks drastically different from the existing code around it, it throws readers out of their rhythm when they go to read it. Avoid this.

Re: Code Standards & Front-end Development Best Practices

#18
I gave up on IE a long time ago. If they don't support the standards, I don't support them.

Of course my pages still render on IE, but I don't do any quirks mode stuff, that just causes too much pain.

Oh, well, that's not strictly true, since I have to have two different things in the CSS for rounded corners (webkit vs mozilla), but apart from that I try to keep quirks to a minimum, and IE can go die in a fire for all I care.

Re: Code Standards & Front-end Development Best Practices

#19

The W3C HTML validator gives up after the second line of the document: http://validator.w3.org/check?uri=http%3A%2F%2Fna.isobar.com...

Here's the source:

   
   
   
  
  Code Standards | Isobar 
   
   
   



  

I see a couple of problems. First up, they're not indenting. The validator is spitting the dummy because of two things, the first is the spurious whitespace before the doctype tag, the second is the title (which it thinks is missing), but the real problem is with the meta tag which isn't properly closed.

But hey, free dinosaur. With hat.

Post reply on HN