more complete: BEDMAS
Bravo!
Years ago, I took a VHDL class. At the beginning of the class, we were1) 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)
M,D are interchangeable, as are A,S. BEDMAS just reads better than BEMDSA
I wouldn't accept work-product that isn't documented... circuit
480)460-2350 | |480)460-2142 | Brass Rat |It's not always that the programmer doesn't want to document, often
Ah, yes. I have been "fired" several times. Rehired as much as two
480)460-2350 | |480)460-2142 | Brass Rat |Amen brother. Just because you can be a smart-arse doesnt mean you should ;}
At the very least every 'C' and 'C++' file should be headed with"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
Personally, I think Hungarian notation is more trouble that it's worth _when6) 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
I imagine on #7 they don't object to a formatting all the code the same way,
They is the kind of thing that -- with proper design -- a compiler is better
If I'm being hired on a contract I'll do your Hungarian notation or whatever
I used to work at a place where the PCB layout guy had a directory structure
I only use hungarian on public and virtuals and the like. I dont see a6) 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
Look at their budget and I bet they spend a day writing each line
I can't see them, which is fairly typical of my NG.
A former coworker offers that as a reason that no code should be commented.
It's a valid point, but what I don't want in code, is what you're doing. I
Exactly.
When rewriting, I often leave the previous code in place behind comment
horses for courses. I am only ever involved with embedded software, (lots ofA 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!)
I wish they would! vars like i, ii and iii make for horrid-to-read code.
I had a problem with a table-driven sin(theta) routine once - looked likeThe 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've worked with guys like that. My favourite was the internal pcb layoutBut 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
Now implement your ideas in 8051 assembler - oops, look ma no methods. ButOn 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!!
This is not possible in some of the projects i've worked on. Leaving