This is in reference to the question posted here. As I would judge it, the question there should be closed simply because it seems to ask why the Borland developers made one thing a function and another a procedure (function that returns a void result).
Now the example was given there of some string manipulation functions that exist in Borland Pascal or Delphi:
S2 := Copy(S1,3,2);
Copies into S2 from S1 the 2 characters starting from the 3rd position.
Delete(S,3,2);
Deletes from S the 2 characters starting from the 3rd position.
Now I thought it might be a good discussion on what would be good design decisions regarding devising these things. I picked up a few rules of good design on what a function prototype should look like beyond the obvious (name reflects function, function result should be atomic, no extraneous variables), but are there any others that should govern a situation such as this one or others? I really didn't see a good case in Atwood's code book where it was discussed.
Anyway, are there some good rules on how functions should be designed to work? Barring the specious naming, would it be better to have
S2 := Delete(S1,3,2);
as opposed to
Delete(S,3,2);
? Are there any other useful considerations or examples to discuss of good and bad function design?
delete
) first-and-size. Half-open bounds (inclusive at the start, exclusive at the end) are popular for reasons that Dijkstra explained fairly well. Most important, though, is consistency. Confusion about bounds is a common source of errors. – Steve314 Oct 2 '13 at 22:20