I'm calling this bluff. No, you can't. If you actually have evidence I'd truly love to see it.

Ridiculous line length is actually one of the most reliable code smells I know. Seeing something like that, I can virtually guarantee that it's an OOP-gone-wild mess of needless abstraction, tightly coupled data structures spread across a dozen files. It's going to be a spaghetti mess of nested if() constructs used where clean data-driven logic would have been better. It will be filled with commented-out-code. And it will probably have indentation that lies, lined up in incorrect columns waiting to fool the developer.

Clearly you feel differently. Prove it. :)

Feel free to criticize. That code has lots of shortcomings. Compromised readability due to line length is not one of them.

Note all the repeated use of this weird dictionary name "my_stats[condition][strand]". This thing appears, often multiple times, on ever line of that loop. You're telling me that this couldn't be made more readable by using a simple local "stats" reference name "st"? Repetition of expressions is the sign of lazy code, it's the same kind of thought process that gives us cut-and-paste bugs.

Note likewise the repated use of "kc_stats[condition]". Same deal. Same treatment.

Note likewise the oddball commented out line (assigning a tuple of m2_ci_lo_fwd, m2_ci_hi_fwd) which is disabled without explanation. Remember my list of attendant symptoms?

And, on the design side: note the mean/median/stdev calls. Those are generally pretty well-defined properties of "sets". Why is there a "Metric" postpended to the method names needlessly? Surely the reader would understand "st.stdev()" already, right? And why do the methods take five named parameters?. That's insane -- they should take zero. It looks like this is trying to pass in some extra "stuff" (maybe to control some side effects, or to filter the data) to what should be an idempotent operation on a fixed piece of data. If you have to filter, or if the object does some extra counting or whatever, those should be set up on the data ahead of time.

This code is crap. Sorry.

      my_stats = {'Modified': {'+': {}, '-': {}}, 'Control': {'+': {}, '-': {}}}
      for condition in 'Modified', 'Control':
        for strand in '+', '-':
          st = my_stats[condition][strand]
          kc = kc_stats[condition]
          kc = kc.metricGenerator(metric, ref_pos=ref_pos, trim=opts.exp_trim,
                                  coverage_ceiling=opts.coverage_ceiling,
                                  strand=strand)
          st['mean'] = kc.mean()
          st['median'] = kc.median()
          off = st['stdev'] = kc.stdev()

          if use_se:
            kc.setOpts(ref_pos, metric, trim=0.0,
                       coverage_ceiling=opts.coverage_ceiling, strand=strand)
            off /= sqrt(len(kc._getMetricData()))

          st['spread_lo'] = st['mean'] - off
          st['spread_hi'] = st['mean'] + off
          my_report_row.extend(st['mean'], st['median'], st['stdev'],
                               st['spread_lo'], st['spread_hi'],
                               st['coverage']])

In either case, both examples are literally geometrically square, which I think drives readability more than line width. When the long lines poke out and don't relate to other long lines, it's hard to read. If all the lines are long and share structure, it's just verbose, but reasonably easy to read. With that perspective, I'd say the parent's code isn't a great example of long-line code: it doesn't demonstrate a _need_ for 160 chars; I'll agree with you.

Some of us have a higher standard for "readable" code than "can be refactored so that it doesn't suck". :)

* Duplication everywhere.

* No internal comments indicating the code's purpose.

* Long functions with too much nesting.

* Lack of constants.

* Indenting by 4 spaces (instead of 2).

* Lines like 316-320 and 326-335 should line break and indent after the first open parenthesis to avoid huge whitespace.

* Inconsistent line break usages for long lines.

* Line 412, for example, should line break at "ref_pos".

The code has many shortcomings, including readability due to extreme line length.

  self.opts.modified_positions_fwd = [ int(p) for p in self.opts.modified_positions_fwd.split(",") ] if self.opts.modified_positions_fwd != None else []

Both yours and my claims are anecdotal. Unfortunately I don't know of many research studies, though I'm sure some has been done for this issue in typography.

This is why I think it's absurd that we still use flat file text editors to code. I don't care about how functions are laid out in the file. As you said, I care about their semantic relatedness. That may vary by concern. It's almost like I want to tag each function with the features/concerns that it addresses. Then I'd like to be able to view each tag on its own, and have all its constituent parts (functions, modules, classes, etc.) laid out in a way that makes sense. Maybe that's stacked vertically, maybe side by side, or maybe something else. I'd be able to switch between views at will. Each feature branch would probably have its own view.

This would have the side benefit that a function with many tags is a new smell, but more meaningful than character or line length.

The only people I know of who are even attempting to address these issues are Brett Victor, Jonathan Edwards, and the Light Table people.