Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

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
      A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://614951]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2019-02-16 15:08 GMT
Find Nodes?
    Voting Booth?
    I use postfix dereferencing ...

    Results (95 votes). Check out past polls.