student project

will happen.

That's bullshit and lame excuses. Allocate x3 more of time and money for projects, and you will be amazed how better the things could be. Otherwise reconcile to what you are getting. The result is absolutely logical and it doesn't require superstitious explanations.

VLV

ants

writting comments for every line is almost worse than no comments, we all know things change and if there's too many comments they never get updatet and then you end up with code that does one thing and comments that say it does something else, which is truly terrible to try and do anything with.

imagine reading a book where every sentence was followed by an explanation, either the book is poorly written if everything needs explaining, or the writer is wasting time writing explanations for something that was already obvious.

-Lasse

It's really annoying to see a heap of C that just starts off with code. There's usually no hint of what the program is for, what it does, who wrote it, what it's called when it's put together, or what it runs on. And if there's a README file, it usually starts off with something like

ver 2.3.145beta4. Fixed bug in SPF linked-list thunk

(etc)

Again, not even the name of the program.

A computer program ought to be managed as engineering documentation. There is an entire software culture that has no idea what than means, and wouldn't go along if they did. No wonder a bug per 10 lines of code is the norm.

John

Then don't do that. Keep the comments right. READ and CHECK your own damned code.

John

You mean, "Only real programmers"

"Jamie's Brick Yard, We lay anything"

SEMI-USELESS BRIGHTNESS FACTOR

same program later.

;-)

and then compains for 6 month in newsgroups about C programmers and C.

I never claimed to be a great programmer. I am careful and most of the stuff I ship does what it's supposed to do and has zero bugs.

What's your ratio of coding/debugging? Mine's above 1.

John

I just wish software was as reliable as plumbing.

Of all the technology we do, software is the worst.

John

S*it goes downhill and payday is on Friday. You are now a plumber.

Maybe programmers should be paid on Friday. That would cut in half problem space, leaving the programmer only the direction of s*it to get right.

Come back and boast when it's above 50.

Debuggers are the first resort for bad programmers, but the last resort for good ones. Good programmers write tests first.

Sounds like you've worked with bozos, and you blame that on C. Perhaps you should find a better way to select your programmers, instead of blaming their tools.

Clifford Heath.

Not quite true. There were CP/M FORTRAN compilers for the Z80 and they were used in anger in some quarters for embedded control work. There was no chance at all of using standard I/O in embedded stuff though. You had to develop and debug your own embedded I/O library.

Scientists seemed to like it because it avoided them learning a new language. It was used that way in the mid-80's when small single board control computers became relatively commonplace in labs. C eventually displaced FORTRAN in that arena. A few enlightened labs used Modula2.

I once ported a rather large mainframe non-linear optimisation program onto a Z80 FORTRAN with 64k of memory using an overlay linker for a bet (I won). But it could only do toy problems of 128 pixels. I found several IBM extensions used in the codebase that were not implemented in the much stricter Z80 compiler. These changes of humble origin later saved us time with optimisation when it was put onto a Cray.

SEMI-USELESS BRIGHTNESS FACTOR

It is interesting to dissect this gloriously commented statement as it reveals plenty about the author. The comment is meaningless and indicates only that the author does not understand the definition of gamma correction in imaging. This is borne out by the fact that he allows an output range of 999.99 to -99.99. Gamma seldom lies outside the range +/- 0.2 - 5.0 for soot and whitewash respectively.

I might as well rail about the way professional circuit diagrams do not show the explicit colour band codes next to every resistor.

Commenting every line is an irrelevant distracting detail stating something that is obvious to practitioners in the art. Commenting lines where something tricky is being done that is not obvious and needs careful explanation is important (like a deliberate fetch from some other page to force certain badly behaved memory managers to prefetch new data). Otherwise someone who doesn't understand it will come along and remove the "obvious" mistake.

I particularly find annoying assembler commented by morons which frequently reads like this:

MOV AX,345 move 345 into AX INC CX add 1 to CX

And it is even more annoying when some maintainer has changed CX to DX without altering the comment so now you have an inconsistency!

INC DX add 1 to CX

I *know* what the machine instructions do. I want to be told the inputs, outputs, invariants, any assumptions and an overview of the algorithms that are being implemented in a program *NOT* the tedious minutiae of individual lines of code. It saves time if the comments also refer back to the page/paragraph number in the specifications.

Whilst I agree that there are aspects of C hacker culture that are at least partly responsible for the mess that commercial software is in there are good programmers in C too. It is not the language so much as the way it is used. Or more accurately the way software development is managed. BASIC done badly can be even more of a maintenance nightmare with its global variables and monolithic slab structure.

Methinks you doth protest too much. You would not get far in modern design without Spice simulation, chip design and PCB layout software.

Regards, Martin Brown

thinking about how good BASIC is.

Historically the excessive use of global variables by its practitioners allows for too many unexpected interactions and side effects. Most Basic implementations are actually partial intepretters or JIT compilers rather than global optimising compilers. The few global optimising Basic compilers do work pretty well.

Actually that is not necessarily the case. Some languages lend themselves to expressing vector parallelism in a form where the compiler can better utilise hardware resources for instance.

Should be but they almost never are. These days the best profile directed optimising compilers on a pipelined architecture can usually beat all but the most skilled hand coders on the real hot spots (ie the people who write the templates for code generation). But it doesn't make any sense to expend that amount of compiler effort on the rest of the bulk code so it is compiled to something fairly decent.

But some languages are much harder to optimise safely than others. FORTRAN and C pose particular problems for the optimiser where raw pointers are passed into a routine as arrays. Other languages with array descriptors can determine if there is a potential conflict and optimise accordingly - C has to assume worst case behaviour to be safe or be explicitly told it is allowed to make the risky optimisations.

Regards, Martin Brown

One could say the same about circuit designers too - particularly the board layout specialists of old who basically just did the tapework and restricted human access and interaction to a few grunts.

Both professions have their share of oddballs. But I cannot accept that computer science graduates can get straight A's without commenting or verifying their work and provided proof of same. At least not in the UK.

I am inclined to agree. Though you can get away with that on some types of modest sized project where the practitioners are all at a very high level. But it does increase the risk of hidden bugs.

You must visit some awful dark ages dumps then. This was standard practice in the mid 80's as was a changes list. The code I worked on always had its module name internally (a language requirement).

I could not agree more and it should have a separate specification of what it is supposed to do that is *not* the executable code and is readable and checkable by the customer. Inability of the customer to check what they are getting is a major factor in development overruns and late expensive changes in the requirements.

So many of the irritating faults are down to the software being defined by whatever it happens to do. I was trying to set up a new password for a bank account and their blasted web page required me to tab over fixed fields during data entry. How dumb is that? It also crashed horribly at the end with the sort of classic sysnurdle error message that we both hate. Along the lines of "Internal Error: SAC_1089".

You are more than an order of magnitude high there. Actually the claimed industry norm is 2 bugs per KLOC in shipped code.

But when I run aggressive static testing against an established codebase I find about that rate and I am sure it doesn't find them all.

Microsoft claim about 0.5 per KLOC in shipped product which I think is optimistic and 10-20/KLOC at the internal testing (which is too high). But they do have some pretty good tools and methods internally - problem is they also have pressure to ship for first mover advantage.

It is infuriating that the sorts of metric and analysis tools that should be being used and taught in universities are only available in the vastly overpriced enterprise editions of MS tools. The problem with most university projects is that the really talented students can hack out a solution and then create the appropriate documentation later. This method does not scale well on much larger projects.

Regards, Martin Brown

It's interesting to watch engineers on the first tea break on 'seminar' days.

I have wondered if the slight social ineptitude is an engineer thing or would you get the same with a bunch of doctors/architects who don't know each other.

Nial

I write in Motorola assembler and QBASIC (gonna start on power BASIC soon, thanks to Larkin) and I comment every line as well as at the head of modules in order to explain what's supposed to be done.

I got bit on the ass a couple of times by _not_ doing it, and I've found that the little extra time taken to comment is very much less than the huge amount of time taken to try to find out what in the hell the programmer was thinking about in the first place.

will happen.