Re: Renaming

[Ben Pfaff]

John Darrington <address@hidden> writes:

> The only other thing I that I'd add to this list at this stage, is
> that I think it'd be worth making some of the names more consistent.
> In particular,  filenames which are derived from two or more English
> words; some are written with underscores, some with dashes, and some
> with no delimeters at all.  I think we should make them all the same.
> I read somewhere that dashes '-' are the prefered GNU standard.

I prefer dashes.

> error.c

=> message.c, I think.  Also pspp-error.h => message.h.  This
will get rid of the namespace conflict with gnulib.

> getl.c
> getl.h

I don't like this name but don't have a great replacement.
line-buffer might be OK but "linebuffer" is already used by
gnulib for what it's worth.

> vfm.c
> vfm.h

=> procedure.[ch] I think.  (There is of course still a lot of
cleanup work to be done here, but I'm not going to get to it for
a while.)

> ./data:
[...]
> cat.c
> cat.h

=> category.[ch] maybe?

> cat-routines.h

(Why is this separate from the above?)

> file-handle-def.c
> file-handle-def.h

=> file-handle.[ch] I think.

> format.c
> format.def
> format.h

We should break out parse_format_specifier*().
parse_format_specifier() and parse_format_specifier_name() are
defined in language/lexer/format-prs.c, so their prototypes
should be in language/lexer/format-prs.h.

> lex-def.c                             identifier.c
> lex-def.h                           identifier.h

I would prefer token.[ch] because I would like to put more of the
lexical knowledge here eventually.

> mkfile.c
> mkfile.h

One routine is only used for HTML output.  Perhaps it should be
in html.c.  Otherwise rename to make-file.[ch]?

> pfm-read.c
> pfm-read.h

=> por-file-reader.[ch]?

> pfm-write.c
> pfm-write.h

=> por-file-writer.[ch]?

> sfmP.h

=> sfm-private.h

> sfm-read.c
> sfm-read.h
> sfm-write.c
> sfm-write.h

=> sys-file-{reader,writer}.[ch]

> val.h

=> value.h

> var.h

=> variable.h

> vars-atr.c

=> variable.c

> ./language/control:
> [...]
> ctl-stack.c
> ctl-stack.h

=> control-stack.[ch]

> ./language/data-io:
[...]
> dfm-read.c
> dfm-read.h
> dfm-write.c
> dfm-write.h

=> data-{reader,writer}.[ch]

> ./language/dictionary:
> apply-dict.c

=> apply-dictionary.c?

> mis-val.c

=> missing-values.c

> sysfile-info.c

=> sys-file-info.c?

> modify-vars.c
> rename-vars.c
> val-labs.c
> var-display.c
> var-labs.c

Expand var/val to variable/value?

> ./language/lexer:
> format-prs.c
> range-prs.c
> range-prs.h

Expand prs to parse?

> subclist.c
> subclist.h

subcommand-list?

> vars-prs.c

variable.c?

> ./language/stats:
[...]
> descript.c

descriptives.c?

> sort-prs.c
> sort-prs.h

sort-parse.c?  (Should this be in language/lexer?)

> ./language/xforms:
[...]
> sel-if.c

select-if.c?

> ./libpspp:
> algorithm.c
> algorithm.h

array.[ch], because they're all array algorithms and I'm planning
to introduce a similar set for linked lists.

> bitvector.h

bit-vector.h?

> pspp-error.h

=> message.h? (already mentioned)

> str.c
> str.h

I guess this should stay str.[ch] to avoid confusion with the
standard header?

> ./output:
[...]
> htmlP.h

Only two things get declared here.  struct html_driver_ext is
only used in html.c so it should be moved there.  The html_class
declaration isn't needed anywhere, except in output.c which
already has its own extern declaration, so it can be deleted.

> som.c
> som.h

=> manager.[ch]

> tab.c
> tab.h

=> table.[ch]

> ./ui/terminal:
> automake.mk
> cmdline.c
> cmdline.h

=> command-line.[ch]

> readln.c
> readln.h

=> something else.
-- 
"Writing is easy.
 All you do is sit in front of a typewriter and open a vein."
--Walter Smith