Finites State Machine (OT?)

[Jeffrey C. Dege]

Maybe not, but it sounds more like bravado to me. An _effective_
programmer keeps both ends of his loops on the same page.

I don't get concerned if they're on adjacent pages.

But I once had to explain my coding style after some suits had run some
metrics against a large project I'd been the primary programmer for.

The average LOC/method was five.

They thought that was excessive.

But they wondered at the fact that 20% of the methods were one line long.

And got serious heartburn over the fact that nearly 5% of the methods
measured zero lines long.

They could not grasp why we were wasting time writing functions that
had nothing in them.

 

[John Larkin]

Maybe not, but it sounds more like bravado to me. An _effective_
programmer keeps both ends of his loops on the same page.

Cheers!
Rich

Let's see... this one I'm working on starts on page 28 (I always
number my pages) and ends in the middle of 51. I guess I'm not
_effective_.

John

 

[Jeffrey C. Dege]

Let's see... this one I'm working on starts on page 28 (I always
number my pages) and ends in the middle of 51. I guess I'm not
_effective_.

No loop that long can be easy to read or to maintain, though some patterns
can be easier than others.

There are, though, issues other than ease of maintenance that can
sometimes make such cumbersomely structured code the best solution.

But circumstances where that is true are rare.

 

[John Larkin]

No loop that long can be easy to read or to maintain, though some patterns
can be easier than others.

There are, though, issues other than ease of maintenance that can
sometimes make such cumbersomely structured code the best solution.

It's not cumbersome, it's beautiful. And it's easy to read and
maintain because it's superbly commented. It's a great program because
it wasn't written by a programmer.

John

 

[John Miller]

It's not cumbersome, it's beautiful. And it's easy to read and
maintain because it's superbly commented. It's a great program because
it wasn't written by a programmer.

You mean, kinda like, "it's a great circuit because it wasn't put together
by a designer?"

 

[Richard Henry]

Let's see... this one I'm working on starts on page 28 (I always
number my pages) and ends in the middle of 51. I guess I'm not
_effective_.

That depends. How long is your design document? How thick are your
comments?

 

[Jeffrey C. Dege]

It's not cumbersome, it's beautiful. And it's easy to read and
maintain because it's superbly commented. It's a great program because
it wasn't written by a programmer.

Comments don't fix bad structure.

--
Nearly every electrical engineer believes deep in his heart that he
is better at writing computer software than any computer programmer,
and can show as proof the fact that he has written a number of small
applications, each of which was done quickly, easily, and exactly met
his needs.

 

[John Larkin]

You mean, kinda like, "it's a great circuit because it wasn't put together
by a designer?"

Not exactly. Electronic design is a fairly mature process, and most
hardware engineers are competent or better, and there is a large body
of accepted practice (like synchronous state machines, among others)
that most people follow. Programming seems to me to be, in general, a
hit-and-miss mess. There are some excellent programmers and software
around, but it's mostly an undisciplined mess. I know of a couple of
big companies whose critical software is "spinning out of control", a
mangled mess of millions of lines of revs and bugs and patches. I've
seen some Windows source code, and it's a nightmare, literally "code"
that has to be traced with difficulty to see what's going on. Bugs are
admitted, embarassing failures in hardware design, but are considered
routine in programming.

I think the current C++/Windows programming paradigm wrecks the
thought process of kids who take CS courses nowadays. And learning
embedded stuff in Pics doesn't help one think in data structures and
state machines, either. Modern programming is path oriented (the
program counter *is* the process state) rather than system state
oriented.

John

 

[John Larkin]

That depends. How long is your design document? How thick are your
comments?

Well, there's the product manual (including specs), the schematic and
support docs (pcb layout, bom, test procedure, etc), a Xilinx FPGA
project file (schematic!), the uP source code (68K assembly), a GO.BAT
file to build it all, and a README.TXT to explain what's going on. All
formally released to the company library. Manufacturing burns a single
ROM per unit, from a released .ROM file. The comments in the source
code are its documentation, and comments outweigh code by maybe 6:1 on
a character basis.

Really, embedded programming is so simple.

John

 

[Richard Henry]

Well, there's the product manual (including specs), the schematic and
support docs (pcb layout, bom, test procedure, etc), a Xilinx FPGA
project file (schematic!), the uP source code (68K assembly), a GO.BAT
file to build it all, and a README.TXT to explain what's going on. All
formally released to the company library. Manufacturing burns a single
ROM per unit, from a released .ROM file. The comments in the source
code are its documentation, and comments outweigh code by maybe 6:1 on
a character basis.

Not adequate.

Really, embedded programming is so simple.

I can see why you think so.

 

[John Miller]

There are some excellent programmers and software
around, but it's mostly an undisciplined mess.

Well, when you're right, you're right. I'm torn, because I want to argue
both sides of this simultaneously. The only graceful retreat I can manage
is to say that the folks who perpetrate the undisciplined messes aren't
what I'd call programmers. Let me elaborate:

In companies that live or die by their software, star programmers are pretty
much at the top of the social pecking order, as determined by respect
they've earned by their peers.

In corporations for which IT is just a means to an end, programmers are,
regrettably, pretty much the lowest form of IT life. They are generally
managed by folks who were politically -- as opposed to technically -- savvy
enough to have risen out of the programmer ranks. So is it any surprise
that corporate code is generally a couple of notches below "mediocre"?
Companies that deal with programmers in that way (compensation, management)
are reaping what they have sown.

I feel very fortunate to have worked (before retirement) in a Fortune 50
consumer goods company that paid their programming employees as much as
$130,000, and gave them a voice. It was certainly the exception for
non-technology companies.
--
John Miller
Email address: domain, n4vu.com; username, jsm

The greatest productive force is human selfishness.
-Robert Heinlein

 

[John Larkin]

Comments don't fix bad structure.

But the very act of typing comments forces one to review the logic and
state things clearly, sort of like how explaining it to someone else
forces you to review a design. If I can't comment it precisely, it
tells me that I don't really understand it, and it's probably too
complex.

State machines are often distributed in code space: this guy sets a
flag (say, a request to write to serial eeprom), and another block
later picks it up and does something else (the very slow write
sequence) as a result. Cross-comments are vital here.

John

 

[John Larkin]

Not adequate.

Most C code I've seen has about a 6:1 ratio, only reversed.

I can see why you think so.

Because it's quick and easy, and always works.

John

 

[Jeffrey C. Dege]

But the very act of typing comments forces one to review the logic and
state things clearly, sort of like how explaining it to someone else
forces you to review a design. If I can't comment it precisely, it
tells me that I don't really understand it, and it's probably too
complex.

If the comments don't match the code, odds are that they're both wrong.

State machines are often distributed in code space: this guy sets a
flag (say, a request to write to serial eeprom), and another block
later picks it up and does something else (the very slow write
sequence) as a result. Cross-comments are vital here.

Absolutely.

 

[Stephen Sprunk]

Maybe not, but it sounds more like bravado to me. An _effective_
programmer keeps both ends of his loops on the same page.

An experienced professional (in any discipline) knows that while rules of
thumb are generally applicable, sometimes the most effective solution
requires a different approach _and documents the heck out of it, including
rationale_.

S

 

[Richard Henry]

Most C code I've seen has about a 6:1 ratio, only reversed.

By "not adequate", I was not referring to the weight of comments.

Two things bother me. One is the apparent lack of evidence of a controlled
requirements->specification->design->code->test process. The other is the
long loop. I strive to keep all routines to a single page, or at most two
pages that can be viewed together. I will admit to having multi-page
switch/case structures when there was just no other way to get all the cases
written in.

 

[Rich Grise]

Not exactly. Electronic design is a fairly mature process, and most
hardware engineers are competent or better, and there is a large body
of accepted practice (like synchronous state machines, among others)
that most people follow. Programming seems to me to be, in general, a
hit-and-miss mess.

Well, to me, it's not. But then again, I'm neither typical nor John Larkin.

I lost a job once because I embarrassed a staff of three degreed programmers
who didn't know their ass from a hole in the ground. I was a temp at the
time doing "document coding," which is a lot like data entry, but with some
decision-making involved. At just above minimum wage.

This outfit was using Paradox on a little LAN, and these idiots had
ONE instance of the software running on the server, and 32 Windows 3.1
machines acting, essentially, like dumb terminals, but didn't know it.

It seems Paradox has this magical command, "coedit." "Magical" (with
maximum sarcasm) in that they didn't have a clue what it was doing -
there were 32 users all dicking with one database file. It was so slow
that users would have to stop after typing a line, and wait for it to
get around to echoing the damn line to see if they had made any typos.

In about a week, I'd rewritten the app such that each user would create
a data record, and hit the "send" button, which would then just write
one record, sequentially, to the file on the server. Instantaneous
(virtually ) response.

I showed the supervisor how much better it worked, and by the time I
got home that day, the temp agency had already called: they "Didn't
need me."

Go figure.
Rich

 

[John Larkin]

By "not adequate", I was not referring to the weight of comments.

Two things bother me. One is the apparent lack of evidence of a controlled
requirements->specification->design->code->test process. The other is the
long loop. I strive to keep all routines to a single page, or at most two
pages that can be viewed together. I will admit to having multi-page
switch/case structures when there was just no other way to get all the cases
written in.

A programming language and its processors are just an impedance
matching system between the way a person thinks and the way a machine
executes instructions. So different people will have preferred, and
more suitable, approaches to programming. I'm an engineer (I write
from sci.electronics.design) and I think in state machines, hardware
registers, and microseconds. So my preferences are...

If it's only used once, it shouldn't be a subroutine

Signals (and code) flow from top to bottom

The best control structure is a jump. That's all the CPU does.

It's easier to read if it's linear

Comment correctly and thoroughly. Be funny if you can.

Avoid abstraction at all cost. But structures are golden.

Program in assembly. C rots your mind.

You *must* archive the entire tool chain with the rest of
the project, as a formal release, if you hope to be able
to maintain it longterm.

Of course, this is embedded, bare-metal, hard realtime stuff, without
an os. Most of the work is done in smallish state machines that run at
interrupt level. I wouldn't want to write a web browser this way.

I had a psychology professor who had been in training research in
WWII. He was trying to improve the sorry performance of waist/tail
gunners in bombers. One day, just as "final exams" were about to
start, he grabbed the graduating class of the Cooks and Bakers School
and sent them up instead of the gunnery students. They shot better.

The best four programmers I personally know (I modestly include myself
at the bottom of the list) are two ee's, a chemist, and a PHD in
thermal hydraulics. None have taken any CS courses. Interesting.

John

 

[Rich Grise]

A programming language and its processors are just an impedance
matching system between the way a person thinks and the way a machine
executes instructions. So different people will have preferred, and
more suitable, approaches to programming.

These two statements are contradictory.

I'm an engineer (I write
from sci.electronics.design) and I think in state machines, hardware
registers, and microseconds. So my preferences are...

If it's only used once, it shouldn't be a subroutine

Signals (and code) flow from top to bottom

The best control structure is a jump. That's all the CPU does.

It's easier to read if it's linear

Comment correctly and thoroughly. Be funny if you can.

Avoid abstraction at all cost. But structures are golden.

Program in assembly. C rots your mind.

You *must* archive the entire tool chain with the rest of
the project, as a formal release, if you hope to be able
to maintain it longterm.

If you really believe this is true, then I have sympathy for your
employer, unless he's really that easy to snow. (i.e. a fool)

Every one of these is the exact opposite of good programming
practices. If I were an employer, then any idiot who calls himself
a programmer, who demonstrates this shoddy, slipshod, devil-may-
care approach to programming, wouldn't even get his foot in the
door.

Good Luck, you'll need it.
Rich

 

[Jeffrey C. Dege]

This outfit was using Paradox on a little LAN, and these idiots had
ONE instance of the software running on the server, and 32 Windows 3.1
machines acting, essentially, like dumb terminals, but didn't know it.

I once turned down a job because they were use Paradox to run their
payroll system.