Tim Driven Development | Test until the fear goes away
Swastik
Swastik Dey wrote:What are you trying to achieve with the following line?
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Swastik
Swastik Dey wrote:Could you please be bit more specific about your exact requirement?
fred rosenberger wrote:Never write 150+ lines of code before testing. I personally write 2-3 at MOST. I may even re-write the same line several times, adding just a piece more, and then compile and test each time.
If this line doesn't work:
simplify it. for now, have it always return something like -1. Then, see if you can get/print the reStockingFee:
then see if you can get the getPrice method to work:
Then see if you can add them together (but still return -1)
Then see if you can return the sum...
I think you are trying to do too much on each compile/test/debug cycle. The less code you write, and the more often you do compile, the easier it is. And it WILL end up SAVING you time in the long run.
Modify the Inventory Program by creating a subclass of the product
Swastik
Swastik
Swastik
Swastik Dey wrote:I guess you are thinking too much. First see what your Product class is. Now extend another class e.g. from Product class and add the other additional features(methods).
Ofelia Stewart wrote:
Swastik Dey wrote:I guess you are thinking too much.
I'm thinking too much.
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Ofelia Stewart wrote:This is what I have all together now. Here's an update:
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
If you are using a wood chipper, you are doing it wrong. Even on this tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
|