Slinky Question

[buck rojerz]

"Bill Garber" <willy46pa@comcast DOT net> wrote in
news:dKCdnbMW9u7hjzrdRVn-vw@comcast.com:

"Rich Grise" <null@example.net> wrote in message
news:4EDpc.130479$G_.76119@nwrddc02.gnilink.net...
: "buck rojerz" <inorbit@outerspace.org> wrote in message
: news:Xns94EADFC309243ou812@216.168.3.44...
:
: > Holy Cow! That's the most complicated method of F to C that
I've ever
: > seen. Try this one. I was told about it about almost 20
yeara ago.
:
: > F + 40 / 1.8 - 40 = C
: > C + 40 X 1.8 - 40 = F
:
: > Perform them in the order indicated. I don't recall the
"Agebraic rule"
: > of whether X & / are performed first or if + & - are
performed first and
: > that rule might screw it up, as shown. I should have paid
more attention
: > in math class.
:
: (F - 32) C
: -------- = ---
: (212 - 32) 100
:
: Cheers!
: Rich

After a quick Google search, here are the correct
formulae for converting Farenheit to Celsius and
back.

Celsius = (Fahrenheit - 32) * 5/9
Fahrenheit = Celsius * 9/5 + 32

Bill @ GarberStreet Enterprizez };-)
Web Site - http://garberstreet.netfirms.com
Email - willy46pa @ comcast DOT net
Change DOT to a dot to contact me

This is also true. This is the one I recall from school. I suppose
which ever road one chooses, if the answer is correct, the formulae is
true.

I am certainly no mathematician.(I may not even spell very well)

Thanks
buck

---
This email ain't infected, dude!

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.678 / Virus Database: 440 - Release Date: 5/7/04

 

[Bill Garber]

"buck rojerz" <inorbit@outerspace.org> wrote in message
news:Xns94EBCBB8329F7ou812@216.168.3.44...
: "Bill Garber" <willy46pa@comcast DOT net> wrote in
: news:dKCdnbMW9u7hjzrdRVn-vw@comcast.com:
:
: > "Rich Grise" <null@example.net> wrote in message
: > news:4EDpc.130479$G_.76119@nwrddc02.gnilink.net...
: >: "buck rojerz" <inorbit@outerspace.org> wrote in message
: >: news:Xns94EADFC309243ou812@216.168.3.44...
: >:
: >: > Holy Cow! That's the most complicated method of F to C
that
: > I've ever
: >: > seen. Try this one. I was told about it about almost 20
: > yeara ago.
: >: >
: >: > F + 40 / 1.8 - 40 = C
: >: > C + 40 X 1.8 - 40 = F
: >: >
: >: > Perform them in the order indicated. I don't recall the
: > "Agebraic rule"
: >: > of whether X & / are performed first or if + & - are
: > performed first and
: >: > that rule might screw it up, as shown. I should have paid
: > more attention
: >: > in math class.
: >:
: >: (F - 32) C
: >: -------- = ---
: >: (212 - 32) 100
: >:
: >: Cheers!
: >: Rich
: >
: > After a quick Google search, here are the correct
: > formulae for converting Farenheit to Celsius and
: > back.
: >
: > Celsius = (Fahrenheit - 32) * 5/9
: > Fahrenheit = Celsius * 9/5 + 32
: >
: > Bill @ GarberStreet Enterprizez };-)
: > Web Site - http://garberstreet.netfirms.com
: > Email - willy46pa @ comcast DOT net
: > Change DOT to a dot to contact me
: >
:
: This is also true. This is the one I recall from school. I
suppose
: which ever road one chooses, if the answer is correct, the
formulae is
: true.
:
: I am certainly no mathematician.(I may not even spell very
well)
:
: Thanks
: buck

There was a time long ago that I could calculate where
a certain star would be in years to come, and now, I can
barely balance my checking account. Thank GOD for online
banking or I'd be totally lost. 8o)

Bill @ GarberStreet Enterprizez };-)
Web Site - http://garberstreet.netfirms.com
Email - willy46pa @ comcast DOT net
Change DOT to a dot to contact me



---
This email ain't infected, dude!

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.678 / Virus Database: 440 - Release Date: 5/6/04

 

[buck rojerz]

"R. Steve Walz" <rstevew@armory.com> wrote in
news:40A7BBE2.2A72@armory.com:

buck rojerz wrote:

nospam <nospam@nospam.invalid> wrote in
news:lifca0haposhn178i2pf83d67gjrnpm4is@4ax.com:

maxfoo <maxfooHeadFromButt@punkass.com> wrote:

On Sat, 15 May 2004 08:17:47 GMT, B Thomas
thomasb@math.ohio-state.edu> wrote:

Hi,
Is there any utility to convert units from one to another?
sincerely
b thomas


This is my favorite one...

Convert is an easy to use unit conversion program that will convert
the most popular units of distance, temperature, volume, time,
speed, mass, power, density, pressure, energy and many others,
including the ability to create custom conversions!

http://www.joshmadison.com/software/convert/

I'm sure there are lots of others and started to write one myself.

Is there much interest in these utilities? Should I carry on?

My design is like a 2 column spread sheet with units in one column
and values in the other. Modifying a value for any unit
automatically converts and displays that value for all other units.
A drop down list at the top lets you select quantities like length,
area, pressure etc.

The whole thing is configured by a user customisable .ini file with
sections like

[Temperature]
K = x, x, f
C = x - 272.15, x + 272.15, f
F = ((x - 272.15) * 9 / 5) + 32, ((x - 32) * 5 / 9) + 272.15, f


[Energy]
Joules = x, x, f
kgm = x / 9.80665, x * 9.80665, f
lbft = x * 1.355818 + 1, x / 1.355818, f


Holy Cow! That's the most complicated method of F to C that I've
ever seen. Try this one. I was told about it about almost 20 yeara
ago.

F + 40 / 1.8 - 40 = C
C + 40 X 1.8 - 40 = F

Perform them in the order indicated. I don't recall the "Agebraic
rule" of whether X & / are performed first or if + & - are performed
first and that rule might screw it up, as shown. I should have paid
more attention in math class.

buck
----------------------
Uh, those are silly, and wrong.

40 * 1.8 = 40 + 32, so C + 40 * 1.8 -40 = C + (40 + 32 - 40),
which is stupid.

Yes, you are correct, IF you perform the string algebraicly as shown.
How ever if you do the calculations individually, it does work. I was
very mistaken to have displayed it in an algebraic form as I did.

(F)75 + 40 = 115

115 / 1.8 = 63.3333

63.3333 - 40 = (C)23.888

See, I should have presented it, in this manner at first. My mistake.
I like this one, because it seems easier to do on a common 4 function
calculator, because you handle each result in turn without having to
remember any numbers or use any parens.

I do appreciate all of the responses, however.

buck

Just use F = C * 9/5 + 32 and C = (F -32) * 5/9

And by the way, parens first then mult/div, then add/sub.

-Steve

 

[Terry Given]

"buck rojerz" <inorbit@outerspace.org> wrote in message
news:Xns94EBCAA92B00ou812@216.168.3.44...

Chuck Harris <cfharris@erols.com> wrote in news:40a7654f$0$3041
$61fed72c@news.rcn.com:

Bill Garber wrote:

The rule is MADS, multiply, add, divide, subtract.
This only applies to figures that are not enclosed
in brackets or parentheses.

No it isn't!

For common arithmetic:

M>y <D>ear <A>unt <S>ally
Multiply, Divide, Add, Subtract.

-Chuck


Ok... Thanks to you as well, Chuck.

buck

more complete: BEDMAS
Brackets
Exponents
Division
Multiplication
Addition
Subtraction

Terru

 

[Chuck Harris]

Terry Given wrote:

more complete: BEDMAS
Brackets
Exponents
Division
Multiplication
Addition
Subtraction

Terru

I've never seen division given more precedence than
multiplication.

It's easier and clearer to throw in a few brackets and
eliminate all doubt.

-Chuck

 

[Terry Given]

"Chuck Harris" <cfNOSPAMharris@erols.com> wrote in message
news:40b1f342$0$3120$61fed72c@news.rcn.com...

Terry Given wrote:

more complete: BEDMAS
Brackets
Exponents
Division
Multiplication
Addition
Subtraction

Terru

I've never seen division given more precedence than
multiplication.

It's easier and clearer to throw in a few brackets and
eliminate all doubt.

-Chuck

M,D are interchangeable, as are A,S. BEDMAS just reads better than BEMDSA
thats all.

you are not wrong about extra brackets though. Especially when mutilating
equations with ascii

Terry

 

[Chuck Harris]

Terry Given wrote:

It's easier and clearer to throw in a few brackets and
eliminate all doubt.

-Chuck


M,D are interchangeable, as are A,S. BEDMAS just reads better than BEMDSA
thats all.

you are not wrong about extra brackets though. Especially when mutilating
equations with ascii

Terry

When I first started programming in C, I followed the conventions of
the programmers who wrote Unix Edition 6. They liked to show off how
tricky they were and wrote in the most terse way possible. Somewhere
along the journey, I got tired of having to puzzle out my old code, and
started writing code that was easy to understand. The same assembly
code comes out of the compiler either way... well, today's compilers
anyway.

-Chuck

 

[Terry Given]

"Chuck Harris" <cfNOSPAMharris@erols.com> wrote in message
news:40b2a1dc$0$3142$61fed72c@news.rcn.com...
[snip comparitively trivial stuff]

When I first started programming in C, I followed the conventions of
the programmers who wrote Unix Edition 6. They liked to show off how
tricky they were and wrote in the most terse way possible. Somewhere
along the journey, I got tired of having to puzzle out my old code, and
started writing code that was easy to understand. The same assembly
code comes out of the compiler either way... well, today's compilers
anyway.

-Chuck

Amen brother. Just because you can be a smart-arse doesnt mean you should ;}

The problem with terse code (and almost all cunning code falls into this
category too) is that its never very well documented. A year or five later,
it becomes someone elses nightmare. Often sooner - programmers move from job
to job, just like everyone else.

My pet peeve is people who (over-) use conditional assignments. Invariably
these compile to the same damn code as a nice IF statement. A terse IF can
be equally bad. I personally favour the following:

1) header blocks that detail the inputs, outputs, memory & stack usage,
interrupt level, execution time etc. along with descriptions & expected
ranges of all input, local, global & output variables
2) description of task to be performed. If a mathematical
simplification/derivation is required, show it explicitly.
3) pseudocode algorithm
4) meaningful, helpful comments interspersed with code.
5) all cunning stunts clearly documented, in both the header and the code.
Specifically mention any prerequisites,eg flags set
6) use meaningful variable names in conjunction with so-called "hungarian
prefix notation" - agree upon a syntax that can describe all the variables
you will need, say AKPUW_current_gain_setpoint[] would be an Array of
Konstant Pointers to Unsigned Words, in this context probably used with
indirect addressing to gain-schedule a current controller (dont forget to
publish the standard. it should be a controlled document, just like a pcb
cad library
7) likewise use a standard format for laying out code (indenting etc)


most programmers HATE 6 and 7. I dont know why. yes it takes a bit more
typing (in theory; not much in practice). And it makes debugging and peer
reviews so much easier to do, allowing many obvious faults to be spotted
immediately (why are you writing a byte to that constant signed word? how
come you call that function from two different interrupt levels yet it uses
static local variables? etc). But no, some (most? what do others think?)
programmers behave like primadonnas, throwing hissy fits dare one suggest
such things "its art, you know, dont stifle my creativity". And many
engineering organisations put up with it, where they wont for drawings, cad
libraries etc. Oops, actually IME lots of companies do a terrible job of
controlling things like cad libraries and drawing revisions. And
consequently make numerous stupid, time consuming and costly mistakes.
usually again and again and again....

Cheers
Terry

 

[Richard Henry]

"Chuck Harris" <cfNOSPAMharris@erols.com> wrote in message
news:40b2a1dc$0$3142$61fed72c@news.rcn.com...

When I first started programming in C, I followed the conventions of
the programmers who wrote Unix Edition 6. They liked to show off how
tricky they were and wrote in the most terse way possible. Somewhere
along the journey, I got tired of having to puzzle out my old code, and
started writing code that was easy to understand. The same assembly
code comes out of the compiler either way... well, today's compilers
anyway.

Bravo!

 

[Mike]

On Tue, 25 May 2004 14:25:33 -0700, Terry Given wrote:

1) header blocks that detail the inputs, outputs, memory & stack usage,
interrupt level, execution time etc. along with descriptions & expected
ranges of all input, local, global & output variables
2) description of task to be performed. If a mathematical
simplification/derivation is required, show it explicitly.
3) pseudocode algorithm
4) meaningful, helpful comments interspersed with code.
5) all cunning stunts clearly documented, in both the header and the code.
Specifically mention any prerequisites,eg flags set
6) use meaningful variable names in conjunction with so-called "hungarian
prefix notation" - agree upon a syntax that can describe all the variables
you will need, say AKPUW_current_gain_setpoint[] would be an Array of
Konstant Pointers to Unsigned Words, in this context probably used with
indirect addressing to gain-schedule a current controller (dont forget to
publish the standard. it should be a controlled document, just like a pcb
cad library
7) likewise use a standard format for laying out code (indenting etc)

Years ago, I took a VHDL class. At the beginning of the class, we were
covering operators, and I asked what the operator precedence was. "I don't
know," said the instructor, "And I don't care. If you write code that
doesn't make it clear what you're doing, then you're making your code
harder to read, harder to maintain, and more susceptible to mistakes."

He was right. Today, I remain convinced that creating highly structured,
fully documented, _unambiguous_ code and schematics is one of the most
important things I do.

Years before I took the VHDL class, we hired a consultant to write some
code. What we received was 4000 lines of assembly without one single
comment (except the first line, which was the name of the source code
file). A coworker explained this in a way that has been echoed many times
throughout my career: "Job security. If it's not documented, you can't get
rid of him, since he's the only one who can change it."

Bob Lewis, who writes for Infoworld, put job security in much better terms:
Your value to a company is directly proportional to your ability to be
replaced. It seems completely backwards, but I'm convinced it's true. You
can only move to a new project or be promoted if someone can take your
place, and nobody can take your place if you're the only person who can
maintain some inconsistent, unreadable, undocumented pile of crap. If all
you can produce is that aforementioned dungheap, you're pretty near
worthless.

-- Mike --

 

[Jim Thompson]

On Mon, 24 May 2004 22:21:14 -0700, Mike <mike@nospam.com> wrote:

[snip]

Years before I took the VHDL class, we hired a consultant to write some
code. What we received was 4000 lines of assembly without one single
comment (except the first line, which was the name of the source code
file). A coworker explained this in a way that has been echoed many times
throughout my career: "Job security. If it's not documented, you can't get
rid of him, since he's the only one who can change it."

[snip]
-- Mike --

I wouldn't accept work-product that isn't documented... circuit
designs OR software code. You are foolish if you do.

I've been recently discovering that I can't remember WHY some of my
old circuits work. I've thus started documenting again like I did in
my 20's, and digging thru my old work and adding documentation ;-)

...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice480)460-2350 | |
| E-mail Address at Website Fax480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |

I love to cook with wine. Sometimes I even put it in the food.

 

[Chuck Harris]

Jim Thompson wrote:

On Mon, 24 May 2004 22:21:14 -0700, Mike <mike@nospam.com> wrote:

[snip]

Years before I took the VHDL class, we hired a consultant to write some
code. What we received was 4000 lines of assembly without one single
comment (except the first line, which was the name of the source code
file). A coworker explained this in a way that has been echoed many times
throughout my career: "Job security. If it's not documented, you can't get
rid of him, since he's the only one who can change it."


[snip]

-- Mike --


I wouldn't accept work-product that isn't documented... circuit
designs OR software code. You are foolish if you do.

It's not always that the programmer doesn't want to document, often
his boss has so seriously underestimated the project that there isn't
enough time to do the job, let alone document it. I have had clients
put *serious* pressure on me to "go with the flow" and document the job
in some ficticious time that will be found *later*. I have refused, and
I have gotten fired as a result.

-Chuck

 

[Jim Thompson]

On Tue, 25 May 2004 16:29:44 -0400, Chuck Harris
<cfNOSPAMharris@erols.com> wrote:

Jim Thompson wrote:
On Mon, 24 May 2004 22:21:14 -0700, Mike <mike@nospam.com> wrote:

[snip]

Years before I took the VHDL class, we hired a consultant to write some
code. What we received was 4000 lines of assembly without one single
comment (except the first line, which was the name of the source code
file). A coworker explained this in a way that has been echoed many times
throughout my career: "Job security. If it's not documented, you can't get
rid of him, since he's the only one who can change it."


[snip]

-- Mike --


I wouldn't accept work-product that isn't documented... circuit
designs OR software code. You are foolish if you do.

It's not always that the programmer doesn't want to document, often
his boss has so seriously underestimated the project that there isn't
enough time to do the job, let alone document it. I have had clients
put *serious* pressure on me to "go with the flow" and document the job
in some ficticious time that will be found *later*. I have refused, and
I have gotten fired as a result.

-Chuck

Ah, yes. I have been "fired" several times. Rehired as much as two
years later to save the project. Amazing how much that can cost ;-)

...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice480)460-2350 | |
| E-mail Address at Website Fax480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |

I love to cook with wine. Sometimes I even put it in the food.

 

[Dave VanHorn]

I make no claims to sainthood, but I normally write the comments first, then
flesh them out to details, then as I keep detailing, I end up having to
write code.

Of course it's different when the spec has changed for the nth time.
Keeping the comments in sync with the code is harder.

 

[Tim Wescott]

Terry Given wrote:

"Chuck Harris" <cfNOSPAMharris@erols.com> wrote in message
news:40b2a1dc$0$3142$61fed72c@news.rcn.com...
[snip comparitively trivial stuff]

When I first started programming in C, I followed the conventions of
the programmers who wrote Unix Edition 6. They liked to show off how
tricky they were and wrote in the most terse way possible. Somewhere
along the journey, I got tired of having to puzzle out my old code, and
started writing code that was easy to understand. The same assembly
code comes out of the compiler either way... well, today's compilers
anyway.

-Chuck



Amen brother. Just because you can be a smart-arse doesnt mean you should ;}

The problem with terse code (and almost all cunning code falls into this
category too) is that its never very well documented. A year or five later,
it becomes someone elses nightmare. Often sooner - programmers move from job
to job, just like everyone else.

My pet peeve is people who (over-) use conditional assignments. Invariably
these compile to the same damn code as a nice IF statement. A terse IF can
be equally bad. I personally favour the following:

1) header blocks that detail the inputs, outputs, memory & stack usage,
interrupt level, execution time etc. along with descriptions & expected
ranges of all input, local, global & output variables
2) description of task to be performed. If a mathematical
simplification/derivation is required, show it explicitly.
3) pseudocode algorithm
4) meaningful, helpful comments interspersed with code.
5) all cunning stunts clearly documented, in both the header and the code.
Specifically mention any prerequisites,eg flags set
6) use meaningful variable names in conjunction with so-called "hungarian
prefix notation" - agree upon a syntax that can describe all the variables
you will need, say AKPUW_current_gain_setpoint[] would be an Array of
Konstant Pointers to Unsigned Words, in this context probably used with
indirect addressing to gain-schedule a current controller (dont forget to
publish the standard. it should be a controlled document, just like a pcb
cad library
7) likewise use a standard format for laying out code (indenting etc)


most programmers HATE 6 and 7. I dont know why. yes it takes a bit more
typing (in theory; not much in practice). And it makes debugging and peer
reviews so much easier to do, allowing many obvious faults to be spotted
immediately (why are you writing a byte to that constant signed word? how
come you call that function from two different interrupt levels yet it uses
static local variables? etc). But no, some (most? what do others think?)
programmers behave like primadonnas, throwing hissy fits dare one suggest
such things "its art, you know, dont stifle my creativity". And many
engineering organisations put up with it, where they wont for drawings, cad
libraries etc. Oops, actually IME lots of companies do a terrible job of
controlling things like cad libraries and drawing revisions. And
consequently make numerous stupid, time consuming and costly mistakes.
usually again and again and again....

Cheers
Terry

At the very least every 'C' and 'C++' file should be headed with

// We don't need no steenking comments!

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[Joel Kolstad]

A comment:

Tim Wescott <tim@wescottnospamdesign.com> wrote:

6) use meaningful variable names in conjunction with so-called "hungarian
prefix notation" - agree upon a syntax that can describe all the
variables you will need, say AKPUW_current_gain_setpoint[] would be an
Array of Konstant Pointers to Unsigned Words, in this context probably
used with indirect addressing to gain-schedule a current controller
(dont forget to publish the standard. it should be a controlled
document, just like a pcb cad library

Personally, I think Hungarian notation is more trouble that it's worth _when
using modern tools_. By that I mean that all the tools I've used in the
past handful of years easily let you click on any object's name and find its
declaration, its actual type, etc. Not only does having something like
AKPUW in front of object names make the overall code less readible, but it
also tends to be at odds with 'information hiding' and 'abstraction' in that
I shouldn't _have_ to know that Current_Gain_SetPoint happens to be an array
of blah blah blah -- the operations I want to do with Current_Gain_SetPoint
should 'just work' because the person who designed the class made that the
case, or the compiler should complain that what I'm attempting isn't doable
anyway. (And while one then might still choose to, say, start performing
typecasting in some quick hack to make the code work, I'm all for throwing
up roadblocks in front of folks before they take the 'hack' route!)

Likewise, I also hate code that looks like this:

class SetpointClass // Skip 'class'
float SetPointSetting; // Skip 'SetPoint' -- sheesh!
....
SetpointClass mySetPointClass;
mySetPointClass.SetPointSetting=5.0;

You could convince me that on microcontrollers with lesser development tools
a SMALL amount of Hungarian notation is useful (e.g., pVar=...), but in my
experience people easily get carried away.

The reset of your suggestions I generally agree with.

most programmers HATE 6 and 7.

I imagine on #7 they don't object to a formatting all the code the same way,
they object to that formatting not being the way _they_ want it formatted!
I.e., they don't object to _a_ standard, they object to _the_ standard.

And it makes debugging and peer
reviews so much easier to do, allowing many obvious faults to be spotted
immediately (why are you writing a byte to that constant signed word? how
come you call that function from two different interrupt levels yet it
uses static local variables? etc).

They is the kind of thing that -- with proper design -- a compiler is better
at catching than people are. I'll readily support strongly typed languages,
for instance... although I do think that C++ does a much better job in that
it can be bypassed if you know what you're doing, whereas in VHDL there's no
escape (i.e., in C++ there's plenty of potential for abuse but also
potential for 'common sense,' whereas in VHDL you're simply not trusted,
period).

But no, some (most? what do others
think?) programmers behave like primadonnas, throwing hissy fits dare
one suggest such things "its art, you know, dont stifle my creativity".

If I'm being hired on a contract I'll do your Hungarian notation or whatever
other oddities the man wants.

And many engineering organisations put up with it, where they wont for
drawings, cad libraries etc.

I used to work at a place where the PCB layout guy had a directory structure
such that the then-current project was in a directory named "\old
stuff\junk". (He had gotten a newer hard drive -- hence the 'old stuff'
directory -- and the project had grown out of some experiments he started
with in his 'junk' directory.) :-( He also wasn't a believer in version
control software such as PVCS or SourceSafe, and hence had dozens of copies
of the same file ("widget.pcb" "widget old.pcb" "widget 03.pcb" "widget
new.pcb" "widget new new.pcb" arrrgggh!) lying around. Made trying to find
the most current version of any of his stuff most entertaining.

---Joel Kolstad

 

[Terry Given]

"Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> wrote in message
news:c90ibk$clb$1@news.oregonstate.edu...

A comment:

Tim Wescott <tim@wescottnospamdesign.com> wrote:
6) use meaningful variable names in conjunction with so-called
"hungarian
prefix notation" - agree upon a syntax that can describe all the
variables you will need, say AKPUW_current_gain_setpoint[] would be an
Array of Konstant Pointers to Unsigned Words, in this context probably
used with indirect addressing to gain-schedule a current controller
(dont forget to publish the standard. it should be a controlled
document, just like a pcb cad library

Personally, I think Hungarian notation is more trouble that it's worth
_when
using modern tools_. By that I mean that all the tools I've used in the
past handful of years easily let you click on any object's name and find
its
declaration, its actual type, etc. Not only does having something like
AKPUW in front of object names make the overall code less readible, but it
also tends to be at odds with 'information hiding' and 'abstraction' in
that
I shouldn't _have_ to know that Current_Gain_SetPoint happens to be an
array
of blah blah blah -- the operations I want to do with
Current_Gain_SetPoint
should 'just work' because the person who designed the class made that the
case, or the compiler should complain that what I'm attempting isn't
doable
anyway. (And while one then might still choose to, say, start performing
typecasting in some quick hack to make the code work, I'm all for throwing
up roadblocks in front of folks before they take the 'hack' route!)

horses for courses. I am only ever involved with embedded software, (lots of
8051, various DSPs) the tools for which are generally nowhere near as good
as PC tools. The Hitachi SH2 C compiler was a nightmare.....couldnt reliably
make it use its own multiply instruction...ARGH! I have yet to attend a peer
review using anything other than paper that was as successful as the paper,
but I suppose a data projector might work (IME people get all carried away
with the computer, and stop thinking).

This actually opens up the whole 'C' pointer can of worms (pointers are at
the root of almost all programming fuckups (programmers are of course
responsible)). I just want the code to be so clear that ANYONE with a basic
engineering education can read it and understand it. In this regard,
abstraction is a bad thing - there arent that many instances (pun
unintentional) where a routine should not have to know what it is dealing
with (eg abstract data structure). Mostly the routine knows exactly what it
is fiddling with, and the abstraction is merely to comply with some
arbitrary comp.sci. "rule" that says thou shalt abstract.

Likewise, I also hate code that looks like this:

class SetpointClass // Skip 'class'
float SetPointSetting; // Skip 'SetPoint' -- sheesh!
...
SetpointClass mySetPointClass;
mySetPointClass.SetPointSetting=5.0;

You could convince me that on microcontrollers with lesser development
tools
a SMALL amount of Hungarian notation is useful (e.g., pVar=...), but in my
experience people easily get carried away.

I wish they would! vars like i, ii and iii make for horrid-to-read code.
even worse are a,b,c etc. Invariably I want to know what the programmer is
trying to do, followed closely by why.

The reset of your suggestions I generally agree with.

most programmers HATE 6 and 7.

I imagine on #7 they don't object to a formatting all the code the same
way,
they object to that formatting not being the way _they_ want it formatted!
I.e., they don't object to _a_ standard, they object to _the_ standard.


And it makes debugging and peer
reviews so much easier to do, allowing many obvious faults to be
spotted
immediately (why are you writing a byte to that constant signed word?
how
come you call that function from two different interrupt levels yet it
uses static local variables? etc).

They is the kind of thing that -- with proper design -- a compiler is
better
at catching than people are. I'll readily support strongly typed
languages,
for instance... although I do think that C++ does a much better job in
that
it can be bypassed if you know what you're doing, whereas in VHDL there's
no
escape (i.e., in C++ there's plenty of potential for abuse but also
potential for 'common sense,' whereas in VHDL you're simply not trusted,
period).

I had a problem with a table-driven sin(theta) routine once - looked like
the table was wrong. Tried to run it in turbo-C to debug it, which helpfully
forced all my static const array contents to be 32-bit signed integers
rather than the 16-bit signed integers I asked for. which was no use to me.
So I ported it to Delphii. At compile time, Delphi spat the dummy, and
pointed out a whole bunch of out-of-range constants (they were) which is
what I was looking for. SH2 C happily compiled, and sin(theta) over- and
under-flowed as a result. death to poorly typed languages.

But no, some (most? what do others
think?) programmers behave like primadonnas, throwing hissy fits dare
one suggest such things "its art, you know, dont stifle my creativity".

If I'm being hired on a contract I'll do your Hungarian notation or
whatever
other oddities the man wants.

And many engineering organisations put up with it, where they wont for
drawings, cad libraries etc.

I used to work at a place where the PCB layout guy had a directory
structure
such that the then-current project was in a directory named "\old
stuff\junk". (He had gotten a newer hard drive -- hence the 'old stuff'
directory -- and the project had grown out of some experiments he started
with in his 'junk' directory.) :-( He also wasn't a believer in version
control software such as PVCS or SourceSafe, and hence had dozens of
copies
of the same file ("widget.pcb" "widget old.pcb" "widget 03.pcb" "widget
new.pcb" "widget new new.pcb" arrrgggh!) lying around. Made trying to
find
the most current version of any of his stuff most entertaining.

---Joel Kolstad

I've worked with guys like that. My favourite was the internal pcb layout
"rules" written by the VP of eng (ME, MIT) where he mentions that there are
3 library symbols for pcb-mount faston terminals, but two of them are wrong
so dont use them. I mean duh, why are they still in the library. No prizes
for guessing that their PCB prototypes werent that great - often bits didnt
fit in the holes.....

I posted a list of my books to ABSE BTW

Cheers
Terry

 

[The Real Andy]

On Tue, 25 May 2004 14:25:33 -0700, "Terry Given"
<the_domes@xtra.co.nz> wrote:

"Chuck Harris" <cfNOSPAMharris@erols.com> wrote in message
news:40b2a1dc$0$3142$61fed72c@news.rcn.com...
[snip comparitively trivial stuff]
%

6) use meaningful variable names in conjunction with so-called "hungarian
prefix notation" - agree upon a syntax that can describe all the variables
you will need, say AKPUW_current_gain_setpoint[] would be an Array of
Konstant Pointers to Unsigned Words, in this context probably used with
indirect addressing to gain-schedule a current controller (dont forget to
publish the standard. it should be a controlled document, just like a pcb
cad library
7) likewise use a standard format for laying out code (indenting etc)


most programmers HATE 6 and 7. I dont know why. yes it takes a bit more

I only use hungarian on public and virtuals and the like. I dont see a
real need for it in methods that are not exposed to anyone else. As
for being maintainable, well with good comments on your declerators no
hugarian is really needed. Add to that, within a method everything
that is not declared within the method itself will be a public or
virtual which should already be hugarianised so you know what datatype
it is!!

 

[Terry Given]

"The Real Andy" <.pearson@wayit_dot_com_dot_au_remove_the_obvious_to_reply>
wrote in message news:ecp7b0p0u4bln0sdv6fj7vfm5dugnbht3j@4ax.com...

On Tue, 25 May 2004 14:25:33 -0700, "Terry Given"
the_domes@xtra.co.nz> wrote:

"Chuck Harris" <cfNOSPAMharris@erols.com> wrote in message
news:40b2a1dc$0$3142$61fed72c@news.rcn.com...
[snip comparitively trivial stuff]
%

6) use meaningful variable names in conjunction with so-called "hungarian
prefix notation" - agree upon a syntax that can describe all the
variables
you will need, say AKPUW_current_gain_setpoint[] would be an Array of
Konstant Pointers to Unsigned Words, in this context probably used with
indirect addressing to gain-schedule a current controller (dont forget to
publish the standard. it should be a controlled document, just like a pcb
cad library
7) likewise use a standard format for laying out code (indenting etc)


most programmers HATE 6 and 7. I dont know why. yes it takes a bit more

I only use hungarian on public and virtuals and the like. I dont see a
real need for it in methods that are not exposed to anyone else. As
for being maintainable, well with good comments on your declerators no
hugarian is really needed. Add to that, within a method everything
that is not declared within the method itself will be a public or
virtual which should already be hugarianised so you know what datatype
it is!!

Now implement your ideas in 8051 assembler - oops, look ma no methods. But
yes, if you use sensible variable names the HPN is perhaps unnecessary. My
entire thesis is that software is buggy, so make it easy to debug. Industry
standard practice is 5% error rate for debugged code. Its a lot less than
that for debugged circuitry. If you want to learn how to write real good sw
go look at the space shuttle code - 1 bug per 420,000 lines of code. And its
almost all done without writing code, but by careful and methodical
design/review.

Cheers
Terry

 

[The Real Andy]

On Wed, 26 May 2004 16:00:08 -0700, "Terry Given"
<the_domes@xtra.co.nz> wrote:
%<

that for debugged circuitry. If you want to learn how to write real good sw
go look at the space shuttle code - 1 bug per 420,000 lines of code. And its
almost all done without writing code, but by careful and methodical
design/review.

Look at their budget and I bet they spend a day writing each line
broken down as follows on an eight hour day:

4hours. Initial meeting
2hours. Initial meeting review
1hour and 30 minutes. Peer review of single line of code
30minutes. coffee break before writing line of code.
OT:
1 hour documenting single line of code
1 min. Write line of code.
1 hour. check into source control and verify.

Then off for a week of testing.


PS, all my assembler uses methods.