41–49 of 49 posts
His argument about size is undermined by the fact files are compressed before going across a network. Blocks of spaces can easily be condensed into a single character.
> 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% (avera…
I also do not access my code on a mobile device.
And I wouldn't reduce it because I have 122 gigabytes of space free on my machine, and absolutely do not care about saving 200 bytes worth of space, even considering it's per commit.
After all, you could reduce your code by even more by minifying it before adding it to your SCM, right? (I know, I know, if you take out line-breaks, diffs will become unreadable).
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…
Earlier quoted context omitted.
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% (avera…
I do not keep my code in a minified state, but we do minify it before serving it on the web. I also do not access my code on a mobile device. And I wouldn't reduce it because I have 122 gigabytes of space free on my machine, and absolutely do not care about saving 200 bytes worth of space, even considering it's per commit. After all, you could reduce your code by even more by minifying it before adding it to your SCM…
Saying you don't conform to a use case does not invalidate said use case.
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 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.
Unfortunately, we don't all get to choose who we work with or that they use a decent editor, and either one or the other are usually lacking, therefore: no tabs, only spaces. Also, if you have a line of code longer than 80 characters, consider that that's an indication that it's too complex, and not so much that it's breaking some arbitrary line length rule. Does a function really need more than three arguments? Why not put them each on a line for better readability? Do you really need to put 15 operations on one line, when the compiler can inline them for you, and you can give more meaningful names to constant temporary variables?
As for putting all code in one function (or even one file), I thought it was fairly obvious: you can make things hard to read by using too long a line of code, just as you can make things hard to read by dumping them all in one unbroken file (line after line with no reuse and no compartmentalization of functionality).
His argument about size is undermined by the fact files are compressed before going across a network. Blocks of spaces can easily be condensed into a single character.
But not disk, flash, or RAM. And network transfers are not always compressed, say, if synchronizing with a WebDAV back-end with naive client software. (The vast majority of iOS WebDAV implementations suck badly in this regard.)
Client-server communication software can improve over time, or be replaced by better software. Picking a style based on technical limitations that will be superseded anyway is surely what you're arguing against?
As a more general point, using spaces instead of tabs can still be handled easily by IDEs. It's possible to recognise that something is supposed to be an "indent", and then space it according to what your preferences are. Whether any current IDEs do that, I don't know.
Earlier quoted context omitted.
But not disk, flash, or RAM. And network transfers are not always compressed, say, if synchronizing with a WebDAV back-end with naive client software. (The vast majority of iOS WebDAV implementations suck badly in this regard.)
I don't think disk, flash or RAM are huge concerns for anything but huge files, to be honest. Client-server communication software can improve over time, or be replaced by better software. Picking a style based on technical limitations that will be superseded anyway is surely what you're arguing against? As a more general point, using spaces instead of tabs can still be handled easily by IDEs. It's possible to recogn…
I picked tab-based indentation because of the flexibility it gives me and anyone else reading the code. Savings elsewhere are icing on the cake.
IDEs can automate bad behaviour as well as good, and yet spaces remain intra-word separators and tabs remain the character designed for indentation and alignment.