4 ms·
In Java 7 you can use Files.readAllLines to read file to string, also there is a built-in CSV parsing library, it's called String.split() :)
by skocznymroczny 13y ago
In Java 7 you can use Files.readAllLines to read file to string, also there is a built-in CSV parsing library, it's called String.split() :)
- bane 13y ago> Files.readAllLines Geez, I think I've already reimplemented that half a dozen times. Of course it would be buried in the Files class and not one of the 30 dozen buffer reader whatever classes I have to piece together. > String.split() Yeah yeah, that's what all the Java books say ;)
- nogridbag 13y agoString.split will work fine until you have data like this: Sarah Jones,Paul Williams,"Smith, John",Fred Johnson It's best to use a library for this like SuperCSV: http://supercsv.sourceforge.net http://supercsv.sourceforge.net
- d0 13y agoThis. This is such a common problem, I added it to our formal code test. We supply an interface, a unit test and a rather broken CSV file and they have to make the test pass by adding the implementation. 22 people failed the test entirely, complaining about quotes and line ending inconsistency. 2 people wrote a proper state machine driven parser that didn't work. 1 person wrote a proper state machine driven parser that worked. 1 person imported commons-csv and wrapped stuff. The last person got the job.
- cygwin98 13y ago2 people wrote a proper state machine driven parser that didn't work. 1 person wrote a proper state machine driven parser that worked. You probably missed three really good candidates here.
- sp332 13y agoSure, but if you've only got one position, you might as well go for the one with enough experience/wisdom to get it right.
- cygwin98 13y agoI thought for coding tests implementations are supposed to be done from scratch on. Or at least the guy who wrote the working parser should be on top of the list.
- d0 13y agoNot really. We want people to solve the problem, not invent something that needs maintenance. In some cases, from scratch is important, but for most it's not.
- coldtea 13y agoSounds like you don't want competent people to challenge the rest.
- d0 13y agoNo we don't want competent people showboating and pissing cash up the wall reinventing wheels that have a high maintenance cost because it's fun. We hire engineers. An analogy: would you hire the electrical engineer who knocks up an ASIC for every task or the one who designs in a COTS part for a predictable unit cost and manufacturing lead time?
- eludwig 13y ago>>1 person wrote a proper state machine driven parser that worked. Look, the fact is, based on the replies below, this guy is probably better off working somewhere else. Not to go off on this particular person, the preoccupation with "Library Knowledge(tm)" in the enterprise (so, Java) world has become an epidemic. I have seen libraries used for all the wrong reasons, pulling in great gobs of someone elses code to do a bloody string copy! Damn, you are hiring coders. Let them fricken code, for God's sake. Please, I know all of the counter arguments (I've been harangued by them for years), but I really think that there is a middle ground here. Some things are truly worth bringing into a project via library. Big things, things that are really hard things that you may not have the staff to handle. But if we are afraid to let coders code some stuff, even trivial stuff, then we have killed the one true joy that we had in the first place: coding! One thing to remember about libraries is that they have bugs too! Just because someones got an apache page, doesn't mean that there are no bugs in there lurking. You WILL most probably need to understand the problem/solution well enough to use the library in the first place. Gosh, rant off.
- Too 13y agoyeah right.....and what's the XML parsing library called? java.util.regex? And the SQL parameterized query library? string.format?