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

21–30 of 49 posts

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

#21

Post by Shivetya »

webreac wrote: post #5
antihero wrote: post #3

80 character line length increases readability, and four spaces means that this is consistent everywhere. If you have a tab character and someone sets things to like, two spaces, their line is going to be a dynamic length and it's going to shit up the code. PEP-8 looks fantastic, works, and leads to consistency across all Python code. Unless you are using a shitty IDE/editor, adhering to it is totally easy and comple…

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.

80 column punch cards are at times implied as the reason for 80 column displays. There are just some solutions that stick.

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

#22

Post by mje__ »

pc86 wrote: post #7
gav wrote: post #2

Fun fact: the VT-100 supported a 132-column display. Anyway, there's a lot of advantages of trying to keep lines <= 78 columns wide. I don't make it a hard-and-fast rule, but usually overly long line is a sign that something's not right with the code and some refactoring is in order.

Why is a ~130-column line of code necessary a bad thing? I'm not saying it's good and that we should shoot for any specific number, but I don't see why shorter necessarily means better. Disclaimer: I've been doing this for all of ~5 years so I have no experience with older terminal-style programming.

Also, tools other than text editors - especially those designed to show code side-by-side like web-based code review tools (), etc become much harder to use when you have long lines.

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

#23

Post by TallGuyShort »

pavel_lishin wrote: post #20
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:…

Another tabs-only approach is to also add a single tab before some_key_1.

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

#24

Post by DanBC »

pavel_lishin wrote: post #20
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:…

Watch out or you'll get

    // 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 }

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

#25

Post by martinced »

npsimons wrote: post #4

I closed the tab at the "Line Length" header; yet another person who Doesn't Get It, and proudly refuses to. There's a reason besides technical limitations (which in reality, didn't exist) that columns are best set to be no longer than 80 characters. Just as a hint, would you like to dump all your code into a single function in one file? No? Didn't think so. Edit: I lied, I kept reading. Oh, why did I do that. Tabs i…

Same here.

80 columns-wide have another huge advantage: 3-ways merge fitting on one screen.

Even with "only" 100 columns wide it's hard to do a three-ways merge side-by-side without wrapping on a 1920x1200 screen (I basically have to temporarily use a smaller font to be able to do my three-ways merge).

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

#26

Post by whatshisface »

Ensorceled wrote: post #18

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 easie…

>what the heck are you writing that needs to be 120 chars wide?

Ever used java?

private static final Map, PersistentHelper> class2helper = new HashMap, PersistentHelper>();

if ((string1.toLowerCase().equals(Localization.getString('Yes')) || string1.toLowerCase().equals('yes')) && Cleaning.Verifier.isSafeInput(string2) && Cleaning.Verifier.isSafeInput(string3))

The first one I found on google, the second one is based on something one would normally expect to find in an average java codebase.

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

#27

Post by JensenDied »

pavel_lishin wrote: post #20
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:…

Use tabs to align stuff on the left. This means putting some_key_1 on the next line. Also move the closing brace to a new line and add a comma after some_var_3.

Added advantage that you can move all of the lines around, :sort them or comment out individual ones without breaking anything.

Use spaces to align anything after the key, I usually align them with a tab stop so that several blocks line up.

  thing = {
  [->]some_key_1: some_var_1,
  [->]some_key_2: some_var_2,
  [->]some_key_3: some_var_3,
  }

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

#29

Post by mrkodiak »

pavel_lishin wrote: post #20
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:…

When working on code bases that follow this style, there tends to be extra whitespace turn when new code is added to re-align everything back up.

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

#30

Post by mwill »

npsimons wrote: post #4

I closed the tab at the "Line Length" header; yet another person who Doesn't Get It, and proudly refuses to. There's a reason besides technical limitations (which in reality, didn't exist) that columns are best set to be no longer than 80 characters. Just as a hint, would you like to dump all your code into a single function in one file? No? Didn't think so. Edit: I lied, I kept reading. Oh, why did I do that. Tabs i…

My main display + editor, I use in two modes, 273 columns wide, or up to 410, both of which I feel comfortable with.

I'm guilty! I'll admit, When I know it's my-eyes-only, in languages with functional features, I tend to just brain-dump one liners if I 'see' them in my mind as one sequence of operations. It's easier for me to write, and much easier to read and parse later than multi line equivalent.

But I l also know that outside of private junk, this sort of thing is usually inappropriate, and downright harmful on teams with varying skillsets, where these lines can be impenetrable to some team members, and make the codebase far more intimidating than it needs to be. I segment and format anything above ~80 if anyone else is going to be involved.

So coming from someone who would violate almost any line length rule if no one was looking: I feel like a line length is appropriate in a style guide, or at the bare minimum a consensus on how much is too much.

Post reply on HN