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

31–40 of 49 posts

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

#31

Post by Ensorceled »

whatshisface wrote: post #26
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 base…

True with Java/ObjC you get very view verbs/nouns in the same "sentence" length.

But ObjC and Java developers also have the habit of writing long undebuggable sentences like:

response = object.veryLongMethodName(object2,object3).anotherLongMethodName().yetAnotherLongMethodName(object4)

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

#32

Post by beatgammit »

alanctgardner2 wrote: post #8
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…

Maybe I`m biased because I write C on a daily basis, and only noodle around with Python occasionally: - Having a standard line length is awesome. I can fit 3 80x4 terminals on my 1920x1080 screen, and I never have worry about anything overflowing or wrapping. You could pick a different length, if you`d like, but 80 is convenient. - I`ve seen the `you can set tabs to whatever you want` argument before. It`s obviously…

Not trying to start a flame war, but I am on the tabs side of the discussion. Most companies have rules about tabs/spaces (we use spaces, much to my chagrin), and it's pretty easy to set a rule.

I code in Go a lot now, and Go ships with gofmt, which formats your code for you (uses tabs by default). There are similar tools for every language I've used. This can be set in a pre-commit hook (or whatever the terminology is for non-git scms), so it's not really an issue. We do this, and it works like a champ.

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

#33

Post by amcgregor »

alanctgardner2 wrote: post #8
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…

Maybe I`m biased because I write C on a daily basis, and only noodle around with Python occasionally: - Having a standard line length is awesome. I can fit 3 80x4 terminals on my 1920x1080 screen, and I never have worry about anything overflowing or wrapping. You could pick a different length, if you`d like, but 80 is convenient. - I`ve seen the `you can set tabs to whatever you want` argument before. It`s obviously…

If your developers are pressing space four times instead of the tab (key), and the editors aren't capable of reasonable wrapping policies, you should probably replace either the editors they are using… or them. The key point of my article is that we have software to do all of this stuff for us. Hitting three more keys than necessary to indent is the fast road to carpel-tunnel and surely not the best use of developer time.

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

#34

Post by amcgregor »

beatgammit wrote: post #32
alanctgardner2 wrote: post #8

Earlier quoted context omitted.

Maybe I`m biased because I write C on a daily basis, and only noodle around with Python occasionally: - Having a standard line length is awesome. I can fit 3 80x4 terminals on my 1920x1080 screen, and I never have worry about anything overflowing or wrapping. You could pick a different length, if you`d like, but 80 is convenient. - I`ve seen the `you can set tabs to whatever you want` argument before. It`s obviously…

Not trying to start a flame war, but I am on the tabs side of the discussion. Most companies have rules about tabs/spaces (we use spaces, much to my chagrin), and it's pretty easy to set a rule. I code in Go a lot now, and Go ships with gofmt, which formats your code for you (uses tabs by default). There are similar tools for every language I've used. This can be set in a pre-commit hook (or whatever the terminology…

Automation is a very nice thing. We, too, use Git hooks to run a wide array of checks and cleanup routines. The base that we use is from my hooks collection: https://github.com/amcgregor/snippits/blob/hooks/pre-commit-...

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

#35

Post by amcgregor »

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…

Tabs not simply because it "looks better", but because it offers me the choice. Unfortunately, like most arguments on this subject, you have brought no logical counter-arguments to the table… just personal attacks (I never feel bad ;) and a false dichotomy of collapsing large codebases into a single file. That is, I'm sorry to say, not a very good argument.

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

#36

Post by amcgregor »

martinced wrote: post #25
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).

I often use splits on my editors, and with 329 columns in my editor (with side-bar open) there is plenty of room. Fairly recently I was working with five simultaneous vertical splits and had no difficulty; my editor soft wrapped the few panes I wanted wrapped quite smoothly and without making the code any uglier or harder to read. While I do not agree with hard wrapping, in general, I still try to avoid run-on lines in my code, and in Python a newline is a statement separator so it's actually pretty hard to have run-on statements. (Literal definitions like lists and dictionaries can run-on, but I tend to hard wrap for SCM reasons.)

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

#37

Post by amcgregor »

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

I use an alternate form that doesn't require alignment to an arbitrary column and works with tab indentation without needing to mix:

  thing = {
  [→][→]some_key_1: some_var_1,
  [→][→]some_key_2: some_var_2,
  [→][→]some_key_3: some_var_3,
  [→]}
Several benefits: easier to insert lines at the head or tail without making the SCM diff ugly, also avoids merge conflicts in those cases, and I use indentation of two levels to separate it from code.

Why suffer a problem when it's easily avoided? :)

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

#38

Post by amcgregor »

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…

Python is one-statement-per-line, which is already a pretty good limiter of line length. Just don't go crazy with ternary operators (which are hard to read anyway and thus against the Zen for more than the trivial cases) or literal definitions.

My FOSS libraries follow a 120-character wrapping limit and avoids alignment, but otherwise follows PEP-8. The main reason it was upped was the stupid arbitrary wrapping of lines that were only a few characters over the limit.

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

#39

Post by amcgregor »

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…

The design of the blog is not under my control; if it was, it'd be a lot more flexible. (Responsive design FTW.)

The lines that are 81 characters long benefit greatly from the increase to 120 characters. That was the primary reason for increasing the limit beyond PEP-8's default 80 in my FOSS codebases. There were far too many lines whose wrapping was clearly stupid, and too much developer time spent worrying about it.

I have 4 screens (2@1024x768, 1@2560x1440, 1@1280x800) and frequently utilize multi-column splits. I only turn soft-wrapping on when I need it, which is almost never. If I were utilizing your setup I wouldn't enable it on your mvim display; <2% of the lines in any of the codebases I work on exceed 90 characters.

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

#40

Post by amcgregor »

pavel_lishin wrote: post #16

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

How often? Daily; I use my phone and iPad while I'm mobile, out having a smoke, or whatever. At home I use my iPad more than my laptop.

You don't keep your source code in a minified state, nor do you keep it gzipped; the storage/bandwidth/IO considerations are for SCM-tracked code where there are potentially many, many copies of the same file in different states.

If you could reduce a 34-line (1KB) diff by 20% (average of two indentation levels of four spaces each across those lines), why wouldn't you?

Post reply on HN