Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Your code style guide is crap, but still better than nothing.

tech.matchfwd.com

Post reply on HN
Print view View original

11–20 of 49 posts

Re: Your code style guide is crap, but still better than nothing.

#12

Post by caipre »

nakkiel wrote: post #6
webreac wrote: post #5

Earlier quoted context omitted.

I do not understand why there seem to be so much agreement on 80 characters line length. I often use 132 character. I have a rule that invite to avoid abbreviations in identifiers and I have often 4 spaces. If I limit to 80 character, all the line breaks decrease significantly readability.

Code is just like literature. Too many words on a line and it looses the reader. All of this indeed depends on the density of the language you're using. If your're using extremelyLongVariableNames it may be ok to use 132 characters per lines but if you use shorter var_names, 80 characters is plenty of room to express yourself^W^Wwrite code. Also, unix. Stop arguing about religion.

I understand the readability argument for literature, where lines of text are left-justified. In code though, indentation is much more prevalent. Between indentation and alignment, some lines of code are unsettlingly clipped to a small fraction of the available 80 characters.

I still recommend wrapping at 80 chars though.

Re: Your code style guide is crap, but still better than nothing.

#14

Post by Cacti »

80 columns exists for the same reason newspaper columns are about 2 inches and a novel is about 10-15 words wide---that is a width in which the human eye and brain can ready and fficiently absorb the information. Lines longer than 80 chars may be fine at times but they are generally a bad idea. Usually it's better to break the line up in some manner.

Re: Your code style guide is crap, but still better than nothing.

#16

Post by pavel_lishin »

> tabs reduce storage, bandwidth, and I/O, three items that are important over weak links like 3G and on embedded devices with limited capacity and speed like my mobile phone.

Between minifying your css and js, and gzip compression, I doubt that tabs save you a significant amount of bandwidth when you're on your phone.

And how often are you working on code where using tabs instead of spaces seriously impacts your storage and I/O?

Re: Your code style guide is crap, but still better than nothing.

#17

Post by msutherl »

The tabs vs. spaces debate makes me very sad. I get it, big companies use spaces because interns are stupid and don't understand how tabs work. And some people monomaniacally want their code to look exactly the same everywhere.

But I wish it could just be acknowledged somewhere that, if you know what you're doing, tabs are better and have no downsides (except that you can't control how other people see your code).

Caveat: I really mean tabs + spaces for complicated formatting beyond the indent level of the current line.

Regarding 80 character width, I'm often coding on my laptop and I really appreciate it when code is kept within those bounds as it allows me to vertically tile 3 files without line-breaks. Also, I find that it forces me to write more succinctly. 'One idea per line' is a good idea and 80 characters is a good arbitrary limitation that helps me achieve that.

Re: Your code style guide is crap, but still better than nothing.

#18

Post by Ensorceled »

I find it ironic that the author says:

  Why, in the name of all that is holy, do our modern style
  guides still force us to manually wrap text to fit within
  80 columns? (That’s four and a half vertical splits of 80
  columns each on my monitor!)
but chooses a blog template that holds the width constant at 1000px. Perhaps there is a reason not to grow without bound horizontally?

I use 80 characters because it's just easier to read than 120 char lines. Plus, I rarely need to break lines anyway, even at 80 chars ... what the heck are you writing that needs to be 120 chars wide?

Also, I have 2 screens with 4 work areas (each half a screen):

* mvim (at 90 chars wide)

* two terminals

* browser

* developer tools

At 120 chars lines, mvim now needs to be 125/130 chars wide and require it's own dedicated monitor.

Re: Your code style guide is crap, but still better than nothing.

#20

Post by pavel_lishin »

msutherl wrote: post #17

The tabs vs. spaces debate makes me very sad. I get it, big companies use spaces because interns are stupid and don't understand how tabs work. And some people monomaniacally want their code to look exactly the same everywhere. But I wish it could just be acknowledged somewhere that, if you know what you're doing, tabs are better and have no downsides (except that you can't control how other people see your code). Ca…

I'm a convert to spaces after someone pointed out that it's easier to make your code 'pretty'.

    // This doesn't look very nice
    thing = { some_key_1: some_var_1,
    [->][->][->]some_key_2: some_var_2,
    [->][->][->]some_key_3: some_var_3 }
    
    // Neither does this.
    thing = { some_key_1: some_var_1,
    [->][->]some_key_2: some_var_2,
    [->][->]some_key_3: some_var_3 }
    
    // Feels good, man.
    thing = { some_key_1: some_var_1,
              some_key_2: some_var_2,
              some_key_3: some_var_3 }
    
    // I want to beat you with an oar.
    thing = { some_key_1: some_var_1,
    [->][->]  some_key_2: some_var_2,
    [->][->]  some_key_3: some_var_3 }
Post reply on HN