Roger (K8RI) wrote:
This was before ANSI C and lint.

I've had more than my share of pre-ANSI compilers... It seems that
nearly every project that I work on, at least one of the machines not
only does not have a C++ compiler for it, it doesn't have one that is
POSIX or ANSI compliant either... As such, you program for the greatest
common denominator -- standard 'C' -- so that you can have a single
piece of source code that compiles across all platforms...

The original C didn't have any type checking. You could add, or
combine anything with anything regardless of type be it an address,
integer, floating point, pointer, array, string, ordinal value, what
ever. It added a new dimension to debugging:-))

But it *built character*... Just look at the quality of developers that
you see these days and it will readily become apparent to you that we
have a *lot* more character than they do...

Never have worked with Ada.

You're not missing much... A language designed my committee -- and it
shows...

"Object Oriented" is really a programming concept although we tend to
think of specific languages such as Delphi and C++ as being Object
Oriented.

Yeah, as I've always said, you can write crap code in *any* language...

If the programmer properly organizes the language he is
using he can create the same inheritance and relationships in most
languages although being able to define a variable as local or global
makes it a tad easier. Of course global makes it easier to defeat the
whole concept too.

Agreed... Allowing the concept of scoping is a quite useful feature in a
language... More often than not though, most code that I've reviewed on
projects believe in basically two levels of scoping -- at the global
level and at the function level... Occasionally, you will see a
developer declare a variable in a local block of code, but it doesn't
seem to happen that often, primarily in some sort of loop counter or
accumulator... From a documentation standpoint though, it looks better
if the variables are defined at the beginning of the functions... Code
should be readable and documentation should be inline so that you can
remember *why* you were doing something a particular way when you have
to come back in a couple of years and modify the code... I like to think
that you should document the code as if you were going to be having it
published in a major publication and subject to peer review... I don't
see that happening with the developers who utilize the MS Visual C++ (or
whatever) type of products... They draw their user interfaces and plug
in the callback actions and about the only comments that you get are
whatever the MS development environment automatically includes in the
code...

You mean something like a number of modules/routines using the same
variable name defined locally and then some one assigns it global? Or
assigning a value to an address that some one else uses for something
else.? I don't know how many times I accidentally assigned global or
local wrongly. I haven't done any programming in C or even C++ in a
long time. (I've been retired 10 years now)

When you are developing a library, you usually have some sort of stub
executable that links in the library for testing during the initial
development... Let's say that you decide to use a variable 'x' in your
library and it needs to be declared by the main module... Let's say that
another library is also expecting a variable 'x'... If the library
routines are not expecting the variable to be modified by another
library routine, there could be issues here... If the first library
instead uses 'AAA_x' and the second library uses 'BBB_x', you've
prevented a collision at link time... Requiring the user of your library
to declare variables is just a core dump waiting to happen though...
It's better style if you have your header file for your library do the
declaring and have it look to see if something is defined before either
declaring the variable or giving a extern reference to the variable...

For example:

--- USER MODULE ---
#define DECLARE_VARS
#include "MYOBJ.h"
#undef DECLARE_VARS
--- USER MODULE ---

--- MYOBJ.h ---
#ifdef DECLARE_VARS
int MYOBJ_x;
int MYOBJ_y;
#else
extern int MYOBJ_x;
extern int MYOBJ_y;
#endif
--- MYOBJ.h ---

On the other hand, if a variable is supposed to be only global to the
modules in your library and not visible to someone linking your module
to their code, you should declare the variable with a storage class of
'static' to minimize the chance that someone could screw something up...

It all boils down to proper programming style... If you want to write
good code in 'C', you can... If you want to write crap code in C++, you
also can...