Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!inpnms!logan
From: logan@inpnms.VSE.COM (James L. Logan)
Newsgroups: comp.lang.c
Subject: Re: portability/maintenance
Message-ID: <582@inpnms.VSE.COM>
Date: 5 Jun 90 00:06:56 GMT
References: <BEVAN.90May29182035@panda.cs.man.ac.uk>
Reply-To: logan@rockville.dg.com (James L. Logan)
Distribution: na
Organization: Data General Telecommunications, Rockville, MD
Lines: 116

In article <BEVAN.90May29182035@panda.cs.man.ac.uk>
bevan@cs.man.ac.uk (Stephen J Bevan) writes:  
# One suggestion was that for large projects (don't ask me to define
# large) a set of standards be drawn up before you start i.e. what
# the indentation style is, where the comments go etc.  These were
# the sort of things I expected to see.

Fine, unless those who decide on the style do not fit in to one of
the mainstream styles.  (Styles were already discussed in another
c.l.c war flamefest.) 

What happens when the people who chose the style leave and no one
knows why they're coding in a style they hate a couple of years
down the road?

# Another suggestion, however, was to use dummy macros to help make
# the type and purpose of parameters and functions stand out.  For
# example, you would have a header file containing the following
# sort of definitions (the rest of this is in K&R I C, I haven't
# really got into the swing of ANSI C yet) :-
# 
# #define PUBLIC
# #define INOUT
# #define IN
# #define PRIVATE static
# #define FORWARD extern

Please don't do this.  See below.

# What I'd like to know is do people acutally use this, and would
# they mind having to maintain code that was written this way?

Yes, people do mind.  In fact, it's completely annoying.

# I've got to admit I kind of like the idea, but if people are going
# to bitch about the code if its written in this style, then I'd
# rather not use it.

They will.  Please don't.

As an example, the psuedo keywords "EXPORT", "IMPORT", and
"PRIVATE" cannot be referenced in C programming books, manuals,
etc., whereas the use of static and non-static variables and
functions are described in definitive C books.  They also
condition the beginner programmers to look for PRIVATE/EXPORT
keywords in 3rd party sources when problems arise.  (As in a 3rd
part database library for instance.) They simply won't find them,
and will find it difficult to adjust.

The psuedo keyword "EXPORT" is misleading because it is not
defined in the C syntax, thus it appears as though it can be
applied to any function or variable.  This is not the case; take
this trivial example for instance:


#include <stdio.h>
#include <unistd.h>

int	file_exists(path)
	char	*path;
{
	int
		retval;

	retval = access(path, F_OK);
	return (retval? 0: 1);
}

char	*mkfullname(path, filename)
	char	*path, *filename;
{
	EXPORT char
		buffer[20];

	sprintf(buffer, "%s/%s", path, filename);
	return buffer;
}

int	main(argc, argv)
	int	argc;
	char	**argv;
{
	char
		*fullpath;

	fullpath = mkfullname(argv[1], argv[2]);

	if (file_exists(fullpath)) {
		printf("You can read '%s'\n", fullpath);
		exit(0);
	} else {
		printf("Sorry, can't read '%s'\n", fullpath);
		exit(1);
	}
	/*NOTREACHED*/
}


Compile it and run it with one argument being a directory and the
second argument being a filename.  Can you tell me why the
filename prints out as garbage?  Beginning to intermediate C
programmers will try things in their code like I have in my
example and will be unable to debug the program.  Can they use a
C manual to figure it out?  Can they use the standards document
to figure it out?  They will have to view the header file to
figure out what it all means.

We need to make our programming environments as efficient and
problem-free as possible, not pretty the C syntax up to the point
where good C programmers (like a good but expensive consultant)
need time to get up to speed in order to understand the code.   

-- 
James Logan                       UUCP: uunet!inpnms!logan
Data General Telecommunications   Inet: logan@rockville.dg.com
(301) 590-3198