in reply to Re: How would you indent this?
in thread How would you indent this?

The cperl-mode default is awful.

It's probably a bug or at least unintentional behaviour. It seems like the consensus is that one should either have

{key => 'k', class => 'kanji'},

or

{ key => 'k', class => 'kanji', },

but not

{ key => 'k', class => 'kanji' },

so what I should do is to stop it from adding the newline after the {.

Replies are listed 'Best First'.
Re^3: How would you indent this?
by ikegami (Patriarch) on Mar 18, 2021 at 07:32 UTC
    { key => 'k', class => 'kanji' },

    is best here because it makes it easy to see the differences the rows at a glance.


    { key => 'k', class => 'kanji' },

    isn't too bad, since it's almost as good at showing the differences between rows. The extra spacing is a needless hindrance, though, so it's not as good.


    But it's definitely not as bad as what you posted in the OP.

    { key => 'k', class => 'kanji' },

    This is just plain weird.


    Finally, we have this:

    { key => 'k', class => 'kanji', },

    It offers no readability benefits over the styles, and makes it even harder to see differences between the lines. No good here. This would be used when dealing with with very long records, and when adjacent lines are substantially different (e.g. in a multi-level structure).

    Seeking work! You can reach me at ikegami@adaelis.com

      > Finally, we have this:

      { key => 'k', class => 'kanji', },

      > It offers no readability benefits over the styles, and makes it even harder to see differences between the lines.

      I'd say that's the reasonable default, the => should be vertically aligned tho.

      Everything else needs intelligent heuristics to determine if the data has a repeated structure requiring another presentation. (not all AoHs have a nearly tabular semantic like in the OP's case)

      That's why all these Data::* modules are so complicated.

      And only the author can tell what the best representation is.

      An editor shouldn't change manual formatting.

      Problem in this thread is that the OP is effectively asking multiple questions:

      • how should this be best written
      • how should my editor do it
      • what's the bug in my editor

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery

        Problem in this thread is that the OP is effectively asking multiple questions:
        1. how should this be best written
        2. how should my editor do it
        3. what's the bug in my editor
        1. They way I write it of course!
        2. The way I would write it if I were taking appropriate care
        3. Is it that it is emacs?

        The are many very bad indentation and white space usage styles in use. Aside from a desire for consistency and style informed by "that is the way we always do it", I don't think many people think very much about their code writing style. My own style decisions, which I have thought about, are driven by laziness. I use white space, to the extent reasonably possible, consistently with the conventional usage in (English) written prose. That way I already have a parsing tool (my brain) that knows how to break stuff up without needing different settings packages for prose and code.

        Other style decisions are made based on intelligibility, such as keeping lines short with the important stuff toward the front, minimizing nesting, keeping functions reasonably short, and so on. Look at pretty much any of my code on PerlMonks to see how that looks. Note though that my block delimiting brace usage for Perl is K&R which I avoid in other languages (I prefer Whitesmiths).

        Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

        Everything else needs intelligent heuristics to determine if the data has a repeated structure requiring another presentation

        Well, yeah. In case you missed the implication, some styles are better than others in certain situations, and you should use the appropriate style to the situation.

        Style is about readability, not slavishly following some preset rules.

        Seeking work! You can reach me at ikegami@adaelis.com

      You seem to place too much emphasis on needing "to see differences between the lines" esp at a glance -- source code is too verbose for that kind of analysis, instead use spreadsheet or printf

        You seem to place too much emphasis on needing "to see differences between the lines" esp at a glance

        I absolutely strongly believe in readability. It is key to writing, debugging and maintaining code.

        If mentioning that a style has a benefit at no cost is too much for you, I hope to never have to deal with your code!

        source code is too verbose for that kind of analysis, instead use spreadsheet or printf

        huh? You're literally replying to a post that shows otherwise.

        Seeking work! You can reach me at ikegami@adaelis.com

Re^3: How would you indent this?
by parv (Parson) on Mar 18, 2021 at 07:18 UTC

    My issue with first and last styles is that changes needlessly become cumbersome. That may be preferred to set infrequently changing defaults, or if one needs to save precious vertical space.