Timeline for Refactoring a series of if-return statements.
Current License: CC BY-SA 3.0
9 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Aug 5, 2011 at 12:11 | comment | added | IAbstract |
@Arnis: Both, IsTemplateSent and IsReceived looked like bool members of Report. Remove those from CheckStatus if you like. In your original sample, the problem is that the status returned by IsTemplateSent will overwrite any return value from CheckStatus. The resulting values "Received" and "Not Received" do make sense as return status values - obviously, you can make whatever changes you like.
|
|
Aug 5, 2011 at 7:59 | comment | added | Arnis Lapsa | @ChaosPandion IsTemplateSent belongs to report not check. It is not status of check. | |
Aug 4, 2011 at 22:40 | history | edited | IAbstract | CC BY-SA 3.0 |
code correction
|
Aug 4, 2011 at 21:29 | history | edited | IAbstract | CC BY-SA 3.0 |
formatting and slight modification
|
S Aug 4, 2011 at 21:29 | history | suggested | Arnis Lapsa | CC BY-SA 3.0 |
formatting
|
Aug 4, 2011 at 20:58 | comment | added | ChaosPandion |
@Arnis L. - Now what if we renamed it CheckStatus and attached the instance to the Check object? I would also rename the instance property to Value .
|
|
Aug 4, 2011 at 20:52 | comment | added | Arnis Lapsa |
This ain't bad stuff. Using class enums myself. But that is still enum which couples all these vaguely related processes together too tightly. Also - Check is object for itself - it is responsible for checking [un]success of report. IsTemplateSent , IsReceived flags belong to report not its check (report template is generated, then - received filled out and that triggers report check to be available). It makes no sense for Check to be responsible for state of Report.
|
|
Aug 4, 2011 at 20:45 | review | Suggested edits | |||
S Aug 4, 2011 at 21:29 | |||||
Aug 4, 2011 at 17:51 | history | answered | IAbstract | CC BY-SA 3.0 |