Skip to content

Commit

Permalink
Updated.
Browse files Browse the repository at this point in the history
  • Loading branch information
lhecking committed Jun 14, 1999
1 parent 2161f2f commit 9ab7869
Show file tree
Hide file tree
Showing 3 changed files with 34 additions and 34 deletions.
60 changes: 29 additions & 31 deletions CodeStyle
Original file line number Diff line number Diff line change
@@ -1,10 +1,12 @@
$Id: CodeStyle,v 1.7 1999/06/10 20:05:42 lhecking Exp $
$Id: CodeStyle,v 1.8 1999/06/14 19:17:37 lhecking Exp $

The following things have be observed when writing new code for gnuplot:
(this file is currently under construction) Some of the following is
just personal bug-bears, so dont take any offense if something I
moan about is something you think is good style...

These rules were originally written up by David Denholm, and I keep
updating them as I go along. -Lars


MISSING FUNCTIONS, AND FUNCTIONS TO BE AVOIDED
Expand Down Expand Up @@ -90,39 +92,33 @@ prototypes have to be enclosed in a special macro, e.g.

int strcmp __PROTO((char *s, char *t)); /* note the double ()'s */

Function definitions, on the other hand, must be done in
k&r style (which ANSI compilers accept).
Probably from gnuplot release 3.7.1 on, I will require that
all function declarations and definitions are in ANSI style.
I see absolutely no point at all in ignoring the benefits of
ANSI compilers, almost ten years after this language became
an ISO standard.

int strcmp(s,t)
char *s, *t;
int
strcmp(char *s, char *t)
{
...
}

While compilers do not require that explicit declarations be
given for integer arguments, we do !


On platforms which use the included configure script, the ansi2knr
tool in the src subdirectory is invoked transparently if the compiler
doesn't support prototypes (Ultrix, SunOS 4.x). Other platforms may
require explicit rules or additional makefiles for non-ANSI/ANSI
compilation. The man page for ansi2knr is included. Note that for
ansi2knr to work, the function return type must be on a separate line,
or, to quote from the ansi2knr manual, "ansi2knr recognizes functions
by seeing a non-keyword identifier at the left margin, followed by a
left parenthesis, with a right parenthesis as the last character on
the line."

If a function has an argument which has a default promotion (char, short,
float), this could cause problems with some strict ANSI conforming compilers.
In this case an alternate function header must be used, e.g.

#ifdef PROTOTYPES
char *foo(char s)
#else
char *foo(s)
char s;
#endif

but since there's no benefit from using a character as parameter, may
as well use the int ie.
char *foo(s)
int s;

gcc -Wtraditional might help with this.
[char parameters should be avoided. int can safely be used in this case.]

While compilers do not require that explicit declarations be
given for integer arguments, we do !


While ANSI compilers can use prototypes for implicit typecasts, k&r
Expand All @@ -135,7 +131,7 @@ code on non-ansi compilers.

[we will definitely give up k&r support in the near future, but
since existing code seems to work with k&r, we're sticking
with it.
with it for the time being.
]


Expand Down Expand Up @@ -202,9 +198,11 @@ putting set ts=4 into your ~/.exrc file.

Unfortunately, gnu indent does not seem to recognise this
as a layout style. If it did, I'd have run all sources
through it long ago. [GNU indent -kr -cp0 -l100 -lps comes
pretty close, though. I need very little manual editing after
running this, mostly for long (> 80 cols) lines. -Lars]
through it long ago. [GNU indent -kr -cp0 -l132 -lps -br -psl
is what I use. Very little manual editing is necessary after
running this, mostly for long (> 80 cols) lines. Anyway,
I don't care which indentation style _you_ use, I'm running
all code through indent and be done with it. -Lars]



Expand Down Expand Up @@ -242,7 +240,7 @@ Unary operators should be writen as usual, ie i++.


No C++ style comments (//).
No comments on #ifdef/#ifndef lines.
No trailing comments on #ifdef/#ifndef lines.
No #error and #warning directives.

[more to come]
2 changes: 1 addition & 1 deletion PATCHLEVEL
Original file line number Diff line number Diff line change
@@ -1 +1 @@
0.8
0.9
6 changes: 4 additions & 2 deletions TODO
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,8 @@ Lars' list
- much-requested feature: read text/commands from data files
- provide library of replacement functions instead of stdfn.c
- possibly switch to automake
[PARTIALLY DONE] not done yet: docs lisp src tutorial
[PARTIALLY DONE] not done yet: docs lisp
[docs is next; won't do lisp]
- completely rewrite the parser. Use yacc/bison if possible.
- maybe rewrite the scanner in lex? The benefits are not so obvious,
because the current scanner is extremely simple. This is probably
Expand Down Expand Up @@ -69,8 +70,9 @@ Lars' list
- better lisp/ files integration (Makefile target to import Bruce's
latest version). How to handle duplicates?
- better documentation format; get rid of the doc2xxx utils
- move src/* subdirs to toplevel?
[SGML. SGML. SGML]
- update the FAQ!!!!
[Being worked on bei Juergen]
- non-integer time value in 'pause' command
- tilde and variable expansion to be done by
gp_fopen() - to be implemented
Expand Down

0 comments on commit 9ab7869

Please sign in to comment.