Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Re^6: chop vs chomp

by Moron (Curate)
on May 11, 2007 at 16:15 UTC ( #614951=note: print w/replies, xml ) Need Help??

in reply to Re^5: chop vs chomp
in thread chop vs chomp

It is somewhat more complicated, yes:

- A can be second or third party or not,

- A can be different team first party or same team responsibility.

- A can fail just after the \n (i.e. wrote a line terminator but still broke off early!) or somewhere else in the line.

- B can have some other fault or not.

- The use of chomp() may or may not obscure such other fault in B.

Looking at the implications of different coding options:

chomp(); # does not expose anything chop(); # can expose a fault in some of the combinations but only by +functional testing (no die). chomp() or die; # exposes that there is a fault somewhere, although fu +rther investigation is needed as to where. ( chop() eq $/ ) or die; # same effect as chomp() or die.
And then of course there is the option to use neither but create a custom routine for whatever reason. Some posters have said they prefer to do that rather than deal with the minefield caused by whatever their own version of such possibilities might be -- the above is probably not a definitive list!

^M Free your mind!

Replies are listed 'Best First'.
Re^7: chop vs chomp
by eric256 (Parson) on May 11, 2007 at 16:43 UTC

    You've proved quite a few times that chomp is not a good choice, in your case. Your case however does not represent everyone else's common uses. By your own definition here, a new line could exist and there could still be an error. In that case shouldn't your code be looking at the structure of the data it is attempting to load and relying on some other input other than the newline to mean your data is valid?

    You've also mentioned chop several times but unless you (chop() eq $/ ) or die chop doesn't do you any more good than chomp did. I also believe it has been pointed out that your chop construct will actualy fail if $/ is more than one line, and in addition chomp isn't mean to remove record seperators, it is meant to portable remove a new line. As a feature chomp doesn't fail if there is no new line, but few of perls functions will die if they fail.

    You attack everyone here as following groupthink and yet you can't seem to accept a new point of view yourself. I havn't seen anyone claim that chomp is ALWAYS the right choice, yet you claim it is ALWAYS the wrong choice. That flies in the face of the facts before you, chomp is quite often exactly what people want it to be, and when it isn't, then don't use it. Don't through it (and the people who use it) out simply because you have had a bad experience with it. Can it be misused? Of course it can, and is, but that realy doesn't mean it is always a bad choice.

    If you want to use it as a measure of skill then fine, but be sure to make your requirements such that chomp alone is the wrong choice. Maybe something like "Write a script to parse a data file removing line endings and verify that each line ends with a terminator. Assume the files are provided on the command line and output them to STDOUT". That is my first attempt writing such a problem so please don't be too critical ;)

    #!/usr/bin/perl use strict; use warnings; while (<>) { chomp or die "Record is missing terminating new line."; print; }

    Eric Hodges
      Your example looks fine. But you see if chomp had never come along, people wouldn't be having to focus so lopsidedly on this issue at all - they'd be taking a balanced view of data quality and would not dream of doing this - this is another of my objections - it's the tail of the input line wagging the dog!!

      ^M Free your mind!

        So....the fault is mine? None of my data files have a trailing new line, and I wouldn't dream of assuming that a newline meant a complete record even if they did. You on the other hand always have a trailing newline and assume it is significant? If my data never (and I do mean never) has a trailing newline then I should be fixing all those horrible tools that are providing me incomplete data. (/me heads off to slap newlines on all his csv files and apologize.). Sorry I didn't realize that soo many of my tools are broken and you are absolutely correct, ALL FILES MUST END IN \n.

        You talk of lopsided focus and yet you don't seem to be able to see that not everyone deals (or wants to deal with, or even should have to deal with) files that have a trailing newline. I've conceded many times now that in some cases you might in fact be right, it is only your blanket (lopsided) claim that chomp is ALWAYS bad that I take issue with. Ah well, it is done, you are of your opinion, and you showed me a use for chomps return value. Thank you for that, I can only hope that maybe you will see a little bit of the other side of the coin here and not right off programmers for using a specific tool when it fits their task (not your task).

        Eric Hodges

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://614951]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (5)
As of 2018-07-17 10:18 GMT
Find Nodes?
    Voting Booth?
    It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?

    Results (363 votes). Check out past polls.