6 ms·

I love how a lot of responses here are of the condescending tone of "we aren't using vt100s anymore, grandpa", as if advocates for the 80 column limit are still

I love how a lot of responses here are of the condescending tone of "we aren't using vt100s anymore, grandpa", as if advocates for the 80 column limit are still running VIC20s in their mom's basement. I see this argument pop up a lot against things like vi and Emacs as well. Yes, we realize that monitors are bigger, resolutions are higher, etc ad naseum. None of that matters. What matters is code readability. So what if you can fit 120 characters in your code editing window? I can fit more than 400 across two monitors, should the new line length limit be 400? Why stop there, why not just let lines be endless and have the editor wrap them? Answer these questions, and you've answered why people still like the 80 column guideline, or even care about code formatting at all. Code is only incidentally written for machines to execute; it should be written for people to read.

ak217 14y ago
Yeah, but code readability has little to do with line width. I could show you perfectly unreadable code that fits in 80 characters because it's legitimately pre-indented by 40 and has to go to one word per line or shorten variable names to fit in 80, and wonderfully easy to read code that goes out to 160 (often because of some literal data that would otherwise just increase the vertical length). Also, it's funny to me that people talk about horizontal line length impacting readability, but never seem to talk about vertical length impacting readability as well. To me it's critical to keep related code clustered vertically as closely as possible without too much brevity: having to scroll/split view to see related pieces of code incurs a cognitive overhead. Arbitrary line breakage imposed by the 80-character limit gets in the way of that. (And don't get me started about teams that treat this as a limit instead of a guideline.) It's critical to give programmers the tools to make their code readable (good languages with good grammar and idioms), not arbitrary restrictions that try and fail to accomplish that indirectly.
- ajross 14y ago
  > I could show you [...] wonderfully easy to read code that goes out to 160 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. :)
  - ak217 14y ago
    https://github.com/kislyuk/dmtk/blob/master/scripts/comparePulseData.py https://github.com/kislyuk/dmtk/blob/master/scripts/compareP... Feel free to criticize. That code has lots of shortcomings. Compromised readability due to line length is not one of them.
    - deleted 14y ago
      [deleted]
    - ajross 14y ago
      You can't be serious. Check lines 388-400. Now, even ignoring the fact that github itself is chopping those lines because they're too long, they're simply not meaningfully readable. The ridiculous repetition (which is the proximate cause of those awful line lengths) totally obscures the meaning. 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.
      - ajross 14y ago
        Just because I'm feeling bored today, here is that same loop (around line 388) "cleaned up" to work inside 80 columns. I added a "metricGenrator" abstraction to the API because it seemed like a sane addition to clean up the "too many arguments to mean()" problem, but all other changes are is pure syntax. I dare you to argue that this isn't more readable than the original: 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']])
- jonnytran 14y ago
  > people talk about horizontal line length impacting readability, but never seem to talk about vertical length 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.
VLM 14y ago
I recently switched from 80 to whatever will fit (oh, 120 or so) on certain projects. Its an extremely personal decision because it depends on the exact interface of your skill level as a programmer in general, your skill level with that particular language, your skill level in the business problem domain, AND your own peculiarities WRT to the kind of errors you make. Given the exact workload I'm being paid for at this time I do NOT make "line" level errors or even "small block" errors but instead get tripped up on crazy "business logic" and big architectural issues. So I am better off at this moment with longer lines showing more "big picture" than with clear little lines. What I'm getting at is on recent projects I've been making more mistakes with "which blocks of changes need to complete transactionally/atomically based on crazy business logic without causing race conditions" rather than "I need to make it really clear I'm adding these two numbers as opposed to concatenating two strings" or whatever. This tradeoff of width vs length varies for me, project by project based on actual requirements. Personally I think this helps "those who come after me". If you see long complicated lines that's a warning that you should tread lightly there and there's probably something complicated at the "vertical" big picture level going on, so I had to make the "horizontal" look icky to make it fit. If I'm just squirting out blah blah code and hitting enter every 20 characters you can safely assume at the big picture there is nothing very complicated going on. A good (fine arts oil) painting analogy is which is better, portrait or landscape canvas? Well, it depends on the scene. Maybe you personally are only commissioned to paint portraits, well then...
rdtsc 14y ago
The better and higher resolution monitors I got the more fanatical I got about the 80 column rule. Why? Because I can split my code into vertical columns on the new fancy monitor. If code lines are 160 I can or have to constantly horizontally scroll them or live with random wrap-arounds. Then the next up monitor I could do 3 columns, so I still stuck to the 80 column idea.

ak217 14y ago

Yeah, but code readability has little to do with line width. I could show you perfectly unreadable code that fits in 80 characters because it's legitimately pre-indented by 40 and has to go to one word per line or shorten variable names to fit in 80, and wonderfully easy to read code that goes out to 160 (often because of some literal data that would otherwise just increase the vertical length). Also, it's funny to me that people talk about horizontal line length impacting readability, but never seem to talk about vertical length impacting readability as well. To me it's critical to keep related code clustered vertically as closely as possible without too much brevity: having to scroll/split view to see related pieces of code incurs a cognitive overhead. Arbitrary line breakage imposed by the 80-character limit gets in the way of that. (And don't get me started about teams that treat this as a limit instead of a guideline.) It's critical to give programmers the tools to make their code readable (good languages with good grammar and idioms), not arbitrary restrictions that try and fail to accomplish that indirectly.

ajross 14y ago
> I could show you [...] wonderfully easy to read code that goes out to 160 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. :)
- ak217 14y ago
  https://github.com/kislyuk/dmtk/blob/master/scripts/comparePulseData.py https://github.com/kislyuk/dmtk/blob/master/scripts/compareP... Feel free to criticize. That code has lots of shortcomings. Compromised readability due to line length is not one of them.
  - deleted 14y ago
    [deleted]
  - ajross 14y ago
    You can't be serious. Check lines 388-400. Now, even ignoring the fact that github itself is chopping those lines because they're too long, they're simply not meaningfully readable. The ridiculous repetition (which is the proximate cause of those awful line lengths) totally obscures the meaning. 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.
    - ajross 14y ago
      Just because I'm feeling bored today, here is that same loop (around line 388) "cleaned up" to work inside 80 columns. I added a "metricGenrator" abstraction to the API because it seemed like a sane addition to clean up the "too many arguments to mean()" problem, but all other changes are is pure syntax. I dare you to argue that this isn't more readable than the original: 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']])
jonnytran 14y ago
> people talk about horizontal line length impacting readability, but never seem to talk about vertical length 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.

VLM 14y ago

I recently switched from 80 to whatever will fit (oh, 120 or so) on certain projects. Its an extremely personal decision because it depends on the exact interface of your skill level as a programmer in general, your skill level with that particular language, your skill level in the business problem domain, AND your own peculiarities WRT to the kind of errors you make. Given the exact workload I'm being paid for at this time I do NOT make "line" level errors or even "small block" errors but instead get tripped up on crazy "business logic" and big architectural issues. So I am better off at this moment with longer lines showing more "big picture" than with clear little lines. What I'm getting at is on recent projects I've been making more mistakes with "which blocks of changes need to complete transactionally/atomically based on crazy business logic without causing race conditions" rather than "I need to make it really clear I'm adding these two numbers as opposed to concatenating two strings" or whatever. This tradeoff of width vs length varies for me, project by project based on actual requirements. Personally I think this helps "those who come after me". If you see long complicated lines that's a warning that you should tread lightly there and there's probably something complicated at the "vertical" big picture level going on, so I had to make the "horizontal" look icky to make it fit. If I'm just squirting out blah blah code and hitting enter every 20 characters you can safely assume at the big picture there is nothing very complicated going on. A good (fine arts oil) painting analogy is which is better, portrait or landscape canvas? Well, it depends on the scene. Maybe you personally are only commissioned to paint portraits, well then...

rdtsc 14y ago

The better and higher resolution monitors I got the more fanatical I got about the 80 column rule. Why? Because I can split my code into vertical columns on the new fancy monitor. If code lines are 160 I can or have to constantly horizontally scroll them or live with random wrap-arounds. Then the next up monitor I could do 3 columns, so I still stuck to the 80 column idea.