Software Design
9 messages in this thread
John,
I have been following your conversation with Steve and thought I would
throw in a few cents. I am a developer for Martin Marietta. I have
been writing software for 5 years: 4 years of PL/1, FORTRAN, COBOL
on a mainframe and 1 year developing in C on Sun platform. I have
seen many styles of implementation; some good, some bad. One thing
that has, IMO, hindered our development efforts are requirements to:
1) Name all software components (.c, .h, functions, variables, etc)
using a given standard.
2) Provide detailed prologues for every function (Roughly, a page or
more in length)
3) Deleting debug statements from software before building to controlled
library
4) Style guides for code development: e.g. placement of braces
if (TRUE) {
}
v.s.
if (TRUE)
{
}
Now, the question I ask myself is, what value is added to the software
by requiring these things?
1) Some of our variable names, and function names are 32 or more chars.
They become unreadable for the most part, and hard to maintain. As
long as names are logical, this reqt. doesnt add anything. (Use of
emacs and tags makes following software a breeze, anyway)
2) Multipage prologues per function are a huge overhead. Good comments
are all that are needed.
3) No sense at all. I must admit, my latest project does not require
this (Use of #if's, asserts is a must!).
4) Some value here. I would prefer programmers to write all statements
using {}'s so that a future programmer can add statements within
{}'s. e.g. if (TRUE) { done = TRUE;} v.s. if (TRUE) done = TRUE;
That would be the extent of my reqt however.
Anyway, I hope to make some changes on my project to maximize
maintainability while minimizing bureaucracy.
Take care!
Dan Barber
Software Design Engineer
barber@mdso.vf.ge.com
My opinions are my own, and not representative of Martin Marietta Corp.
1. Have you ever encountered the "Hungarian" notation for variable names as
recommended by Microsoft for Windows programming? I had to work on code like
this for a while, I didn't see the great advantages, either, and it would get
cumbersome. Some was handy, like 'sz' prefixes on zero-terminated string ptrs.
2. Again, I agree. My experience tells me that comments can have bugs and it
doesn't affect the performance of the program, so SQA doesn't care. 🙂
3. If you have a relatively foolproof way to leave the debug statements in the
program, but ifdef'd out, then no problem. One way is to only activate the
debugging by compiling the module in a strange way that doesn't happen in a
regular link. Another way I detect this is with debugging messages sprayed out
the serial port or a debugging monitor.
4. I prefer the first method, the old K & R method. As long as someone is
consistent, I can handle it. I prefer to put braces on every instance where
control can branch: every if, every while, every for, even if only one
statement.
> 1. Have you ever encountered the "Hungarian" notation for variable names >
as recommended by Microsoft for Windows programming? I had to work on code >
like this for a while, I didn't see the great advantages, either, and it >
would cumbersome. Some was handy, like 'sz' prefixes on zero-terminated >
string ptrs.
I find hNotation good for languages that don't have good type support – like
Clipper or dBase. I think Windows used it because C had no way of
differentiating between their various handles and pointers and stuff. Don't
ask me for examples – the first thing I do when programming in Windows is
#define STRICT to eliminate these problems.
> 4. I prefer the first method, the old K & R method. As long as someone > is
consistent, I can handle it. I prefer to put braces on every instance > where
control can branch: every if, every while, every for, even if only > one
statement.
I quite agree. When I first started out, I had an incredible amount of trouble
with:
if (TRUE)
do_this();
and then adding an extra line to it:
if (TRUE)
do_this();
and_that();
without the { }. Indentation can be misleading in these cases.
>I find hNotation good for languages that don't have good type support – like
>Clipper or dBase. I think Windows used it because C had no way of
>differentiating between their various handles and pointers and stuff.
When I find myself boxed into such a requirement, I look to another
language. This is of course not always possible. I forget exactly why
Simoni (sp?) concocted the thing, I believe I recall it as a mixture of a
bunch of things. My main gripe is that it buys little. This is much
detriment to believing the id name too. Anyway, throwing type info in a
"meaningfull id name" (what we're supposed to do IMO) just rubs me the
wrong way. Again, I realize one doesn't always have unlimited possibilities
in their choice of language. In those cases I tend to still prefer a strong
disciplined approach. Both ways has their problems of course.
>1) Name all software components (.c, .h, functions, variables, etc)
> using a given standard.
Yes, things like this can often be good. Lots can be said for consistency.
>2) Provide detailed prologues for every function (Roughly, a page or
> more in length)
The length is not an issue for me, the explanation is though.
I want to know stuff like the expected input, expected output,
at least general algorithm taking place. That the _minimum_ comments
I want to see.
>3) Deleting debug statements from software before building to controlled
> library
I'll disagree with this for a number of reasons. Some are simply practical.
Others, in the spirit of some of this thread is that some debug statements
can actually take the form of enhancing the clarity of the code. OTOH,
perhaps we are not speaking of the same types of debug statements.
>4) Style guides for code development: e.g. placement of braces
Yes, though this is a hard one as there are many forms of things like this.
I've been reading this string with a lot of interest, and thought I throw
in my two cents worth. I've been doing Software in the Aerospace Industry
for 20+ years, I've used several assembly languages, FORTRAN, COBOL, Space
Programing Language, Jovial, C, and now Ada. The one thing I've learned
is that while once you get into an HOL the only thing that really makes a
difference in the product is between your ears. Most of the improvements
I've seen in SW engineering have more to do with how you look at the
problem than what language you use. I will agree that some languages are
a lot more fun to use (they'll need a gun to get me back to COBAL), but
the most important thing is good discipline and intellegence.
CAM
Chris,
yes! I emphasize the discipline.
Brian
You are right that the thing that makes a a different is "between your
ears."
The whole point of human-computer interfaces is to shape the way the user
thinks about the problem domain in order to make the computer easier to
understand. I think this applies to languages just as well as GUIs. Each
languages encourages you to think a different way, from a different angle.
Dale Larson
– An Amiga Software Engineer with some time on his hands.
Hi,
Just thought I'd jump in and reccomend 2 very good books by Microsoft Press.
They are:
Code Complete and Writing Solid Code
Both books have some very good ideas related to varible names, debugging,
software design, testing, and much much more. These should be required reading
by any serious programmer!
There are also a few good Yordon books… But they seem a little out dated.
Read as much as you can, then use the methods that are best for the
situation. I feel the most important thing is being consistent. This is even
more important if you work in a group.
-Troy