Re: [Aspell-user] Spell-checking source code

[Greg Ward]

[my requirements]
> I don't care if the error is
> 
>   /* this fucntion adds two numbers */
> 
> or
> 
>   message = "error reeding file";
> 
> or
> 
>   void getRemaningObjects()

[Christoph Hintermüller replies]
> Why do you want to spell check the function name doesn't is sufice to have 
> the 
> compiler complaining about unknown getRmanngObject function name or better 
> implicit declaration if ti appears.

The compiler cannot catch the error if both the declaration and every
use of the function are misspelled: the program is syntactically and
semantically correct and consistent, but identifiers are misspelled.
This often happens when programmers don't know that they're misspelling
a word, or use an editor that finishes partially-typed identifier names
for them.  (This could be "smart" completion like Eclipse does [only
look for names in the right scope], or "dumb" completion like Emacs does
-- it doesn't matter, if the programmer is unaware that what he
originally typed is wrong, neither the editor nor the compiler will
correct him.)

> Or are you looking for somethin like 
> http://www.splint.org/.

Don't think so.  Split claims to be a better lint, and it's specific to C.

> And 
> what would happen if the designated function name doesn'T consist of full 
> words but rather of their abreveiations as full words would make the name 
> rather inreadable.

First, I wrote this for Java programmers, who tend to be rather verbose
and generally don't use abbreviations in identifiers.  (I used to be
annoyed by this, but I'm coming around to see the good side of it.)  I
tried running it on the Python standard library, but was quickly put off
by the heavy use of short, abbreviated identifiers there.

Second, a fair amount of the code I wrote to wrap [ia]spell deals with
custom dictionaries for particular programming languages and projects.
(The idea is that my tool would included "standard" dictionaries -- one
for each programming language that I use regularly [Python, Java, C,
Perl], one for Unix and libc calls, and so on -- and then give users the
option to specify project-specific dictionaries.)  All this stems from
two observations:

  * programming identifiers should probably not be muddled into one's
    personal dictionary, especially if you're working on code with
    several programmers -- the project dictionary belongs in the
    source code repository, not in your home directory

  * I want my tool to run non-interactively, eg. as part of the nightly
    build, or to spellcheck CVS checkin messages.  So the usual
    [ia]spell mode of operation, where the user chooses which words
    to add to her personal dictionary on the fly, is a non-starter.

Anyways, thanks for your input.  I was just curious if I was wasting my
time reinventing a wheel, and it doesn't sound like it.

        Greg
-- 
Greg Ward <address@hidden>                         http://www.gerg.ca/
One man's theology is another man's belly laugh.