Browsing through the Rails code... I see a lot of lines over 80
characters there!
I always thought that it was good to keep line length below 80
characters as it helps readability on different devices/screens. But
I've found that it's difficult to keep that small a line length
sometimes.
Your thoughts?
Joe Van Dyk wrote:
Browsing through the Rails code... I see a lot of lines over 80
characters there!I always thought that it was good to keep line length below 80
characters as it helps readability on different devices/screens. But
I've found that it's difficult to keep that small a line length
sometimes.Your thoughts?
What makes you think it's difficult?
puts "Tom Tidler's Ground".scan(/[TG](r)?([aeiou])/).\
flatten.compact.join
I frequently find it really hard to keep lines below that limit without heavily altering the code I want to write (such as wrapping a single statement in a if ... then rather than a post-line conditional). When I find myself wasting time reformatting my code to try and meet an arbitrary limit that is nowhere close to what my own screen and comprehension impose, I try to stop and say "It's alright, leave it be."
I think it's a nice initial goal, but I personally don't fret if half my lines are 100 characters long, and the occasional line tops 130 or more.
On Aug 15, 2005, at 10:20 PM, Joe Van Dyk wrote:
I always thought that it was good to keep line length below 80
characters as it helps readability on different devices/screens. But
I've found that it's difficult to keep that small a line length
sometimes.
William James schrieb:
Joe Van Dyk wrote:
I always thought that it was good to keep line length below 80
characters as it helps readability on different devices/screens. But
I've found that it's difficult to keep that small a line length
sometimes.What makes you think it's difficult?
puts "Tom Tidler's Ground".scan(/[TG](r)?([aeiou])/).\
flatten.compact.join
In this case you can even omit the backslash. Because of the last dot Ruby knows that the statement isn't finished yet.
Regards,
Pit
[talking about 80 character lines...]
I think it's a nice initial goal, but I personally don't fret if half
my lines are 100 characters long, and the occasional line tops 130 or
more.
I generally try to keep my lines less than or close to 80 lines, as well, but
it's not over any great concern about whether or not the lines will fit on
someone else's screen. Just as processor speeds climb and storage media
capacities soar, screen resolutions have also increased, and with them, the
usable line length has changed, too. I used to believe that the 40 character
wide Apple ][+ lines were perfectly reasonable, for example. Technology is
no great limit, unless one is coding on or reading code on a palm-sized
computer.
My reasoning for generally trying to stay at 80 characters are that by
sticking to some arbitrary limit, it helps me to think about how the code and
the comments do look. Comments that stick to an arbitrary limit are nicer
looking and easier to read, and often if I have a line of code that is
growing well beyond that arbitrary 80ish character limit, it's a signal to me
that there might be a simpler approach or that I am probably writing a
Faulkner style sentence when a Hemmingway style paragraph would probably be
easier to read. Like that sentence you just finished reading. Sure, it's
fine, but turning it into multiple sentences would be better for most
readers.
It is just a general rule, though, and I violate it all the time. For
instance, if I am creating a chain of several method calls or doing something
similar, it may be easier to understand a single long sentence instead of a
paragraph of short sentences.
As with so many style issues, it comes down to personal taste. Do what makes
sense for you and your audience.
Kirk Haines
On Tuesday 16 August 2005 6:27 am, Gavin Kistner wrote:
Well put.
The eye gets lazy when it has to follow those long lines. I figure I'm trying to be too cute, when my line soars past 80 characters and I rethink what I'm trying to accomplish.
Also, I'm of the opinion that it eases the inclusion of code in other mediums: email, web pages, and books. This can be pretty important in Ruby where a wrapped line can change the meaning of the program.
James Edward Gray II
On Aug 16, 2005, at 7:58 AM, Kirk Haines wrote:
My reasoning for generally trying to stay at 80 characters are that by
sticking to some arbitrary limit, it helps me to think about how the code and
the comments do look.
Right. There's a reason why newspapers wrap lines in articles the way
they do. It's easier for us to read. I think the same applies to
reading source code.
On 8/16/05, James Edward Gray II <james@grayproductions.net> wrote:
On Aug 16, 2005, at 7:58 AM, Kirk Haines wrote:
> My reasoning for generally trying to stay at 80 characters are that by
> sticking to some arbitrary limit, it helps me to think about how
> the code and
> the comments do look.Well put.
The eye gets lazy when it has to follow those long lines.
--
R. Mark Volkmann
Partner, Object Computing, Inc.
Though one should not follow print media guidelines too closely. People
generally have their eyes farther away from their monitors than they do from
print media that is being read, which means that the natural scan arc of the
eye can take in a wider line on a monitor than on book or newspaper. Of
course, confounding that is the fact that paper has a clarity and crispness
advantage over monitors.
I did a project for a Catholic priest this spring, helping compile a
historical archive, and we went round and round more than once on the fact
that formatting online content like a print manuscript looks funny; the
columns are too narrow.
Kirk Haines
On Tuesday 16 August 2005 9:33 am, Mark Volkmann wrote:
Right. There's a reason why newspapers wrap lines in articles the way
they do. It's easier for us to read. I think the same applies to
reading source code.