Re: obj 8-2

Discussion in 'Perl Misc' started by Rainer Weikusat, Feb 21, 2014.

  1. Marek Novotny <> writes:
    > On Fri, 21 Feb 2014 19:03:10 +0000, Henry Law wrote:


    [...]

    >> But for an algorithm, why not just loop through the array (Perl is good
    >> at that) and keep a running note of the largest number you found?
    >>
    >> You can code a loop over the values of an array like this:
    >>
    >> for my $current_number ( @array ) {
    >> # Here $current_number is each value in the array,
    >> # in order, one by one
    >>
    >> ... and you can code your 'if' statement more perlishly
    >>
    >> $max_number = $currentnumber if # Put your condition after the if
    >> # and don't forget the semicolon.
    >>
    >> Then when the loop finishes, print out the maximum number you found.
    >> About six lines of code is what you're aiming for.

    >
    > Thank you for all the replies first of all. I read what you write, but as
    > a beginner it's not always easy to translate the information into actual
    > code. That being said, this is what I came up with.
    >
    > #!/usr/bin/perl
    > # File: Obj8-2.pl
    > use strict;
    > use warnings;
    >
    > my @array=(5,4,3,1,7,23,12,5,43,29,32,18,49);
    > my $answer = 0;
    > my $elem = 0;
    >
    > foreach $elem (@array){
    > if ($elem > $answer){
    > $answer = $elem;
    > }
    > }
    > print "The Answer is: $answer.\n";


    This obviously breaks down when the array contains numbers < 0.

    @array = (42,41,42,31,54,42,56,57,46,58,59,60,34,61);

    $max = $array[0];
    $_ > $max and $max = $_ for @array[1 .. $#array];

    print "The Answer is: $max\n";
     
    Rainer Weikusat, Feb 21, 2014
    #1
    1. Advertising

  2. Rainer Weikusat

    John Black Guest

    In article <>,
    says...
    >
    > Marek Novotny <> writes:
    > > On Fri, 21 Feb 2014 19:03:10 +0000, Henry Law wrote:

    >
    > [...]
    >
    > >> But for an algorithm, why not just loop through the array (Perl is good
    > >> at that) and keep a running note of the largest number you found?
    > >>
    > >> You can code a loop over the values of an array like this:
    > >>
    > >> for my $current_number ( @array ) {
    > >> # Here $current_number is each value in the array,
    > >> # in order, one by one
    > >>
    > >> ... and you can code your 'if' statement more perlishly
    > >>
    > >> $max_number = $currentnumber if # Put your condition after the if
    > >> # and don't forget the semicolon.
    > >>
    > >> Then when the loop finishes, print out the maximum number you found.
    > >> About six lines of code is what you're aiming for.

    > >
    > > Thank you for all the replies first of all. I read what you write, but as
    > > a beginner it's not always easy to translate the information into actual
    > > code. That being said, this is what I came up with.
    > >
    > > #!/usr/bin/perl
    > > # File: Obj8-2.pl
    > > use strict;
    > > use warnings;
    > >
    > > my @array=(5,4,3,1,7,23,12,5,43,29,32,18,49);
    > > my $answer = 0;
    > > my $elem = 0;
    > >
    > > foreach $elem (@array){
    > > if ($elem > $answer){
    > > $answer = $elem;
    > > }
    > > }
    > > print "The Answer is: $answer.\n";

    >
    > This obviously breaks down when the array contains numbers < 0.
    >
    > @array = (42,41,42,31,54,42,56,57,46,58,59,60,34,61);
    >
    > $max = $array[0];
    > $_ > $max and $max = $_ for @array[1 .. $#array];
    >
    > print "The Answer is: $max\n";


    Honestly, I like Marek's second solution much better than all of yours. Marek's code is very
    readable and easy to understand what its doing. Sorry Rainer, but yours is a cryptic mess
    (IMO). And so are all the other ones that use $_. The only thing Marek needs to do to allow
    him to handle an array of all negative values is to set:

    my $answer = $array[0]; # instead of = 0

    John Black
     
    John Black, Feb 22, 2014
    #2
    1. Advertising

  3. John Black <> writes:
    > In article <>,
    > says...
    >> Marek Novotny <> writes:
    >> > On Fri, 21 Feb 2014 19:03:10 +0000, Henry Law wrote:


    [...]

    >> > #!/usr/bin/perl
    >> > # File: Obj8-2.pl
    >> > use strict;
    >> > use warnings;
    >> >
    >> > my @array=(5,4,3,1,7,23,12,5,43,29,32,18,49);
    >> > my $answer = 0;
    >> > my $elem = 0;
    >> >
    >> > foreach $elem (@array){
    >> > if ($elem > $answer){
    >> > $answer = $elem;
    >> > }
    >> > }
    >> > print "The Answer is: $answer.\n";

    >>
    >> This obviously breaks down when the array contains numbers < 0.
    >>
    >> @array = (42,41,42,31,54,42,56,57,46,58,59,60,34,61);
    >>
    >> $max = $array[0];
    >> $_ > $max and $max = $_ for @array[1 .. $#array];
    >>
    >> print "The Answer is: $max\n";

    >
    > Honestly, I like Marek's second solution much better than all of
    > yours. Marek's code is very readable and easy to understand what its
    > doing. Sorry Rainer, but yours is a cryptic mess (IMO).


    Referring to a single line of code with three expressions as "cryptic
    mess" seems a little out of place (George's arithmetic solution was
    relatively cryptic because of the 'if' hidden inside the the
    abs-function but it was far to simple and obviously too organized that
    it could be labeled as 'a mess'). Looking at it, what is used here is

    - a short-circuiting boolean operator for conditional evaluation
    - a statement modifier
    - $_ with it usual meaning of "the current thing"
    - an array slice expression using the integer range operator

    These are all pretty basic Perl features and if they're sufficiently
    unfamiliar to you that they seem 'cryptic' to you, that's not my fault.
    Perl has sufficient expressive power that really simple things, like
    finding the largest number in an array, can be expressed succinctly and
    that's one of the reasons why I consider it a much more useful language
    (to me, at least), than, say, Java, where nothing can be done without
    adding two dozen lines of boilerplate code to it (if not more). That's
    what makes a text complicated to read for me: Loads and loads and yet
    more loads of words and in the end "Parturient montes, nascetur
    ridiculus mus".
     
    Rainer Weikusat, Feb 22, 2014
    #3
  4. Rainer Weikusat

    John Black Guest

    In article <>,
    says...
    >
    > John Black <> writes:
    > > In article <>,
    > > says...
    > >> Marek Novotny <> writes:
    > >> > On Fri, 21 Feb 2014 19:03:10 +0000, Henry Law wrote:

    >
    > [...]
    >
    > >> > #!/usr/bin/perl
    > >> > # File: Obj8-2.pl
    > >> > use strict;
    > >> > use warnings;
    > >> >
    > >> > my @array=(5,4,3,1,7,23,12,5,43,29,32,18,49);
    > >> > my $answer = 0;
    > >> > my $elem = 0;
    > >> >
    > >> > foreach $elem (@array){
    > >> > if ($elem > $answer){
    > >> > $answer = $elem;
    > >> > }
    > >> > }
    > >> > print "The Answer is: $answer.\n";
    > >>
    > >> This obviously breaks down when the array contains numbers < 0.
    > >>
    > >> @array = (42,41,42,31,54,42,56,57,46,58,59,60,34,61);
    > >>
    > >> $max = $array[0];
    > >> $_ > $max and $max = $_ for @array[1 .. $#array];
    > >>
    > >> print "The Answer is: $max\n";

    > >
    > > Honestly, I like Marek's second solution much better than all of
    > > yours. Marek's code is very readable and easy to understand what its
    > > doing. Sorry Rainer, but yours is a cryptic mess (IMO).

    >
    > Referring to a single line of code with three expressions as "cryptic
    > mess" seems a little out of place (George's arithmetic solution was
    > relatively cryptic because of the 'if' hidden inside the the
    > abs-function but it was far to simple and obviously too organized that
    > it could be labeled as 'a mess'). Looking at it, what is used here is
    >
    > - a short-circuiting boolean operator for conditional evaluation
    > - a statement modifier
    > - $_ with it usual meaning of "the current thing"
    > - an array slice expression using the integer range operator
    >
    > These are all pretty basic Perl features and if they're sufficiently
    > unfamiliar to you that they seem 'cryptic' to you, that's not my fault.
    > Perl has sufficient expressive power that really simple things, like
    > finding the largest number in an array, can be expressed succinctly


    I know how your code works but I stand by what I said. Some people like to sacrifice
    readability and maintainability to save one or two lines of code ("succinctly"). Burying a
    decision inside of a short circuit AND is one of those cute tricks people do to avoid using a
    simple IF but not something I would encourage people (especially beginner programmers) to do
    except for those few applications where it makes sense (this is not one). Even using $#array
    is not necessary. foreach $elem (@array) is clear and unmistakable. I could probably show
    Marek's solution to someone who doesn't even know Perl and they'd be able to easily tell me
    exactly what it does. Not so with yours.

    John Black
     
    John Black, Feb 22, 2014
    #4
  5. John Black <> writes:
    > In article <>,
    > says...


    [...]


    >> >> $max = $array[0];
    >> >> $_ > $max and $max = $_ for @array[1 .. $#array];
    >> >>
    >> >> print "The Answer is: $max\n";
    >> >
    >> > Honestly, I like Marek's second solution much better than all of
    >> > yours. Marek's code is very readable and easy to understand what its
    >> > doing. Sorry Rainer, but yours is a cryptic mess (IMO).

    >>
    >> Referring to a single line of code with three expressions as "cryptic
    >> mess" seems a little out of place (George's arithmetic solution was
    >> relatively cryptic because of the 'if' hidden inside the the
    >> abs-function but it was far to simple and obviously too organized that
    >> it could be labeled as 'a mess'). Looking at it, what is used here is
    >>
    >> - a short-circuiting boolean operator for conditional evaluation
    >> - a statement modifier
    >> - $_ with it usual meaning of "the current thing"
    >> - an array slice expression using the integer range operator
    >>
    >> These are all pretty basic Perl features and if they're sufficiently
    >> unfamiliar to you that they seem 'cryptic' to you, that's not my fault.
    >> Perl has sufficient expressive power that really simple things, like
    >> finding the largest number in an array, can be expressed succinctly

    >
    > I know how your code works but I stand by what I said.


    Well, I was trying to inform you politely that you weren't making any
    more sense as if you'd accuse me of "sacricing readability and
    maintainability" (or some other suitable objectivation of an opinion of
    yours in lieu of arguing in favor of it) because I wrote something in
    German, say "Guten Tag, Herr Praesident!" you didn't understand
    because the language was unfamiliar to you: The "Good afternoon, Mr
    President" didn't become more complicated because it was expressed in a
    different form. Likewise,

    $max = $array[0];
    for (@array[1 .. $#array]) {
    if ($_ > $max) {
    $max = $_;
    }
    }

    or

    $max = $array[0];
    for ($i = 1; i < @array; ++i) {
    if ($array[$i] > $max) {
    $max = $array[$i];
    }
    }

    are no more or no less complicated at the content-level than

    $max = $array[0];
    $_ > $max and $max = $_ for @array[1 .. $#array];

    It's the same thing expressed in three different ways and 'verbosity' is
    not a virtue in its own right (as is brevity, for that matter).
     
    Rainer Weikusat, Feb 22, 2014
    #5
  6. Rainer Weikusat

    John Bokma Guest

    John Black <> writes:

    > I know how your code works but I stand by what I said. Some people
    > like to sacrifice readability and maintainability to save one or two
    > lines of code ("succinctly"). Burying a decision inside of a short
    > circuit AND is one of those cute tricks people do to avoid using a
    > simple IF but not something I would encourage people (especially
    > beginner programmers)


    So you don't recommend:

    open my $fh, '<', $filename
    or die "Can't open '$filename' for reading: $!";

    ?

    The use of short circuit operations is very common in Perl. It's not
    more confusing (to me) than:

    $foo += $bar;

    Idioms like this are very common in languages that support them. IMO,
    instead of dumbing down a language so everybody can program in it, it's
    better to learn idioms and use them.

    This is not programming specific: as soon as a lot of people start doing
    things together they make up jargon so they don't have to describe
    things in detail endlessly or write things down endlessly.

    > makes sense (this is not one). Even using $#array is not necessary.
    > foreach $elem (@array) is clear and unmistakable. I could probably
    > show Marek's solution to someone who doesn't even know Perl and they'd
    > be able to easily tell me exactly what it does. Not so with yours.


    But this is the case for a lot of languages. I can copy paste a piece of
    Python (you know, often advertised as the most readable and most easy to
    learn of all programming languages) or Haskell here and without knowing
    enough of the language one wouldn't have a clue what it does.

    As for the use of $#array: I see more beginners using this and indexing
    instead of using looping over @array.

    --
    John Bokma j3b

    Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
    Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
     
    John Bokma, Feb 22, 2014
    #6
  7. Rainer Weikusat

    $Bill Guest

    On 2/22/2014 11:35, Rainer Weikusat wrote:
    >
    > Well, I was trying to inform you politely that you weren't making any
    > more sense as if you'd accuse me of "sacricing readability and
    > maintainability" (or some other suitable objectivation of an opinion of
    > yours in lieu of arguing in favor of it) because I wrote something in
    > German, say "Guten Tag, Herr Praesident!" you didn't understand
    > because the language was unfamiliar to you: The "Good afternoon, Mr
    > President" didn't become more complicated because it was expressed in a
    > different form. Likewise,
    >
    > $max = $array[0];
    > for (@array[1 .. $#array]) {
    > if ($_ > $max) {
    > $max = $_;
    > }
    > }
    >
    > or
    >
    > $max = $array[0];
    > for ($i = 1; i < @array; ++i) {
    > if ($array[$i] > $max) {
    > $max = $array[$i];
    > }
    > }
    >
    > are no more or no less complicated at the content-level than
    >
    > $max = $array[0];
    > $_ > $max and $max = $_ for @array[1 .. $#array];
    >
    > It's the same thing expressed in three different ways and 'verbosity' is
    > not a virtue in its own right (as is brevity, for that matter).


    I like:

    my @array = (42,41,42,31,54,42,56,57,46,58,59,60,34,61);
    my $max = $array[0];
    foreach (@array) { $max = $_ if $_ > $max; }
    print "The Answer is: $max\n";

    It has the required if and looping constructs too.
     
    $Bill, Feb 22, 2014
    #7
  8. Rainer Weikusat

    $Bill Guest

    On 2/22/2014 12:39, John Bokma wrote:
    >
    > So you don't recommend:
    >
    > open my $fh, '<', $filename
    > or die "Can't open '$filename' for reading: $!";
    >


    FWIW ...

    One thing I learned very early in my C programming years was to
    always end a continued line with an operator (if possible) so
    it's obvious that the line is continued (rather than your version
    where the operator starts the 2nd line). EG:
    open my $fh, '<', $filename or
    die "open '$filename': $! ($^E)";
    It's much easier to read someone else's code that way.

    I usually also add the $^E cause it often gives helpful additional
    info (especially if the error was deep in the code).

    I'm also still a fan of the original K&R braces:
    if (...) {
    }
    rather than the wasted line versions often used today:
    if (...)
    {
    }
    for similar reasons as the operator on the end of the line.
     
    $Bill, Feb 22, 2014
    #8
  9. Rainer Weikusat

    John Black Guest

    In article <leb3e1$511$>, says...
    > I'm also still a fan of the original K&R braces:
    > if (...) {
    > }
    > rather than the wasted line versions often used today:


    I like this too. I like being able to follow the column right up to the associated If or
    While statement.

    John Black
     
    John Black, Feb 22, 2014
    #9
  10. Rainer Weikusat

    John Bokma Guest

    "$Bill" <> writes:

    > On 2/22/2014 12:39, John Bokma wrote:
    >>
    >> So you don't recommend:
    >>
    >> open my $fh, '<', $filename
    >> or die "Can't open '$filename' for reading: $!";
    >>

    >
    > FWIW ...
    >
    > One thing I learned very early in my C programming years was to
    > always end a continued line with an operator (if possible) so
    > it's obvious that the line is continued (rather than your version
    > where the operator starts the 2nd line). EG:
    > open my $fh, '<', $filename or
    > die "open '$filename': $! ($^E)";
    > It's much easier to read someone else's code that way.


    I prefer the or on a new line, also with stuff like:

    my $line = '........................'
    . ' and then some more';

    since a line of Perl starting with 'or' or '.' is very odd.

    > I'm also still a fan of the original K&R braces:
    > if (...) {
    > }


    Use those to, even on subs.

    > rather than the wasted line versions often used today:
    > if (...)
    > {
    > }


    Depends, when I use the former I often write:

    if ( ... ) {

    ....
    }
    (i.e. empty line after if) and when I used the latter I did:

    if ( ... )
    {
    ....
    }

    So often the same amount of lines. IMO, don't worry about the number of
    lines. Make your code flow and easy to read and don't be too clever ;-)

    --
    John Bokma j3b

    Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
    Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
     
    John Bokma, Feb 22, 2014
    #10
  11. On 2014-02-22 21:05, $Bill <> wrote:
    > On 2/22/2014 12:39, John Bokma wrote:
    >>
    >> So you don't recommend:
    >>
    >> open my $fh, '<', $filename
    >> or die "Can't open '$filename' for reading: $!";
    >>


    Actually I would recommend autodie here.

    But I think this is different in several aspects.

    1) In the “open or die†idiom, the open is the important part, while
    the die is just error handling, so it is fitting that the die is
    hidden at the end of the line (or a continuation line in this case).
    But in “$_ > $max and $max = $_†the assignment is central and should
    not be hidden.

    2) “open or die†conveys the proper meaning as an English sentence,
    but “$_ > $max and $max = $_†doesn't. In English “and†is used to
    combine similar things, so after reading “$_ > $max and†one would
    expect another comparison, not an assignment. Or vice versa, both
    subexpressions could “do something†and the whole statement could
    execute both (something like the comma operator). In Perl it means
    something completely different, so the similarity to an English
    sentence is distracting (I don't have this problem with the &&
    operator).

    I am an advocate of writing idiomatic code. If you write Perl code,
    write code which looks like Perl, not like Fortran with funny
    characters. But “idiomatic code†doesn't mean “cram every language
    feature you can think of into the smallest possible spaceâ€. It means
    code which is common among experienced programmers and easy to read for
    them (not necessarily for the beginner).

    I like Rainer's code as a demonstration of several useful language
    constructs in a single line. But I wouldn't write it like that in
    production code. (OTOH, if I encountered it in production code, I
    wouldn't change it. While it's overly cute in my opinion, it's far from
    obfuscated.)


    > One thing I learned very early in my C programming years was to
    > always end a continued line with an operator (if possible) so
    > it's obvious that the line is continued (rather than your version
    > where the operator starts the 2nd line). EG:
    > open my $fh, '<', $filename or
    > die "open '$filename': $! ($^E)";
    > It's much easier to read someone else's code that way.


    Damian Conway recommends the opposite in Perl Best Practices:

    Breaking Long Lines

    Break long expressions before an operator.

    When an expression at the end of a statement gets too long, it's
    common practice to break that expression after an operator and then
    continue the expression on the following line, indenting it one
    level. Like so:

    push @steps, $steps[-1] +
    $radial_velocity * $elapsed_time +
    $orbital_velocity * ($phase + $phase_shift) -
    $DRAG_COEFF * $altitude;

    The rationale is that the operator that remains at the end of the
    line acts like a continuation marker, indicating that the expression
    continues on the following line.

    Using the operator as a continuation marker seems like an excellent
    idea, but there's a serious problem with it: people rarely look at
    the right edge of code. Most of the semantic hints in a program—such
    as keywords—appear on the left side of that code. More importantly,
    the structural cues for understanding code—for example,
    indenting—are predominantly on the left as well (see the upcoming
    "Keep Left" sidebar). This means that indenting the continued lines
    of the expression actually gives a false impression of the
    underlying structure, a misperception that the eye must travel all
    the way to the right margin to correct.

    A cleaner solution is to break long lines /before/ an operator. That
    approach ensures that each line of the continued expression will
    start with an operator, which is unusual in Perl code. That way, as
    the reader's eye scans down the left margin of the code, it's
    immediately obvious that an indented line is merely the continuation
    of the previous line, because it starts with an operator.

    The indentation of the second and subsequent lines of the expression
    is also critical. Continued lines should not simply be indented to
    the next indentation level. Instead, they should be indented to the
    starting column of the expression to which they belong. That is,
    instead of:

    push @steps, $steps[-1]
    + $radial_velocity * $elapsed_time
    + $orbital_velocity * ($phase + $phase_shift)
    - $DRAG_COEFF * $altitude
    ;

    one should write:

    push @steps, $steps[-1]
    + $radial_velocity * $elapsed_time
    + $orbital_velocity * ($phase + $phase_shift)
    - $DRAG_COEFF * $altitude
    ;

    This style of layout has the added advantage that it keeps the two
    arguments of the push visually separated in the horizontal, and
    thereby makes them easier to distinguish.

    When a broken expression is continued over multiple lines, it is
    good practice to place the terminating semicolon on a separate line,
    indented to the same column as the start of the continued
    expression. As the reader's eye scans down through the leading
    operators on each line, encountering a semicolon instead makes it
    very clear that the continued expression is now complete.

    It takes a bit of an effort to shake off years of habit, but I agree
    with him: It does make the code more readable.

    I recommend Perl Best Practices. All the recommendations are
    thoughtfully explained. While you may disagree with some of them (I know
    I do), at least it makes you think about your style choices.

    hp


    --
    _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
    |_|_) | | Man feilt solange an seinen Text um, bis
    | | | | die Satzbestandteile des Satzes nicht mehr
    __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
     
    Peter J. Holzer, Feb 22, 2014
    #11
  12. Rainer Weikusat

    John Bokma Guest

    "Peter J. Holzer" <> writes:

    > On 2014-02-22 21:05, $Bill <> wrote:
    >> On 2/22/2014 12:39, John Bokma wrote:
    >>>
    >>> So you don't recommend:
    >>>
    >>> open my $fh, '<', $filename
    >>> or die "Can't open '$filename' for reading: $!";
    >>>

    >
    > Actually I would recommend autodie here.
    >
    > But I think this is different in several aspects.
    >
    > 1) In the “open or die†idiom, the open is the important part, while
    > the die is just error handling, so it is fitting that the die is
    > hidden at the end of the line (or a continuation line in this case).
    > But in “$_ > $max and $max = $_†the assignment is central and should
    > not be hidden.


    Yeah, I know the argument(s), have read PBP more than once, etc.

    To me, it's all a matter of taste, and my experience is that it changes
    over time.

    I prefer (now) this

    $x > 12 or next;

    over:

    next if $x > 12;

    I think of the former as something that must be true for the lines that
    follows.

    I've also no problem with:

    $x <= 12 and next;

    But now I sometimes write it like I did several years back:

    next if x <= 12;

    I see both styles in code (and way much weirder ones).
    >
    > 2) “open or die†conveys the proper meaning as an English sentence,
    > but “$_ > $max and $max = $_†doesn't. In English “and†is used to


    Yes, I understand the reason, etc. Yet, I don't see how someone has a
    hard time with reading/understanding

    $_ > $max and $max = $_

    It's nice that Perl sometimes reads like an English sentence, but a lot
    doesn't in my experience.

    > I am an advocate of writing idiomatic code. If you write Perl code,
    > write code which looks like Perl, not like Fortran with funny
    > characters.


    To me $_> $max and $max = $_ for @values; reads like Perl ;-)

    > But “idiomatic code†doesn't mean “cram every language
    > feature you can think of into the smallest possible spaceâ€. It means
    > code which is common among experienced programmers and easy to read for
    > them (not necessarily for the beginner).


    Exactly, and to me the above falls in that class.

    > I like Rainer's code as a demonstration of several useful language
    > constructs in a single line. But I wouldn't write it like that in
    > production code. (OTOH, if I encountered it in production code, I
    > wouldn't change it. While it's overly cute in my opinion, it's far from
    > obfuscated.)


    Yup. I sometimes write dense code like that, and other times I write it
    more out. It depends on my mood and also how complicated the code
    surrounding it is, and of course for who I am writing.

    > I recommend Perl Best Practices. All the recommendations are
    > thoughtfully explained. While you may disagree with some of them (I know
    > I do), at least it makes you think about your style choices.


    Yup, I certainly recommend PBP as well and wouldn't mind a more modern
    version. And I think most people who've read it a) disagree with some
    and b) have become better programmers.

    --
    John Bokma j3b

    Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
    Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
     
    John Bokma, Feb 23, 2014
    #12
  13. On 2014-02-23 00:03, John Bokma <> wrote:
    > I prefer (now) this
    >
    > $x > 12 or next;
    >
    > over:
    >
    > next if $x > 12;


    One of these two lines doesn't do what you think.

    hp


    --
    _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
    |_|_) | | Man feilt solange an seinen Text um, bis
    | | | | die Satzbestandteile des Satzes nicht mehr
    __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
     
    Peter J. Holzer, Feb 23, 2014
    #13
  14. On 2014-02-22 23:22, Ben Morrow <> wrote:
    > Quoth "Peter J. Holzer" <>:

    [quoting BPP]
    >> The indentation of the second and subsequent lines of the expression
    >> is also critical. Continued lines should not simply be indented to
    >> the next indentation level. Instead, they should be indented to the
    >> starting column of the expression to which they belong. That is,
    >> instead of:
    >>
    >> push @steps, $steps[-1]
    >> + $radial_velocity * $elapsed_time
    >> + $orbital_velocity * ($phase + $phase_shift)
    >> - $DRAG_COEFF * $altitude
    >> ;
    >>
    >> one should write:
    >>
    >> push @steps, $steps[-1]
    >> + $radial_velocity * $elapsed_time
    >> + $orbital_velocity * ($phase + $phase_shift)
    >> - $DRAG_COEFF * $altitude

    >
    > That I don't like. Non-standard indentation IMHO is more confusing than
    > it is helpful. If I felt it necessary to separate @steps and the start
    > of the expression more clearly, and particularly if there were two such
    > expressions, I'd use another line:
    >
    > push @steps,
    > $steps[1]
    > + ...
    > + ...,
    > $steps[2]
    > - ...
    > + ...;


    Ugh. That looks mis-aligned. I like stuff to align vertically.

    >> ;

    >
    > This, also, I don't like: a bare semicolon or comma looks terribly out
    > of place.


    Yeah, I don't do this.

    hp

    --
    _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
    |_|_) | | Man feilt solange an seinen Text um, bis
    | | | | die Satzbestandteile des Satzes nicht mehr
    __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
     
    Peter J. Holzer, Feb 23, 2014
    #14
  15. Rainer Weikusat

    Uri Guttman Guest

    >>>>> "BM" == Ben Morrow <> writes:

    BM> This has the additional advantage of allowing a trailing comma inside
    BM> the brackets (although, now I check, 'push @x, 1, 2,;' is in fact legal,
    BM> despite looking even weirder than a bare semi).

    perl is one of the few (only?) languages to allow trailing commas. it is
    such an easy syntax thing to add and it allows for easy reordering of
    lists with one per line or other things. too bad most lang designers
    didn't see that like larry did.

    uri
     
    Uri Guttman, Feb 23, 2014
    #15
  16. Rainer Weikusat

    John Bokma Guest

    "Peter J. Holzer" <> writes:

    > On 2014-02-23 00:03, John Bokma <> wrote:
    >> I prefer (now) this
    >>
    >> $x > 12 or next;
    >>
    >> over:
    >>
    >> next if $x > 12;

    >
    > One of these two lines doesn't do what you think.


    Yes, my bad.

    next unless $x > 12;

    ( or $x > 12 and next; to go with the if )

    I still prefer the or/and version, mostly, but like I wrote I recently
    started to fall back to if/unless recently.

    --
    John Bokma j3b

    Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
    Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
     
    John Bokma, Feb 23, 2014
    #16
  17. Rainer Weikusat

    Uri Guttman Guest

    >>>>> "BM" == Ben Morrow <> writes:

    BM> perlstyle sez 'put the more important clause first'. So

    BM> reactor_is_overheating() and sound_alarm();

    BM> but

    BM> increase_power_output() unless too_much_already();

    peter scott (author of perl medic and other stuff) teaches that 'and',
    'or' should be used for flow control and &&, || used for
    expressions. this is good also because of their precedence. the word
    versions are very low precedence which allows for assignment and other
    things in the clauses.

    but i prefer the if/unless modifiers vs and/or in simple booleans. i
    teach to leave early when you can. i see way too much code like this:

    if( some test ) {

    do LOTS OF CODE ;
    }
    else {
    next # or return or last
    }

    it should be:

    next unless test() ; # or return or whatver

    do LOTS of code at main level ;

    it saves block entry, indents, lines of code, braces and pixels. a 5 way
    win!

    uri
     
    Uri Guttman, Feb 23, 2014
    #17
  18. Rainer Weikusat

    $Bill Guest

    On 2/22/2014 14:17, Peter J. Holzer wrote:
    >
    > The indentation of the second and subsequent lines of the expression
    > is also critical. Continued lines should not simply be indented to
    > the next indentation level. Instead, they should be indented to the
    > starting column of the expression to which they belong. That is,
    > instead of:
    >
    > push @steps, $steps[-1]
    > + $radial_velocity * $elapsed_time
    > + $orbital_velocity * ($phase + $phase_shift)
    > - $DRAG_COEFF * $altitude
    > ;
    >
    > one should write:
    >
    > push @steps, $steps[-1]
    > + $radial_velocity * $elapsed_time
    > + $orbital_velocity * ($phase + $phase_shift)
    > - $DRAG_COEFF * $altitude
    > ;


    I prefer to just split at the nearest (or most logical operator) and
    indent 2 spaces (to conserve H space):

    push @steps, $steps[-1] + $radial_velocity * $elapsed_time +
    $orbital_velocity * ($phase + $phase_shift) - $DRAG_COEFF * $altitude;

    sometimes I'll break like this to get one logical calc per line:

    push @steps, $steps[-1] +
    $radial_velocity * $elapsed_time +
    $orbital_velocity * ($phase + $phase_shift) -
    $DRAG_COEFF * $altitude;

    always staying in my 80 col space.
     
    $Bill, Feb 23, 2014
    #18
  19. Rainer Weikusat

    $Bill Guest

    On 2/22/2014 19:48, Uri Guttman wrote:
    >
    > it should be:
    >
    > next unless test() ; # or return or whatver
    >
    > do LOTS of code at main level ;
    >
    > it saves block entry, indents, lines of code, braces and pixels. a 5 way
    > win!


    I do that quit a bit - it may not be structured, but saves
    a lot of space to short circuit the code.

    next if ...;
    <more code>

    or even like this:

    if (...) { <some short code>; next; }

    also saves an indent level.

    To me all code has to fit in 80 columns or less except for the rare
    occasion where you have some really long names/white space that can't
    be split.
    Sometimes I back-dent code (take 1 or more tabs off and add 2 spaces)
    that's long and not easily splittable to make it easier to read (and
    since it's fairly rare):

    if (...) {
    print
    "some-really-long-thingy-that-doesn't-split-well\n";
    }
     
    $Bill, Feb 23, 2014
    #19
  20. Rainer Weikusat

    Uri Guttman Guest

    >>>>> "$" == $Bill <> writes:

    $> On 2/22/2014 19:48, Uri Guttman wrote:
    >>
    >> it should be:
    >>
    >> next unless test() ; # or return or whatver
    >>
    >> do LOTS of code at main level ;
    >>
    >> it saves block entry, indents, lines of code, braces and pixels. a 5 way
    >> win!


    $> I do that quit a bit - it may not be structured, but saves
    $> a lot of space to short circuit the code.

    it is structured. just structured better! using control flow ops is a
    good thing. the old 'structured programming' where you must return only
    on one place and only leave loops at the top is anal. it was better than
    spaghetti code but the langs in those days didn't have the flow power of
    perl and other modern langs. anything was better than goto hell.


    $> next if ...;
    $> <more code>

    $> or even like this:

    $> if (...) { <some short code>; next; }

    $> also saves an indent level.

    i generally will never put a real block on one line. just too
    dense. maybe in a dispatch table with some short anon subs that can
    work and i have done that.

    uri
     
    Uri Guttman, Feb 23, 2014
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark Kamoski
    Replies:
    3
    Views:
    15,750
    Jay B. Harlow [MVP - Outlook]
    Aug 9, 2003
  2. Phil Endecott

    Obj* ptr = new Obj(X)

    Phil Endecott, Jun 3, 2005, in forum: C++
    Replies:
    5
    Views:
    474
    Mark P
    Jun 3, 2005
  3. Shalabh Chaturvedi
    Replies:
    2
    Views:
    447
    Mike C. Fletcher
    Feb 20, 2004
  4. Matthew Thorley

    How do you convert a string obj to a file obj?

    Matthew Thorley, May 4, 2005, in forum: Python
    Replies:
    7
    Views:
    511
    Peter Otten
    May 4, 2005
  5. alf
    Replies:
    9
    Views:
    414
Loading...

Share This Page