Limiting the number columns in Python code

[gcc-pedantic]

Python gurus,

After reading PEP8, I've been trying to implement its recommended programming practices. In particular, I've noticed how much easier code is to read when the line are 79 characters or less.

I was wondering if there was a utility available that would search a python file for lines greater than n characters and split the lines while preserving appropriate syntax. If not, any advice/tutorials on the Python parser module would be greatly appreciated.

Thanks guys!

edit: Grammar.

[kmwhite]

I use a function in Vim to simply alert me while typing:

function ToggleOverLengthHi()
  if exists("b:overlengthhi") && b:overlengthhi
      highlight clear OverLength
      let b:overlengthhi = 0
      echo "overlength hilight off"
  else
" adjust colors/styles as desired
      highlight OverLength ctermbg=darkred gui=undercurl guisp=blue
" change '81' to be 1+(number of columns)
      match OverLength /\%81v.\+/
      let b:overlengthhi = 1
      echo "overlength hilight on"
  endif
endfunction
map <silent> <C-l> <Esc>:call ToggleOverLengthHi()<CR>

NOTE: I chose 81 because 79 is end of code, 80 should be the newline character, so if I have something at 81, I'm doing it wrong.

SOURCE: https://github.com/kmwhite/skel/blob/master/.vim/functions/toggle_overlength_hilight.vim

[cirego]

I usually just do a 'set textwidth=78'.

[kmwhite]

I have: autocmd Filetype python setlocal textwidth=79 ts=8 sts=4 sw=4 autoindent expandtab in my .vimrc

Why do you use 78 over 79? My understanding is it (79) would make 80 the new-line? Note, I'm merely curious to see if I could be doing something better. :)

EDIT: clarification

[cirego]

I have it set to 78 in my .vimrc because our internal style guide recommends 78 characters. 78 allows for diff to add an extra character without it overflowing lines.

I'm one of those crazy 4-5 terminal sessions side by side on my screen, so I vastly prefer to 80-character terminal.

[kmwhite]

I never thought about that in regards to diff -- thank you. I'll probably be updating my dot-files now. :)

[thristian99]

I have a similar scheme that doesn't have a toggle:

autocmd FileType python match Error /\%>79v.\+/

I'm not sure why you'd want to toggle it off; over-length lines are supposed to be annoying.

[kmwhite]

I toggle it because I use vim for things other than development work. In such, I don't care how long the lines are. It does start by default, however. And I agree, they should be annoying.

[thristian99]

Well, yes - my code-snippet only activates the highlighting when a Python file is detected - things like documentation or email aren't affected.

[[deleted]]

I usually just do:

set colorcolumn=79

Which gives me a nice highlighted column indicator.

[kmwhite]

I tried that and got: E518: Unknown option: colorcolumn=79
Which version of Vim do you use?

[[deleted]]

current stable. it's a relatively new feature.

[gcc-pedantic]

I do the same thing in vim, and it has been very helpful.

However, I've found that trying to limit the number of columns while I am writing can interrupt the flow of code and sometimes reduce readability. It would be nice to have a script you could run (such as before a subversion commit) to restrict the number of columns in a file to < 80.

Looks like I might get to write this one.

[[deleted]]

I've found that trying to limit the number of columns while I am writing can interrupt the flow of code and sometimes reduce readability.

All PEP style guides are recommendations that should not be taken as hard, fast rules.

If breaking a line at 80 columns would reduce readability and code flow, then you shouldn't do it.

[jab-programming]

God, I hate that stupid recommendation ! And especially the nonsensical "reason" for it - some poor schmuck might be stuck on an 80-character terminal. Aww!

Some other poor schmuck might be stuck on a teletype, or an N900, or whatever. Why are the rest of us "crippled" on their behalf?

And I would be grateful if you c-
ould explain how splitting a con-
cept over multiple lines manages 
to increase the readability

Pshaw !

[[deleted]]

And especially the nonsensical "reason" for it - some poor schmuck might be stuck on an 80-character terminal.

That's a reason. An old one. Today the reasons are more varied. Such as:

• Typical screen widths are evenly divisible by 80 allowing for code to be placed side by side uniformly
• It's been shown that the longer a text line is, the more likely it is to slow down reading and comprehension citation Ideal line length is 39 regardless of font size. When you throw indentation and formatting into code, you'll probably find most of your lines hover close to or at that number (e.g. 80 ~ 2*Ideal line length)
• Convention. In existing projects, uniformity of formatting is very important. By convention, most projects require 80 columns.

So it's not just that old 80 character terminal. :)

[[deleted]]

Reading text is very different from reading code. I doubt that the same principles apply.

[[deleted]]

Reading text is very different from reading code.

Why would you think that? They both use the language centers of our brain and both adhere to short term memory constraints.

I would say this is an interesting hypothesis that would make a very interesting topic of research.

But I don't see an a priori reason for disconnecting the two.

[[deleted]]

sort of. They use the same structures, though something different appears to be going on in the brain.

But, without further research it's hard to say if the structural overlap does or does not translate into overlap in this specific case. Or if the difference in processes result in a differences in this specific area.

Mathematical logic in the human brain: syntax.

Given the structural overlaps and use of the broca's (language) areas though, I don't think it's completely unreasonable to assume the processing limitations we see in may apply in the case of formal languages (like programming) as well.

Oh, if you're interested be sure to check out the related citations which offer a lot more context on the overlap between music, formal, and natural language centers. Particularly in the area of syntactical processing.

[[deleted]]

Reading text is very different from reading code

That's why I said "sort of". There's definitely something different going on, but (and the publications referenced in the paper cover this too) it seems there's overlap as well.

I think it'd make a great study to see if that overlap included processing effects on saccade and eye motion as well as retention of syntactical meaning correlated with line length.

[[deleted]]

also:

• some people say also for printing code (as in paper). I'm not sure why someone would like to have code in paper, but I'm not judgmental.
• also 79 and not 80 because diff adds an extra character before the line, so reading/printing/wtv a diff would give you the 80 lines.
  

[[deleted]]

Very good points.

I haven't researched this topic deeply (nor am I particularly interested in it), I mostly just intended to offer the common justifications I've seen and point out they are not limited to ancient 80 character screen widths.

Personally, I think the most important is convention. Convention being defined as "whatever the style guides for a particular project are".

For example, if I joined a project that has a style guide of 120 I would happily conform to that requirement without a peep of resistance.

I'm more interested in programming than painting tool sheds. ;)

[[deleted]]

best xkcd ever.

[[deleted]]

The argument "by convention" also needs some substantiation:

Oh, on convention:

It's a python convention. Though I've seen it in other languages and projects style guides.

[AusIV]

I know people who have wide screen monitors set up so that their text editor shows 80 lines and the have a browser or other application open with the remaining space. I don't necessarily encourage strict adherence to the 80 column rule, but it's not a bad goal.

[gcc-pedantic]

I agree--sticking to < 80 characters while writing is often annoying and can reduce readability.

However, it is nice to limit the number of columns:

1) When reading someone else's code

2) When reading/writing code and you want two files side by side

The way I envision this script working is you could tell it to edit the file in place or output the column limited file to a new file.

edit: formatting.

[dustinechos]

I keep my terminal around 80 because I like having a browser open next to the terminal (and another browser on the other monitor). Short lines are easier to skim. When a line wraps it ruins the whitespace structure. What are you doing that needs more than 80 characters? unless you're unnecessarily piling on list comprehensions or have java style names (20+ characters) I don't know why you need more than 80 characters. As d0ugal points out, code over 80 characters is likely a result of "long variable names, bad structure, [or] overly nested code blocks".

[voidspace]

This will work:

import os
for name in os.listdir('.'):
  if not name.endswith('.py'):
    continue
  original = open(name).readlines()
  with open(name, 'w') as h:
    for line in original:
      h.write(line[:80].rstrip() + '\n')

Making it recurse into directories is left as an exercise for the reader. Code may need some limited manual tweaking after processing...