P Zoltan wrote: > Finally I have some time for this issue. Looking through the source, it > seems a litte under-documented (inline) for me and also I'm not very happy > with the name of different identifiers; first I'd like to add some > comments and doxygen documentation. What kind of coding standards should > we use? Something like this would be good: > http://techbase.kde.org/Policies/Kdelibs_Coding_Style .
Sure. =) > About tests: I don't want to create a testing framework here, but I would > be more useful to create some test types (some class), holding the set of > operations and particularize them for various input data in test cases. > That should catch most of the bugs. ok... I think I've nailed most of the easy bugs in the calculation engine, the process seems to have exacerbated bugs of various kinds in BJT, jfet, and especially mosfet. =( > A final question: should limtechmath (and all the test cases) depend on > kde libs, or not? It can be easly done, because only the way the output is > printed must be changed. The only problem is that, as I've already > mentioned it, that cout mixed with kdDebug() can create inconsistent > output. Any ideas are appreciated. "deep" code should always output to a "FILE" or stream object, that way it can be redirected to whatever purpose is desired by the front end. -- New president: Here we go again... Chemistry.com: A total rip-off. Powers are not rights. ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org _______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
