Timeline for What coding practices are most useful dealing with trailing whitespace in data fields in binary files?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 10, 2016 at 10:46 | history | tweeted | twitter.com/StackSoftEng/status/807536925297037312 | ||
| Dec 2, 2016 at 21:14 | vote | accept | Jay Elston | ||
| Nov 17, 2016 at 9:41 | answer | added | Doc Brown | timeline score: 3 | |
| Nov 17, 2016 at 8:37 | answer | added | Brendan | timeline score: 1 | |
| Nov 17, 2016 at 0:45 | answer | added | BillThor | timeline score: 0 | |
| Nov 16, 2016 at 22:35 | answer | added | Christophe | timeline score: 1 | |
| Nov 16, 2016 at 22:23 | comment | added | gnasher729 | As you describe it, you are storing strings with or without whitespace. The fact that you store these in a binary file is maybe a bit frightening, but totally irrelevant to your problem. | |
| Nov 16, 2016 at 21:54 | history | edited | Jay Elston | CC BY-SA 3.0 |
Clarified how text fields are stored.
|
| Nov 16, 2016 at 21:54 | comment | added | Jay Elston | SJuan76 -- No, the file size does not change. An individual text field is stored in a binary file as a fixed number of bytes at a specified offset in that binary file. If a text field has fewer characters, the remaining bytes are set to 0. (Thanks for the comment-- I clarified this in the question just now). | |
| Nov 16, 2016 at 21:38 | comment | added | SJuan76 | Something I do not understand... if you trim the field, when you store it you will change the length of the binary file, making all the rest of the offsets wrong... Am I missing something? | |
| Nov 16, 2016 at 19:13 | comment | added | mattnz | My experience tells me if you have legacy code ignoring white space, and you change things, some other legacy buried somewhere in the bowels of history will be expecting the white space.... and resurrect itself the day after you make the change | |
| Nov 16, 2016 at 19:03 | comment | added | Doc Brown | @JustinCave: your comment could be a good answer, I guess. | |
| Nov 16, 2016 at 18:50 | comment | added | Justin Cave | How many touch points are there where people are writing to the file vs. reading from the file? If there are relatively few points where data is written, trimming on write makes sense. If you have writers all over the place but relatively few readers, trimming on read makes sense. If you have a messy code base that lacks abstraction where there are tons of places that data is written to the file and tons of places where it is read from the file, then you'd probably need to do both and will likely be finding and fixing legacy code forever. | |
| Nov 16, 2016 at 18:35 | history | asked | Jay Elston | CC BY-SA 3.0 |