What coding standard are you using for C?

In article <>,
says...
> Paul Carpenter wrote:
> > In article <>,
> > says...
> >> On 2009-11-05, Paul Carpenter <> 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.

The old server has gone done and this hard drive uses an interface
and file system no longer supported by new system(s), is more common a
problem than most people think. Then they go to backup and the backup
for that server was not network but tape (and not compatible with any
other drive in the place) or mirred to another drive of same type that
is difficult to interface.

I get questions like this often.

> 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.

Assumptions that all editing is done with GUI, that a suitable font
will be available, that the new tools will always be able to deal
with line endings and non straight ASCII encodings. That printer
or printer driver will not substitute a different font or SIZE.

Even simple Notepad still cannot deal with anything other than
Windows style of line endings. Not uncommon for GUI based tools
to use the OS method of line ending ONLY.

As soon as you have to pick font, including size, you have to document
that probably at the head of each file.

If you do code review MEETINGS do you expect everyone to sit there
looking at screens?


> 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.

Very much so in reality, as mobile phones, MP3 players, components for
desktops, Laptop utilities, PC BIOS, consumer products, change model
about every 6 months or less. Considering warranty time periods and how
long before last unit is sold, the time between LAST release of software
for one model and end of support is about 2 years (often less).

Even for a lot of desktop software, it is always buy the new version
and if necessary a new OS (and system).

So beyond two years they are not even interested in keeping THAT version
of the software. They may have a lot of the modules reused/reversioned
for later models.

So for an AVERAGE lifespan of code that is a reality, some code is much
longer, but the majority of C code is not.

....
> 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.

Proprietary file formats even covers the file system, and if straight
ASCII has been used to store the file.

--
Paul Carpenter |
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

On Sat, 7 Nov 2009 07:33:13 -0800 (PST),
wrote:

>On Nov 6, 6:00*pm, Andrew Smallshaw <andr...@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.

I think that's a point. I do the same thing, mostly because I still
have and use Microsoft's M (or ME) which supports writing your own C
code that can be linked into the editor to extend its features. I've
done that. However, the fact that I can also do a lot of editing with
Windows' editors (IDE or otherwise) means that it isn't quite as much
of an issue for me as it would have been when I was only using that
editor alone.

The printing issue is more important to me partly because straggling
lines that display into the left side margins distract my eye. It's
just enough that I have to _consciously_ ignore them. And that can be
just enough of an annoyance in constructing mental models from reading
that I can be slowed down for a moment. Why have the trouble, at all?

It's also about worrying about others who may read or need to print,
too. Or have their own reasons for preferring an 80 column limit.
(Very few have problems working with 80 or under.) It's not just for
me.

A few days back:

On Thu, 5 Nov 2009 08:57:54 -0000, Paul Carpenter
<> wrote:

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

Tabs are a great question for which I don't have a perfect answer. It
was interesting also to see this on the same day (at my longitude):

On Thu, 05 Nov 2009 15:47:47 -0600, Vladimir Vassilevsky
<> wrote:

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

My own preference is to do space-fill and to use 4 spaces per. With
fixed-pitch fonts, 3 is okay. 2 is too small for my eyes to quickly
recognize in the face of all fonts and characters. So I like at least
3. More than 4 or 5 and it eats up the 80 columns too fast. Which
brackets me, tightly. And using spaces ensures that others see about
what I want them to see -- there is a consistent appearance I can plan
for this way.

Not every program allows for viewing or printing with arbitrarily set
tab stops ... some insist on columns 9, 17, etc. and brook no changes
to that. Use of tabs would wreck some havoc in these cases.

However, there is an argument _for_ tabs when I take into account
others who may also want to read or print my code. Tabs provide the
easy ability for different people to select different preferred
alignments and they work even in the face of proportional fonts, which
some may also prefer for reasons of their own. If I enforce my own
indent requirements by using spaces, I make it more difficult for them
if they really want something other than my own choice.

What nails down the answer to these questions starts with this: I need
and want creative control over the appearance of what I write. There
are times when I need to generate ASCII pictures to help communicate
issues related to the code. I do this often enough that it is very
important. Here's an example of what I mean, which includes a
coroutine diagram, some tables, and examples in order to discuss the
methods I used in writing a fast 8051 float division routine:

http://www.infinitefactors.org/jonk/zips+src/_fsdiv.c

In these cases, and others, using tabs becomes far too much of a
liability in communicating to others. I need to have a lowest common
denominator I can rely upon for communication. Limiting as it is,
this means spaces, not tabs; 80 columns, not more; and fixed-pitch
fonts, not proportional.

Jon

wrote:
> On Nov 6, 6:00 pm, Andrew Smallshaw <andr...@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.

I like to stick to just under 80 columns (i.e., sometimes, the
80th is needed for a newline indication).

The ~80 column limit is advisory, just like other "guidelines".
But, breaking it should only be done "for good reason".

You also have to consider how other people viewing
your code will be affected. Do they use 80x25 xterm(1)'s?
"DOS consoles"?

If they *are* working in a GUI envrionment, do they have
enough desktop space to "waste" on overly wide source lines?
E.g., a GUI debugger usually prepends stuff to each line
(break point indicators, etc.). A scrollbar adds to the
actual width of the window, along with other window decorations.

And, I suspect most folks would like to have other windows
visible on the desktop alongside the "source" window so
the wider you make your source, the greater the impact on
those other windows. (e.g., I like having a schematic
open when I am writing drivers).

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 <> 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.

DJ Delorie wrote:
> D Yuniskis <> 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.

I suspect you use a small-ish font? I like 80x66 xterms -- they
have the "feel" of a sheet of paper -- with reasonably large
fonts (I dislike wearing glasses)

> (*) 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.

I can rotate them independantly of each other and have
tried it. 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.
I.e., with two, you barely have to move your head to
either side of "center" to take in a full screen;
with three you actually have to twist your neck. I
suppose this would be lessened if I pushed the monitors
further away -- but then I would want a larger font
(chicken/egg)

I've also tried going to 24" monitors (instead of 21")
and found that to have pretty much the same problems.

Two works good. I can power one off when I am just writing
code and back on if I need more real estate (e.g., if
I want to look at a schematic and the PCB artwork
created from it).

I have two other workstations on either side of the main
workstation (my work area is arranged in a "U") so I
can truly "spread out" when I need more screen space
(e.g., when I am talking to a target while debugging
on the main desktop)

D Yuniskis <> 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.

DJ Delorie wrote:
> D Yuniskis <> 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.

I'm 9x15 -- probably about 12 point. But, it's nice and
"clean" (well formed letters).

>> 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.

You might explore setting the monitors in the desktops.
I tried it some years ago but found that I lost too
much "real" desktop space -- a soldering iron, paperwork
or something else would invariably end up getting in the
way of a display!

The tops of my current monitors are literally at eye level.
This is too high for me. They can't be lowered (this
would interfere with their rotation -- I guess the
manufacturer wanted to ensure you couldn't lower
them "too low" to prevent that rotation... even if
you don't use it!)

I have two keyboards to contend with -- one on the desktop
and one in a drawer just below. So, raising my chair moves
the lower keyboard out of reach.

>> 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

I'm tighter than that. Maybe 3 feet wide but probably only 15-18"
from my face. I also twist the monitors so they face a common
focus (makes things tighter as a consequence). I doubt my head
even turns 30 degrees in normal usage.

When I had three monitors I had to move them further away to
maintain this same sort of arc. I found this uncomfortable
for viewing (and more real estate than was worth the effort).

This works well enough as I can keep mouse, spaceball, tablet
close enough to be usable without crowding the monitors.
Editing video is a bit clumsy as there is no "close in" room
for that equipment.

Biggest hassle is having to spin the chair to work on targets.
I foolishly fell to the temptation of "symmetry" in laying out
the workstations so the "console" for one target is on my
left while the console for the second target is mirrored on
my *right*! As a result, I often find myself "spinning"
in my chair :< A more practical layout would keep the
targets adjacent and move the primary workstation to one
end or the other (of the "U")

> 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.

I use two when needing to consult a schematic while writing
a driver; or schematic while laying out PCB; or looking at
"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! :< ).

D Yuniskis <> writes:
> "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! :< ).

Why not? I've got a total of four monitors on this PC (the fourth is
elsewhere in my office) and I can drag things from any monitor to any
other montor. I can even expand windows to span multiple monitors if
needed.

Being able to move stuff of my main monitor to a secondary monitor is
a key to the usefulness of this setup.

DJ Delorie wrote:
> D Yuniskis <> writes:
>> "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! :< ).
>
> Why not? I've got a total of four monitors on this PC (the fourth is
> elsewhere in my office) and I can drag things from any monitor to any
> other montor. I can even expand windows to span multiple monitors if
> needed.

Sorry, reread my post. The two monitors can be connected
to two different machines. I.e., I can have monitor 1 on
machine A and monitor 2 on machine B; 1 on B and 2 on A;
or both on A; or both on B. Machines A and B are unaware
of each other (run different OS's, etc.)

If both monitors are on the same machine (A or B), then
moving a window between monitors is no big deal. Or,
ahving a window span two monitors. Or, having the monitors
mirror each other. The problem is when I instinctively
want to drag something from monitor 1, machine A to
monitor 2, machine B. Just because the monitors are
adjacent doesn't mean they are "virtually connected" :>

> Being able to move stuff of my main monitor to a secondary monitor is
> a key to the usefulness of this setup.

Yes. Now try it when one monitor is connected to a PC
and the other is displaying video from a Sun workstation. :>

(I actually *can* do this but not without caveats)

On Sat, 07 Nov 2009 17:15:31 -0700, D Yuniskis
<> wrote:

>
>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*?? :>

Why are books, newspapers and other plain texts usually printed with
column widths well below 80 characters ? Apparently to help people
follow the line and not accidentally skip a line or read a line twice.

Writing very long code lines makes it hard to read the code and you
may have to use extra line spacing or even empty lines around a very
long code line, thus limiting how much you can put on the screen.

It seems that the most common reason for wanting to use wider than 80
characters is the heavy use of indentation, so there might be 50
spaces before the actual code starts. In that case, there are usually
some problems with the program structure design.

Split it to simpler functions or even use "goto" to jump forward to a
descriptive named label after all the various situations have been
handled, instead of using highly nested if-then-else constructs.

Paul