amcgregor

Disk, flash, or RAM are concerns any time you have many copies of the files. One large file or millions of small ones, it adds up either way!

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.

With no downsides to using tabs over spaces, and wanting to preserve readable SCM diffs, saving 20% of the space for such diffs just happens to be a nice side benefit, not the primary one. (The primary one being flexibility in presentation.)

Saying you don't conform to a use case does not invalidate said use case.

Oh, forgot to mention: you can embed in source files editor instructions (between -*- for emacs, something I can't remember for vim) that specify a default presentation format.

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.)

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?

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.

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.

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? :)

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.)

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.

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.

Convienently, the solution I wrote allows you to utilize two or as many templates as you want, add and remove to the directory as you wish. For us, setting off a handful of template options for two weeks then seeing which one has higher conversion is extremely simple (no need for 'reward' function as such) and effective (it's a fair distribution across the options). We explicitly wanted to avoid needing to track the number of times each possibility is viewed.

I think "better" needs to be defined. "More accurate results?" Possibly, but probably not by much. Less disturbance to general conversion rates (since the 'successful' case is presented most often barring random variability), sure. But the point is to try out every option, not try out the seemingly more successful option the majority of the time.