Re: Some Advice.

From: Mike Wahler (mkwahler_at_mkwahler.net)
Date: 02/14/04 

Date: Sat, 14 Feb 2004 01:08:56 GMT

"Joec" <joec@annuna.com> wrote in message
news:OdcXb.2968$WW3.1046@newsread2.news.pas.earthlink.net...
>
>
> Karl Heinz Buchegger wrote:
>
> > Mike Wahler wrote:
> >
> >>
> >>Ninth,
> >>
> >>Even after fixing these problems:
> >>
> >> - No standard library identifier qualfications.
> >>
> >> - "game.hpp" #including .cpp files
> >>
> >> - Putting #include guards to fix the duplication
> >>
> >> - two main() functions
> >>
> >>.. I still couldn't build it, because there are no
> >>definitions for the class 'player' member functions.
> >>
> >>Tenth,
> >>
> >>Use #include statements directly in the .cpp files which
> >>use the names in a header. But *only* #include headers
> >>for identifiers that each .cpp file refers to.
> >>
> >>Try again. :-)
> >>
> >
> >
> > Eleventh (without having looked at the code),
> >
> > Don't try to do to much in one big rush. Implement a small
> > feature, compile it, fix compiler errors, test it. Implement
> > the next feature, compile it, fix errors, test it. Ad nauseam
> >
> > This way you know that a compiler error is related to one of the
> > 10 or 20 lines you wrote last. You also know that a runtime problem
> > is related to those 10 or 20 lines and have a starting point for
> > fixing the problem.
>
> That is what I did. It is just that I had to write several parts of the
> program at once to get it to function.

Use what we call a 'test harness' for each function. Then you can
test them without dependency constraints. IMO this is the best
way to develop code anyway.

void foo(/* params */)
{
   /* do your stuff */
}

void test_foo(/* params */)
{
   /* set up data for parameters, etc. */
   foo(/* args */);
   /* examine/display results */
}

int main()
{
    test_foo(/* args */); /* then comment out or delete, then add a call to
next one */
}

Don't be afraid to write 'throw away code'. As a matter of fact,
don't throw it away. Just save it somewhere. It might come in handy
later when you're trying to break things down later, chasing a bug.

-Mike

Relevant Pages

  • Re: Code critique (was equality tester)
    ... designed, not by piling feature on top of feature, but by removing the ... macros) that aren't strictly necessary, but are preferable to the more ... I talk about the ability to compile the code, ...
    (comp.lang.scheme)
  • Q: ARRAY[expanded_type] conforms to ARRAY[ANY]?
    ... a system that compiled fine with the snapshot of v5.7 failed to compile on ... Error code: VTCG ... actual generic parameter does not conform to constraint. ... Feature: invariant ...
    (comp.lang.eiffel)
  • Parallel make
    ... Just for fun I played a bit with the parallel make feature on IRIX - ... which I use for ages now to compare compile speed of old UNIX iron. ... The parallel make feature does work - I've ... It's not like that this is of any work relevance for me, ...
    (comp.sys.sgi.misc)
  • Re: Array of points, i.e. #(1@1 2@2 3@3...)
    ... embedding references to String objects (created at compile time) in your code. ... The syntax is the usual: ... But why should the feature be limited to instances of String? ...
    (comp.lang.smalltalk)
  • Re: comment out code
    ... There is no "comment" a block feature that many programming languages have. ... This means also that when you compile the code down to a mde..the ... essentially is the same concept of commenting out a block of code that many ... conditional compiling is used for version dependent features. ...
    (microsoft.public.access.formscoding)