While I can't fault your choice of personal preference on option 2 because all options are valid I will add my last 2 cents to this topic
>>e.g. return false but populate the returned item or return true with a nil pointer. It doesn't matter what is in the returned item if false is returned because that is part of the contract that the data is only valid if true is returned. And returning true with a nil pointer would also be a failure of contract which correct unit testing would remove. Ultimately the entire application is a reliance on the obligations of encapsulated code to perform its duties and for the authors to test and re-test to ensure they always provide the correct outputs for certain inputs. I don't think that programmers really want to design and architect software on the basis that code might not fullfill the obligations properly. It would be fixing code in the wrong place causing reuse of code to be a redundant concept. In this case the contract is that the code returns true to guarantee an assigned object so that you don't need if assigned(value) in a whole lot of places. The second part of the contract is that if it returns false, you don't pretend that it was true and try to do something with an invalid pointer. Regards Kyley -----Original Message----- From: [EMAIL PROTECTED] [mailto:owner-delphi@;delphi.org.nz] On Behalf Of Chris Reynolds Sent: Thursday, 31 October 2002 9:20 p.m. To: Multiple recipients of list delphi Subject: Re: RE: [DUG]: Style question - your votes please Now that you spell it out like that I think I have a strong preference for option 2 because any bugs down in findFirstmatch to do with the two returned items being out of sync will appear as bugs in the caller e.g. return false but populate the returned item or return true with a nil pointer. In option 2, the contract between the caller and callee is cleaner. The findFirstMatch has the responsibility for finding the firstMatch and nothing else. The caller is responsible for thinking about whether no match is an error or not. Furthermore as part of the contract, the caller is responsible for passing a valid list and if it doesn't then the function can throw an exception. So my version would be: functionFindFirstMatch (List: TItemList; Status: TItemStatus):TListItem; var i : Integer; begin if not assigned(List) then raise exception.create('No list assigned for findFirstMatch()'); if not assigned(Status) then raise exception.create('No status assigned for findFirstMatch()'); Result := nil; for i:= 0 to list.count-1 do if list[i].status = status then begin result := list[i]; exit; end; end; >From a personal perspective, I like this because it increases the chances of seperation between error handling and application logic. If also attempts to stop a bug jumping the stack from caller to callee or back up. ------------------------------------------------------------------------ --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi" Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/ --------------------------------------------------------------------------- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi" Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
