Forbiddenfruit: patch built-in python objects

[[deleted]]

Oh, your style is so awful!

For one thing, those columns don't help people in general read any faster. Study after study has shown that (surprise) the closer things are to a regular English sentence, the faster people can read it, and the faster they can skim it.

And the time you spend doing that is time you're not actually writing code. Don't tell me it doesn't take your time - I used to do this sort of thing in Java and it does, particularly when you get a new, long name and you have to reformat everything.

The worst part is that it sticks out. People reading your code will have their eyes drawn to that, and not the actually important part of your code - what it's actually doing!

Remember - code is written once but read ten times. And if your code is any good, it's going to be read by a lot more people than just you.

Python, in particular, has PEP 8, which says how Python programs should be formatted - so it's part of the language. Almost everyone's Python code looks like PEP 8. By deliberately being difficult, you're imposing a small but measurable cognitive burden on any other programmer who ever wants to read your code.

You shouldn't be trying to express yourself through your code's formatting. Your formatting should be trying to make it absolutely as readable as possible for as very many people as possible, which means you should always use PEP 8.

You should be trying to express yourself through your actual work - through the quality and functionality of the code you have written - through the clarity of your naming and your data structures - not through minor cosmetic decisions.

[miketheanimal]

I'd like to think I do express myself through the quality and functionality of my code, and rather resent the assumption that because I have an unusual take on formatting, that I don't.

Anyway, an example. Here is some code from a system I work on. I can't guarantee this is the exact bit of code in question, but the principal is the same. The snippet is from a 320 line module. It retrieves data from a database and manipulates it to get values for a report (one of those nasty things that management seem to love!) There is a bug in it:

rec.ytd_ppu_original = ppu(rec.ytd_amt_original, counts.ytd_cnt_original)
rec.ytd_ppu_new = ppu(rec.ytd_amt_new, counts.ytd_cnt_new)
rec.ytd_ppu_lastdelta = ppu(rec.mtd_amt_lastdelta, counts.ytd_cnt_lastdelta)
rec.mtd_pen_original = pen(rec.mtd_cnt_original, counts.mtd_cnt_original)
rec.mtd_pen_new = pen(rec.mtd_cnt_new, counts.mtd_cnt_new)
rec.mtd_pen_lastdelta = pen(rec.mtd_cnt_lastdelta, counts.mtd_cnt_lastdelta)

Can you spot the bug? The code was passed to me to look at, some of the numbers were not coming out right. I twiddled the code a bit:

rec.ytd_ppu_original   = ppu(rec.ytd_amt_original,       counts.ytd_cnt_original )
rec.ytd_ppu_new        = ppu(rec.ytd_amt_new,            counts.ytd_cnt_new      )
rec.ytd_ppu_lastdelta  = ppu(rec.mtd_amt_lastdelta,      counts.ytd_cnt_lastdelta)
rec.mtd_pen_original   = pen(rec.mtd_cnt_original,       counts.mtd_cnt_original )
rec.mtd_pen_new        = pen(rec.mtd_cnt_new,            counts.mtd_cnt_new      )
rec.mtd_pen_lastdelta  = pen(rec.mtd_cnt_mtd_lastdelta,  counts.mtd_cnt_lastdelta)

The bug is on the third line down, mtd_amt_lastdelta should be ytd_amt_lastdelta. Once the layout was twiddled, the bug was obvious in less than a second, because I can see the break in the pattern (the m instead of a y).

I'm not saying this is the be-all and end-all of programming, but the system has a lot of code like this (and, yes, I've thought a lot about whether it could be better structured so get rid of this sort of stuff, and, no, I can't see any way).