On Tue, May 19, 2009 at 10:51 AM, Mike Meyer <mwm@mired.org> wrote:
On May 19, 2009, at 12:43, Aaron Rubin <aaron.rubin@4dtechnology.com> wrote:
I realize that this is a religious debate which has gone on for many centuries. I appeal to the scientific aspects, with a distinct avoidance of preference and emotion. Preference might be easily explained by "right brain" vs "left brain" preference, but either way, it is merely a preference and I want to stick to facts. Here is a list I have compiled of facts which support a wider than 80 character line width standard (in Python, specifically). Please add to them, subtract from them, or add to the other side of the debate, but please avoid the usage of the word "readable" (which implies preference), unless you are referring to a scientific study of readability, which would be great.
Most of you points don't stand up under inestigation. Of course, negating them doesn't support am 80 character limit by itself.
1) Python is three things which the standard was not designed for: One: Object Oriented. Two: Not Hungarian notation Three: Mandatorily uses *whitespace* as its defintion for code blocks. Let me explain each one in a bit more detail: Object Oriented: Because it is not functional-style programming, but instead OO, you have to give defintion as to what object type you are using before using it. This makes definitions and usage longer than in functional programming (when 80 character widths were invented). PhazeMonkey.Hardware.FrameSource.Abstract.Framegrabber is an example (and not an extreme one) of a class (55 characters already) in a rather large code base.
This type of reference is considered by some to be bad style. See the "Law of Demeter" for more information.
The Law of Demeter applies to objects referenced second-hand. The class name given is an example of a hierarchy of modules, not one class reaching through a second class to get at the class members it uses.
Not Hungarian: Not only is Python not Hungarian (in general), but the PEP-8 specifically tells us to use longer, more descriptive variable names. hasInstrumentControllerPhaseDither is an example. Many variables are 15-20 characters and oftentimes longer.
This appears to be false. A quick check of the standard library finds between 1 and 2 percent of variable references to have fewer than 15 characters, rising to 8 percent of unique names. This hardly qualified as many.
do you mean greater than 15 characters? If not, then I don't see your point. At any rate, 8 percent of unique names seems statistically relevant. 8 percent of how many? If the number is 100,000, then I would say that 8,000 variable names qualifies as "many".
Whitespace: Python is very unique in that it *uses* whitespace for code blocking. It turns out to be very useful, since it visually cues the reader where code blocks begin and end by mandate. This creates many situations where code *starts* at the 10th indentation (40 characters in our standard, 80 characters in some Python standards).
This also appears to be false - the standard library has fewer than 200 lines out of over 80,000 that start that deep. "Rarely" would seem to be more accurate than "many".
200 lines might qualify as many. Regardless, there are quite a number of lines which do. Let's not argue over the meaning of "many". As long as "some" exist, the point remains.
Even in normal "great design" mode (which takes more time again), you can't help it....your code starts at the 6th indentation level often. (28 characters, more than 30% of 80 characters already gone. Now how many variables or class names can you fit?) Whitespace (2): Because Python uses whitespace as its sole method of code blocking and because this is the visual cue for code blocks, wrapping lines obfuscates this and makes the reader think about whether this whitespace was there for a code block, or a line-wrap. Thinking about intention of code slows us down.
2) Many of the libraries that are widely used do not adhere to the 80 character width line standard. wxPython, NumPy and Boa Constructor are a few, but I'm sure there are many, many more.
Which just goes to show that you don't hve to be constrained by the PEP if you don't want to. Notvthat doing so is a good idea.
3) Writing new code in 80 character line widths takes more time. If I have to worry about hitting this width, I have to de-concentrate my efforts of writing logical code and concentrate instead on how exactly to format this line of code (where to break it, etc....there are a number of rules attached to wrapping lines of code). Then I have to re-concentrate on the actual task at hand. Alternatively, I can code it up without worrying, then when convenient, take some time to reformat to 80 character width. Either way, more time.
On the other side, the Oulipo school of writing believes that writing with apparently arbitrary constraints improves the results. I find that if I'm running into the 80 character limit with any frequency, it's because my code is poorly structured and in need of a reworking.
That can definitely be a symptom of bad code. Doesn't mean it's the only reason for it, however.
4) Code searching. IDEs have powerful searching features. They list all the lines of a file (or files) which match the string you are searching for. If things are in one line, this search is meaningful and you can read it like you can code. If a line of code actually spans two (or more) lines of code, the search is no longer contextually useful and you have to click on each item to see what's actually going on. This feature is used heavily in many environments (especially large code bases) to save time, but time is either lost finding the actual context of a found string, or the search tool is avoided altogether because it does not provide meaningful results (i.e. a predictive waste of time)
In that case, you need a better IDE; it should either show more context, allow multiline searches, or both. Both of these things will help even if you never wrap your lines.
5) Monitors are getting bigger, wider, cheaper. This allows us to have two files, side-by-side on a screen that are *both* 120 character width (or even wider), without changing font sizes.
Printers aren't.
6) Tools are cheap. Time isn't. Get a second monitor, get a more powerful editor, do whatever it takes to save time. If viewing more information at one time is important, then we should try to make that possible with technology, not time.
This point seems to be at best neutral to where or if you wrap lines. A good IDE will wrap the display and indicate it did so.
7) Python is designed to be written more like English than other programming languages. English is written horizontally, not vertically. In furtherance to an attempt to make "readability" an objective argument, here is a scientific study which finds that greater character width lines improve readability: <http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp> http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp. To summarize, the study found that of the choices of 35, 55, 75 and 95 character lengths, 95 was able to be read the fastest.
Please note that the study *started* by pointing out that other studies existed which found the best line length to be anywhere from 35 to 85 characters, and gave no reason for trusting their results rather than the earlier studies. I would claim that all studies that looked at written languages - as opposed to programs - were inapplicable. They almost certainly used variable width fonts and a left justification (if not both), either of which has more effect on readability than line length.
Thanks for the time spent reading this long-ish post. Thanks for your feedback if you provide it.
You really need better justification - studies of program comprehension, not English reading speed, code bases that support your claims about written code, etc.
I would love to see these studies done, but at this time I cannot find them. The closest I could come (and I disclaimed that it was only a loose connection) was the study I referenced.
<mike