On Fri, 2007-03-09 at 11:00 -0500, Perry E. Metzger wrote: > You can rail against how stupid this is, but it won't get you very far > with those of us who live this way. You can thus choose to make the > code unreadable by a large chunk of the developer community, or stick > to 80 columns.
I'm not saying it's stupid and it shouldn't make it "unreadable". Actually, I'm suggesting the code is more readable. I've made these arguments myself in the past... literally, all the same points you bring up. I think they focus on the wrong things. I'm also not being capricious; I've spent years trying it both ways, and I find the code is clearer with an 80-column guideline, but without an 80-column limit. Editors shouldn't wrap preformated code. In the common case, the bulk of the code fits clearly w/in 80-columns ... with a few lines where the ends trail off and need to be scrolled. In my experience, you can get the gist of the line from seeing the first 80 characters, and need to scroll over very rarely. My normal emacs window is 198x75, and I much more often split it horizontally than vertically; when I do, though, I can still fit code into the ~80-wide sub-windows, especially for comparing stuff side-by-side. Over-deep nesting is an orthogonal issue. Similarly, too-long functions are something else entirely. I'm guilty of both, at times, but I'm not looking for a 100-wide limit to work around either of those smells. Printing to the page often requires reformatting (in other contexts as well). I don't think it is useful to optimize for this (increasingly) special case. Yes, some part of this proposal is due to editing files in 2007 on a big monitor, with a good IDE, &c. But that's how we spend 99% of our time, so it's what we should focus on. > As an aside, generally speaking, I think identifiers and type names > are no longer than they were in the early 1980s. I also think humans > are no smarter, so we can't deal with keeping larger blocks of code in > our heads at once than we could 25 years ago. Identifier lengths, perhaps ... function-local variables and class-local field names tend to have the benefit of scoping and context to allow them to continue to be short. I think too much code uses meaningless abbreviations, but ... But functions and type names are clearly getting longer, especially as libraries do more and higher-level stuff. I think this is especially true in C and Gnome-ville, where there's no language support for packaging and aliasing (as in, say, Java and C#). Take, for example, http://svn.gnucash.org/trac/browser/gnucash/trunk/src/gnome-utils/gnc-tree-model-account.c#L55 We've taken to shortening names like these to something like 'gtma_[...]', and that works much -- but not all -- of the time. Or, take for example the dozen cases from real code that I presented in the previous email; those are reasonable cases from a not-exceptional file. > The biggest consideration in style choices is making sure as many > people as possible can read and understand your code, since the This is my motivation. I think a >80-character unbroken line is more readable than one "unnaturally" split at 80 columns. -- ...jsled http://asynchronous.org/ - a=jsled;b=asynchronous.org; echo [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
