What coding standard are you using for C?

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

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.

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.

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

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'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")

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! :< ).

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.

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

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)

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

You're preaching to the choir, here... :> Though I don't consider any (many?) thing as non-negotiable.

I don't know if I would make that assumption. Consider almost everything is in function scope so you *start* off with one level of indentation. Damn near any construct you employ will add at least one more level.

Nest some loops and throw a switch inside and you've added several more levels.

In my case, my preference for lengthy identifiers leads to using up lots of "width" quickly. This is especially a problem when arguments to function calls get lengthy.

I prefer to wrap conditionals in a do-while and then break out of that construct instead of layering conditionals. But, the do-while itself adds a level of indent...

It's hard to arbitrarily "decree" that you can limit the levels of indent just to satisfy some arbitrary (?) restriction on line length. As I said, everything is a *guideline* not a *rule*.

I did not suggest that Andrew Smallshaw adopt my standard. Just observing that he would probably hate complying to it. I am also well aware of teh title of the thread and had already supported the adoption and enforcement of a decent coding standard that makes the software intent clear, unambiguous and easy to read and understand.

--
********************************************************************
Paul E. Bennett...............
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

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.

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.

Backwards compatibility of different sorts, especially of tools and proprietary file formats, is a real problem. But there is no need to invent mythical problems in addition.

Useless backups are a real issue - many people forget that the most important aspect of a backup is having a working and tested restore procedure that is independent of the original hardware and software. But that is a very different issue from being unable to read or work with files.

We are talking about source code here - primarily for C code. You can edit it with 30 year old vi or the latest Eclipse. If you manage to find an editor that is so poor it cannot deal with different line endings (such as windows notepad), and are for some reason incapable of using a better editor, you can use utilities like unix2dos to change them. If you are using some bizarre non-ASCII encoding, you can get utilities to convert from them. But for the basic character set critical to programming languages, almost nothing but ASCII has been used for the 32-127 character range for the last 30 years. This is a totally fabricated problem in the context of C source code. If we were talking about word processor formats, or other binary closed proprietary file formats, then I could agree to a fair extent - but we are not.

And how often do you need to write files on one OS, and use them later of another? Not very often, in practice. And how often do you /need/ to use a crippled editor? Almost never (though people /do/ use crippled editors, they rarely need to do so). And how many people need to use files created with one OS's idea of a line ending in a crippled editor on another OS, and are incapable of using dos2unix/unix2dos or using a decent editor to swap the line endings? I'd say none that are qualified to work as embedded systems engineers.

That's just paranoia. You'd have to be trying seriously hard to write C code that requires specific fonts to be legible. There is a limit to the sort of micromanaging that makes sense.

What is the problem with making a printout of your code using a reasonable editor, printed out on whatever sort of paper and whatever sort of printer you typically use at the office? This really is not rocket science - anyone who has trouble making legible printouts of their code is in the wrong job. And while it is quite possible that the code you are working with has to run on fifteen systems, compiled by twelve year old tools on ten year old hosts, there is no such requirement for the system used to write, store, and print out the code.

Unless you store or edit your source code on your MP3 player, this is totally irrelevant!

Perhaps I am missing something here (in fact, I am /sure/ I am missing something here), but it sounds to me like you are taking the short life span of MP3 players and using it as an argument to limit source code lines to 80 characters.

I regularly work on a ten year old computer, as well as one a couple of years old. I run mostly the same software on each. And for my embedded development tools in particular, I keep all the old versions as well as new versions. It's something you have to consider, but it's not /that/ hard.

For tools such as those used in embedded development, old versions /are/ often available. You should, of course, do your best to keep copies of all versions you have used, but decent commercial suppliers will be able to provide you with old tools if you need them. Open source tools are typically available in archives stretching far back (though if you go far enough back, you may have to compile them yourself).

The discussion was never (to my understanding) about the active lifespan of the C code and its use in projects. It was about your claims that it could be difficult to work with C files more than two years old due to incompatibility of media, file systems, line endings, fonts, printers, character encodings, etc.

Can you give me an example of a situation where C source code files are /not/ stored in straight ASCII files?

[%X]

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

--
********************************************************************
Paul E. Bennett...............
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

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

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

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.

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

*I* used to think that way! I kept backups on external SCSI drives that were neither "on-line" (mounted) nor *spinning* (powered up).

On one occasion, I needed to restore a file from one of these "offline archives". I spun-up the drive, mounted the filesystem and the drive *crashed*!

OK, bad luck.

But, I have a *second* backup drive (drives are cheap insurance). So, I pulled that drive out, spun it up, mounted it ... and watched *it* crash!

Turns out there was a bug in the driver that this model of drive tickled. Very reliably. I.e., I could have had *20* such drives and it would have dutifully scrambled *all* of them!

Note that the only thing I "did wrong" here was not using the write-protect jumper on the drive before installing it in its enclosure.

Undaunted, I moved on to my CD archive and was able to restore the file from a CD. If that had failed, I would have fallen back to tapes.

And, then turned my attention to the "computer" to see what the problem was, there.

Point is, if you *assume* things, you get bitten. My assumption was that I could NEVER have two hard drives fail at the same time. And, *neither* of them did! I later re-copied the portion of my archive that resided on these two (duplicate) drives *back* onto them.

Of course! The windows system is (as always) the PITA. So, I just backup it from one of the UN*X boxen so I'm just dealing with "files" and not some stupid proprietary "backup format" (been there, done that, t-shirt to prove it).

I have six or seven DLT's here so I am not dependant on "working hardware". And several different machines that can read and write the archives portably. Instead of chasing the latest and greatest "PC hardware", I'd rather invest in having duplicates of *everything*!

Backups are precious. I treat them as such. :>

Tractor feed printers are still decidedly available. There's a pretty regular stream of HP Quietjets on eBay for cheap, though you can go broke buying the teensy little ink bullets for them. Or if you're doing real volume, I've seen some tractor fed lasers. They're the size of a Mini Cooper, horrifically expensive, and move whole forests of paper through.

--
Rob Gaddi, Highland Technology
Email address is currently out of order

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.

Well, staples and ring binders exist.

One of the local office supply stores here still carries them, though I'll admit to having been surprised to see one on display.

Somewhere, in some box or other, I still have one of those motorized ribbon re-inker gadgets and most of a pint of ink (or, what's left after the vehicle has evaporated).

Ahh... those were the days. ;-)

--
Rich Webb     Norfolk, VA

For many applications in business, a dot matrix printer is still the only solution, especially if you use multipart forms for receipts, local and accounts copies etc. It's also the cheapest and least complicated solution as well.

I don't print much code listings now, but always use laser printer in landscape mode to get 132 column width, to match the output of the editor. If you use meaningfull, english like variable names, it doesn't take long to exceed 80 col width, even with 4 space indent...

Regards,

Chris