This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Originally posted by Keith Jones: In the specification it says that:
The problem is that this is not quite true. Having looked at the contents of my file the terminating characters they have chosen is not 0 (null) but 32 (space).
Question is when we write fields into the data file ourselves should we do what they say or do what they do?
I think that this requirement is there to test how you would deal with a situation where the customer specification is obviously wrong (They don't always know what they want).
I known some people have written back nulls when updating a file as per the spec rather than spaces.
Of course when reading in a record it doesn't matter because if you use String.trim() it will get rid of all charachters at the beginning and end of the string whose ascii value is less than the space charchter. (a space is value 32 and null 0). Also trimmed as are any other whitespace charachters in between such as carraige return, newline and tab).
It says in the requirements that other applications still use the same flat file format (which is why we have to implement the stupid DBMain interface) so I would be inclined to pad with spaces as this is what the other legacy applications would expect and padding the file with null may cause them to fail.
Regards, Mark [ November 22, 2006: Message edited by: Mark Smyth ]