On Fri, 6 Nov 2009 23:00:15 +0000 (UTC), Andrew Smallshaw
andrews at (no spam) sdf.lonestar.org> wrote:

On 2009-11-05, Paul Carpenter <paul at (no spam) pcserviceselectronics.co.uk> wrote:
Despite C, being free format, avoid too much free format, remembering
that at some time it may well be printed, 300 character lines wrap
very interestingly, if they wrap. Choosing indentation matching
can make following the code easier, even if you have managed
to get the function to fit on one page.
I keep getting criticism for ignoring an imagined 80 column limit.
Yes, I'll keep it under 132 columns but not 80 - it just gets too
restrictive and demands either less indentation of cyptically short
variable names which are a much bigger problem. 132 (sometimes
136) is of course how long a line can be printed on a wide carriage
printer, so it is largely historical now, although is does approximate
what enscript -r can fit on a sheet of A4 with default settings.
With modern text editors under GUIs you are typically not limited
to anythign like 80 column views so I see no practical reason to
stick to such a narrow limit.

I stay with a strict 79 column limit. It turns out that I also print
my listings on the laser printer in portrait mode and that with the
use of commonly available fixed-pitch fonts like Courier or Prestige
Elite I get just about the right font size for readability, as well.

I couldn't possibly consider 132 columns as acceptable anymore. I
still have the boxes of printer paper designed for that, but long
since lost printers with the sprockets to feed the paper. Use it for
scratch paper, now. And printing landscape, while acceptably printing
at 132 columns fixed-pitch, puts too few lines on the page. Readable
code requires that the basic idea is presented (as well as possible)
on a single page (or perhaps two.) The few lines that I wind up
wrapping do NOT add anywhere near enough extra vertical lines to cause
a problem. While printing landscape would lose way too many lines and
would definitely become a readability problem for me.

I guess different people come to different, strongly held conclusions.

Jon

I keep getting criticism for ignoring an imagined 80 column limit.

Paul Carpenter wrote:
In article <slrnhf9ajs.4uj.andrews at (no spam) sdf.lonestar.org>,
andrews at (no spam) sdf.lonestar.org says...
On 2009-11-05, Paul Carpenter <paul at (no spam) pcserviceselectronics.co.uk> wrote:
.....
what enscript -r can fit on a sheet of A4 with default settings.

Never assume anything other than a simple text file print is possible
relying on specific software or printers, is the standard assumption
that you will be the only person ever wanting to print out any part.

Just like 'lock-in' IDE's that use encrypted project files.

Some types of work will require printouts, as paper is still a VERY
good archive method as it can be read for many more years, than most
media. How many systems still have 3.5" floppy drives?

With modern text editors under GUIs you are typically not limited
to anythign like 80 column views so I see no practical reason to
stick to such a narrow limit.

Hopefully you are dealing with standard text files, as paper
printout can be read where even some text files using strange
character encodings can be a pain.

Can you guarantee that any software written will only need to be
supported for about two years after release? That is about the
average timespan before some change means it can be difficult
to read some files due to things like

OS change
Tools version change
Tools (including editor change)
Media no longer available
printers or other changes (wide carriage no longer available)

Vanishingly few people actually go through their archive of projects
and all current releases to ensure that all files can be read/edited
and rebuilt, when they have one of the above changes. Generally it
suddenly becomes a problem because someone has to examine some
old code.

Coding standards are about maintainability as well as current
tasks.


In the days before networks and hard disks were common even in small
firms, there was an issue with media - I know that we have programs from
our company's early days that are effectively lost because they are on
old 5 1/4" floppies. You can also get in trouble if you use tape for
your primary archive media. But other than that, media should not be an
issue.

Printer sizes have not been an issue for something like 20 years
at least, since laser printers let you pick different font sizes and
thus different numbers of characters per line. And editors that can
work happily with files of different sizes, different line widths,
different line endings, and different character sets have been around
for at least as long.

So unless you are storing your source code files in some locked
proprietary file format, any source code file written for the last
fifteen years at least is ease to read, edit and print out from
virtually any system. I don't know where you picked the "two years
average lifespan" from, but it certainly wasn't reality.

Proprietary file formats are another problem, but fortunately for C
programmers, they are only an issue for things like project files rather
than for the actual source code.

On Nov 6, 6:00 pm, Andrew Smallshaw <andr... at (no spam) sdf.lonestar.org> wrote:
I keep getting criticism for ignoring an imagined 80 column limit.

As others have posted, I find the 80 column limit to be a good
one.

However, in my case, that doesn't come from printer limitations
and it doesn't come from my imagination either. It comes from
80 characters being the width of a non-GUI console.

Sometimes I use a GUI and sometimes I don't.

More importantly indent with spces the block of code by the
same amount. Tabs can be different on systems/IDE/editors

Just don't write assembly code in capital letters and do fill tabs
with spaces.

On Nov 6, 6:00 pm, Andrew Smallshaw <andr... at (no spam) sdf.lonestar.org> wrote:
I keep getting criticism for ignoring an imagined 80 column limit.

As others have posted, I find the 80 column limit to be a good
one.

However, in my case, that doesn't come from printer limitations
and it doesn't come from my imagination either. It comes from
80 characters being the width of a non-GUI console.

Sometimes I use a GUI and sometimes I don't.

My primary work desktop is 3200x1200. So, if I *wanted* to have
130 character lines, that's not a problem. Why stop at 130?
Why not *200*?? :

D Yuniskis <not.going.to.be at (no spam) seen.com> writes:
My primary work desktop is 3200x1200. So, if I *wanted* to have
130 character lines, that's not a problem. Why stop at 130?
Why not *200*?? :

My primary desktop is 4960x1600(*) but my editor is only 120 columns.
If I maximize it across all three monitors, it's 700 columns (358 if I
juse use the main one). I don't use the whole 120 colums usually, I
like to have some whitespace to the right of the text so I can easily
see when lines (like program outputs) wrap.

My xterms are 115x58, which is a weird geometry but it allows four of
them to tile in the remaining space without overlapping.

(*) one big monitor landscape, two small portrait ones to each side.
The two portrait ones are great for PDFs, web browsers, IRC...
Try rotating your two monitors someday, for a 2400x1600 display.
Might be more useful than 3200x1200.

D Yuniskis <not.going.to.be at (no spam) seen.com> writes:
I suspect you use a small-ish font?

7x13 pixels, about 11 point, bold. White on black for terminals,
black on beige for editing. Black on grey90 for web browsing.

But, the tops of the monitors (i.e., the top of the viewing area)
ends up too high for me.

I'm building a new desk that will have the keyboard higher so I can
raise my chair. The monitors will be a little further away, too.

I also tried using a third monitor but that proved to be too wide.

My layout is 4.5 feet across, and 2 feet from me. About a 90 degree

field of view. However, what I've got is a central 30" monitor with
two 20" monitors (rotated) next to it. So, most of my field of view
is the main monitor, but the other two are available for reference. I
never need to look at it all at the same time.

"things" on two different hosts "side-by-side" (the annoying
thing in this configuration is remembering that you *can't*
just drag things from one screen onto the other! :< ).

I suspect you use a small-ish font?

But, the tops of the monitors (i.e., the top of the viewing area)
ends up too high for me.

I also tried using a third monitor but that proved to be too wide.

Paul E Bennett wrote:
David Brown wrote:

Paul Carpenter wrote:

[%X]

In the days before networks and hard disks were common even in small
firms, there was an issue with media - I know that we have programs
from
our company's early days that are effectively lost because they are on
old 5 1/4" floppies. You can also get in trouble if you use tape for
your primary archive media. But other than that, media should not
be an
issue.
The old server has gone done and this hard drive uses an interface
Interfaces older than IDE were very rare, and if you have to use
something like older SCSI interfaces, you can still get the cards. The
PC world is pretty good at backwards compatibility.

and file system no longer supported by new system(s), is more common a
I'd be impressed if you can think of a file system that is a realistic
candidate for such a situation, and which is not supported by Linux.

[%X]

Wonder how many remember as far back as the Kansas City Tape Standard
for Data Recording onto Audio Cassettes. If really pressed I could
still cobble

grin> Or folks who used "VCR data recorders" manufactured
iin somebody's garage...

one of those up. However, if it was really important data to keep,
then it should have been subject to a migration policy so that it was
appropriately transferred to modern media.

*This* is the key issue here! 20 years ago I spent several weeks
takiing everything that I had archived (floppies of various
sizes, 9 track tape, a slew of other oddball tapes, etc.) and
copied it onto "modern media". Since then, every project
has been added to the pool.

I keep backups on a RAID5 array, additional copies on my
regular workstation (for more recent work or anything that
I want to "have a look back at"), other copies on CD's
and DVD's (these are POOR choices, IMO) and on DLT. The
most vulnerable of these are those on rotating media
as you can lose it *all* in a single ohnosecond! If
possible, find an external drive that has a hardware write
protect switch if you want to go that route...

The *good* thing about archives is they don't change
often. So, you (i.e., *I*) don't have to repeat this process
very often -- just incrementally update it.

D Yuniskis wrote:
Paul E Bennett wrote:
David Brown wrote:

Paul Carpenter wrote:

[%X]

In the days before networks and hard disks were common even in small
firms, there was an issue with media - I know that we have
programs from
our company's early days that are effectively lost because they
are on
old 5 1/4" floppies. You can also get in trouble if you use tape for
your primary archive media. But other than that, media should not
be an
issue.
The old server has gone done and this hard drive uses an interface
Interfaces older than IDE were very rare, and if you have to use
something like older SCSI interfaces, you can still get the cards. The
PC world is pretty good at backwards compatibility.

and file system no longer supported by new system(s), is more common a
I'd be impressed if you can think of a file system that is a realistic
candidate for such a situation, and which is not supported by Linux.

[%X]

Wonder how many remember as far back as the Kansas City Tape Standard
for Data Recording onto Audio Cassettes. If really pressed I could
still cobble

grin> Or folks who used "VCR data recorders" manufactured
iin somebody's garage...

one of those up. However, if it was really important data to keep,
then it should have been subject to a migration policy so that it was
appropriately transferred to modern media.

*This* is the key issue here! 20 years ago I spent several weeks
takiing everything that I had archived (floppies of various
sizes, 9 track tape, a slew of other oddball tapes, etc.) and
copied it onto "modern media". Since then, every project
has been added to the pool.

I keep backups on a RAID5 array, additional copies on my
regular workstation (for more recent work or anything that
I want to "have a look back at"), other copies on CD's
and DVD's (these are POOR choices, IMO) and on DLT. The
most vulnerable of these are those on rotating media
as you can lose it *all* in a single ohnosecond! If
possible, find an external drive that has a hardware write
protect switch if you want to go that route...

You /can/ lose data on hard disks fairly quickly, but typically you have
to be very unlucky (assuming you make your backups write-protected for
normal use). It's a good idea to have two independent copies on
different computers, in different locations - you are not going to have
hard disk fails, fires, or human error on both systems at once.

The *good* thing about archives is they don't change
often. So, you (i.e., *I*) don't have to repeat this process
very often -- just incrementally update it.

You don't have to repeat it too often, but you /do/ need to check your
restoration procedures regularly. This is particularly true if you rely
on tape and/or specific backup programs - have you tested the tapes on
an independent system (hardware and software)?

Jon Kirwan wrote:
On Fri, 6 Nov 2009 23:00:15 +0000 (UTC), Andrew Smallshaw
andrews at (no spam) sdf.lonestar.org> wrote:

On 2009-11-05, Paul Carpenter <paul at (no spam) pcserviceselectronics.co.uk
wrote:
Despite C, being free format, avoid too much free format,
remembering that at some time it may well be printed, 300
character lines wrap very interestingly, if they wrap. Choosing
indentation matching can make following the code easier, even if
you have managed to get the function to fit on one page.
I keep getting criticism for ignoring an imagined 80 column limit.
Yes, I'll keep it under 132 columns but not 80 - it just gets too
restrictive and demands either less indentation of cyptically short
variable names which are a much bigger problem. 132 (sometimes
136) is of course how long a line can be printed on a wide carriage
printer, so it is largely historical now, although is does
approximate what enscript -r can fit on a sheet of A4 with default
settings. With modern text editors under GUIs you are typically
not limited to anythign like 80 column views so I see no practical
reason to stick to such a narrow limit.

I stay with a strict 79 column limit. It turns out that I also
print my listings on the laser printer in portrait mode and that
with the use of commonly available fixed-pitch fonts like Courier
or Prestige Elite I get just about the right font size for
readability, as well.

I couldn't possibly consider 132 columns as acceptable anymore. I
still have the boxes of printer paper designed for that, but long
since lost printers with the sprockets to feed the paper. Use it
for scratch paper, now. And printing landscape, while acceptably
printing at 132 columns fixed-pitch, puts too few lines on the
page. Readable code requires that the basic idea is presented (as
well as possible) on a single page (or perhaps two.) The few lines
that I wind up wrapping do NOT add anywhere near enough extra
vertical lines to cause a problem. While printing landscape would
lose way too many lines and would definitely become a readability
problem for me.

I guess different people come to different, strongly held
conclusions.

Jon

Its pointless to print out code today due to lack
of tractor feed printers. What happened to them?
To me, a stack of non-contiguous
sheets has very little value.

Its pointless to print out code today due to lack
of tractor feed printers. What happened to them?

To me, a stack of non-contiguous sheets has very little value.

Andrew wrote:

Its pointless to print out code today due to lack
of tractor feed printers. What happened to them?

Nothing unusual: their typical application range reduced from
near-universal to a rather small niche. My car mechanic's shop, e.g.,
still relies on needle printers(!) with tractor feeds.