applications should be decomposed so that each method or function performs one action. at the top level of the application, the action may be "populate_database". this method would then call lower level methods to perform each of the actions to populate a database where each lower level method performs a single action. strict line limitations on methods or functions is arbitrary. although i do go by the "the method should fit on my screen" guide. as far as code file size, i don't believe there is a need to limit the file size arbitrarily. we limit a file to a single class. for some of our abstract base classes, the class is pretty big to cover all the base methods. working with methods or functions that perform multiple tasks is a nightmare. in a previous life, i had the truly unfortunate nightmare of having to work with a code file that was over 80000 (yes that's eighty thousand) lines long. one function within this file was over 12000 lines long. to add insult to injury, there were goto statements in the code (it was C code) that were used for regular program execution (not error recovery). to make it even worse (which is a challenge) there was a macro with a goto statement in the file!! decomposition of the application into single actions is the way to go. schleprock

Joe Woodbury wrote:

(One problem in TDD is finding that a fundamental code change will greatly improve the application but will render the tests invalid as written. This WILL happen often. The temptation is to compromise the code so the tests either don't have to be rewritten or the rewrite is minimal. If you aren't careful, you end up creating an application that passes all the tests, but doesn't solve the customer's problem. As a developer, we may proclaim this simply won't happen, but tell that to the people writing your paychecks.)

you're not writing good tests. the unit tests should be very specific tests that should never change unless you re-architect the product. regression tests should test the output in a way that allows for change in the output without invalidating the test. for example, if the output from your application is textual but you don't care about the order in which the output appears, sort the output from the application and then check for correctness. you've now gotten rid of the ordering issue. if you're testing a gui and you don't care about button position, write the test to bypass choosing the button via x/y location and call the method directly. have a single test that triggers a button push via position and you only need to update that one test when the button gets moved. tests need to be written to ignore things that you don't care about and only test what you do care about. schleprock

leppie wrote:

It's only a benefit if you can test against something, eg some algorhithm.

absolutely not true. one small example, your end user uses the output from your application to automate something else, they expect your output to be in a specific order with a particular syntax. if you don't want to piss off your end user, you test that the output is correct anytime you change your application. testing is about ensuring that your code base at the time of compilation is acting in a fashion that your end user is expecting. while that does include testing of algorithmic correctness, it also includes correct output (which could be font, color, placement in the window, ...) for a given input. it should also include detecting and handling error conditions in a resonable way. simply exiting out unexpectedly on any error is NOT a resonable way of handling error conditions (and that is not necessarily algorithmic). schleprock

Robert Vukovic wrote:

What about GUI programing ? What about multithreading? What about C++ ?

TDD can be applied to any programming language or situations. in my development world, we do gui, multithreading, C++, multiprocess. for the minor (play) programming of the original post (30K lines is barely getting started) with a single developer who does all aspects of product design, development and deployment, one can get away with not writing tests (though it is not a good idea). empirical testing is not a good way to test. it is inherently error prone (humans are very poor at repetitive tasks) and usually skips tests that the user simply “believes” cannot be broken (but invariably are broken). We’ve automated all of our testing (gui included) so that you are assured that the changes you have made work in the current source set. Without tests you cannot refactor with confidence (in fact according to “refactoring to patterns”, Kerievsky; you cannot refactor without a complete set of unit tests). TDD is also about writing the test before you write the code. The test should fail when you try to run the test (as the code “should not” exist yet), but if the test passes, then you don’t need to write any code. It also helps in finding those corner cases as you can write the crazy tests before you code and get an idea of how to solve the corner cases while you’re writing the main algorithm. This allows for you to provide a generic algorithm without all the “if..else” kludges for the corner cases. Asserts are not a testing methodology, they are a debugging methodology. Asserts are supposed to be used to test setup conditions and assumptions in the code. They are not a good tool for testing code. Automated unit and regression testing are the best way at this point. Formal proofs are the best method, in theory you would not even have to run tests if one could provide a formal proof of the application, but we’re a long way away from that (maybe never for complete applications). TDD is not a silver bullet (there are NO software silver bullets, see IEEE Queue, I think june ’06 issue). i don’t like the hype around it either. Nothing will beat good programming practices and discipline. TDD is a good practice. schleprock

Robert Vukovic wrote:

What about GUI programing ? What about multithreading? What about C++ ?

three to five times a week in the gym for an hour. then hiking on the weekend with da wife and kids. been programming since 1976 (ouch 30 years!!) guess that makes me a 5. i have to say that in my particular cube farm, those coders that are more fit are far more productive then those that are slugs. also the more fit are out sick much less. schleprock :cool:

i agree with Graham, comments within header files should explain what the method does, how to use the method, the expected output, and (gasp) any side effects. header comments should not ever explain how the method does it's work. within source code, comments should explain the intent of the code as well as any assumptions. i absolutely hate comments such as the one Graham points out and for God's sake, if you change the code and the comments are not relevent or even worse, not correct, REMOVE THEM or CORRECT THEM. it just blows me away when people check in code with obsolete or incorrect comments. i'll get off my soap box now. schleprock :cool: "God only knows, and he ain't talkin'" David Lee Roth