Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re^5: chop vs chomp

by Chady (Priest)
on May 11, 2007 at 14:08 UTC ( #614921=note: print w/ replies, xml ) Need Help??


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

So what you're saying is:

  1. Program A outputs data with "\n" at the end.
  2. Program B chonks the data.
  3. Program A fails in some way, and outputs a line without a terminating "\n"
  4. Program B dies and reports the problem?

This will appear in test as.. what? a failure in Program A or Program B?

If Program A outputing "\n" at the end of the line is such a cruicial matter, shouldn't you be testing Program A's output explicitly for "\n" (or whatever your seperator is) instead of condeming the use of chomp everywhere?

And by using chop, how do you catch this in testing? like so?

$data = get_input_from_program_a(); $chopped = chop($data); if ($chopped ne $/) { die "Program A is acting up"; }

I'm just not up to the level to think that deeply into your problem, maybe you can help me understand?


He who asks will be a fool for five minutes, but he who doesn't ask will remain a fool for life.
Chady | http://chady.net/
Are you a Linux user in Lebanon? join the Lebanese GNU/Linux User Group.


Comment on Re^5: chop vs chomp
Select or Download Code
Re^6: chop vs chomp
by Moron (Curate) on May 11, 2007 at 16:15 UTC
    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!

      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!

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (6)
As of 2014-09-30 23:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (386 votes), past polls