[progne]

Just 12 years full time with Ruby here, I'm a noob. But when I see that I could replace

  def initialize(text)
    @text = text
  end

  def inspect
    "#<#{self.class} #{text}>"
  end

  def ==(other)
    other.is_a?(Word) && text == other.text
  end

with

  def initialize(text) = @text = text
  def inspect = "#<#{self.class} #{text}>"
  def ==(other) = other.is_a?(Word) && text == other.text

I start drooling a little. That's 3 lines to replace 11. We have a soft limit on class length of 100 lines, and I like the extra conciseness this allows.

You can also do it like

  define_method(:inspect) { |text| "#<#{self.class} #{text}>" }

and we do that in some places, but that extra verbosity makes for more lines.

[stouset]

Unnecessarily cramming more density into one line to avoid soft limits seems like a poor tradeoff.

Ask any typesetter. Blank space used well gives text breathing room, making it easier to parse visually.

In the former example, it is extremely easy to pick out what each method name is and a decent idea of what it does at a glance. In the latter, I have to read to even see the method names.

[kazinator]

Ask a typesetter? No thank you.

What is a typesetter? Someone or something which takes tree-structured sentences, cranks them into a linear sequence of words, which is arbitrarily chopped into a rectangular form, with the goal being that the rectangle appear evenly gray from a distance. Sometimes ugly hyphens are inserted into the middle of tokens.

[Pxtl]

I feel like I'd still want the body on its own line from the signature definition just for readability. And with the parser problems described in TFA, I'd say that parens should be mandatory coding-style enforced by linter.

  def initialize(text)
    = (@text = text)
  def inspect 
    = ("#<#{self.class} #{text}>")
  def ==(other) 
    = (other.is_a?(Word) && text == other.text)

seems like a good compromise.

edit: this is similar to our standard when writing one-liner methods in C#. A bit noisier because of types and visibility, but still pretty concise, imho.

  public void Initialize(string text)
    => Text = text; 
  // I actually hate the above a bit because "=>" 
  // originally implied functional/no-side-effects 
  // in C#, but the world moves on.

  public string Inspect()
    => $"{this.GetType().Name} {text}>";

  public static bool operator== (Word a, Word b)
    => a.Text == b.Text;

[vidarh]

Personally I'd never let your first example through a code review. If you're going to break it up, use end. Where the one line format makes sense is when the body is trivial and often when there are multiple related methods that can be lined up to highlight their similarities and differences in the single line format.

[Pxtl]

Hah, I'm a firm "no alignment allowed, indent only" reviewer, so that use case would never even occur to me.

[vidarh]

I can't stand that. It dramatically reduces code readability to me.

[Pxtl]

I tend to agree with Google on this one:

https://google.github.io/styleguide/jsguide.html#formatting-...

> Terminology Note: Horizontal alignment is the practice of adding a variable number of additional spaces in your code with the goal of making certain tokens appear directly below certain other tokens on previous lines.

>

> This practice is permitted, but it is generally discouraged by Google Style. It is not even required to maintain horizontal alignment in places where it was already used.

>

> Here is an example without alignment, followed by one with alignment. Both are allowed, but the latter is discouraged:

  {
    tiny: 42, // this is great
    longer: 435, // this too
  };

  {
    tiny:   42,  // permitted, but future edits
    longer: 435, // may leave it unaligned
  };

> Tip: Alignment can aid readability, but it creates problems for future maintenance. Consider a future change that needs to touch just one line. This change may leave the formerly-pleasing formatting mangled, and that is allowed. More often it prompts the coder (perhaps you) to adjust whitespace on nearby lines as well, possibly triggering a cascading series of reformattings. That one-line change now has a "blast radius." This can at worst result in pointless busywork, but at best it still corrupts version history information, slows down reviewers and exacerbates merge conflicts.

[kazinator]

TXR Lisp:

  1> (defstruct (word text) ()
       text
       (:method print (me stream pretty-p) (put-string `#<@(typeof me) @{me.text}>` stream))
       (:method equal (me) me.text))
  #<struct-type word>
  2> (new (word "abc"))
  #<word abc>
  3> (equal *2 "abc")
  t

You wouldn't define a print method for a struct like this, because it's counterproductive. You're throwing away print-read consistency in exchange for no benefit.

I usually define print methods for complex structures with many slots, that are not expected to be externalized. Particularly if they are linked in a graph structure, where (even if you have the circular printing turned on to handle the cycles) the prints get large. You know, you wanted to just print the banana, but it was pointing to a gorilla, and basically a dump of the whole jungle ensued.

[vidarh]

You wouldn't define an `inspect` method for this simple example in Ruby either, because Ruby provides a default inspect that'd do just fine in this example. The exact same tradeoff for when to define inspect as for when you'd define print methods exist. In other words, that wasn't the point.

[sdf4j]

> We have a soft limit on class length of 100 lines, and I like the extra conciseness this allows

I'd recommend your team to stop code-golfing... Even better: with this new syntax you MUST reduce the soft limit to around 50 lines per class, right?

[progne]

I agree that it shouldn't be used for anything complex, even if it reduces to one line. But I do like it for simple things. Maybe it's staring at very similar code all day, but such short statements read fluently for me.

And even if an extra line of separation is used, it's still 6 lines instead of 11.

[mschuster91]

> We have a soft limit on class length of 100 lines, and I like the extra conciseness this allows.

The "compact" line format is something that is very information dense and really really hard to parse for a human's eye, compared to the clearly visually structured prior format.

Personally, if I'd see something like that outside of a code golf tournament, I'd run because that kind of code density means that at least one of the developer(s) believes themselves to be some kind of code wizard who loves Matrix-style display, and it means that new developers have a very steep learning curve ahead of them.

[kbenson]

What can be good, but requires discipline, is to replace some of the syntax that's no longer needed with a comment to help explain the what and why and goal. You reduce or eliminate the line savings, but overall may increase the information and understanding of intent.

I do this commonly in the Perl I write. If I'm using a complex set of maps and greps to reorganize a structure, doing that inline can be useful to the developer because it can match mental state, but the later reader may be somewhat lost when seeing it depending on how much of the data state they've internalized. A nice comment to explain the intent is useful, and when you're already saving space by eliding syntax, keep a good ratio of action to code on the screen (which is really what we're optimizing for here most times anyway, right?)

[jlarocco]

Seems counter productive to me.

The first snippet is much easier to read, and using this technique to get around your 100 line rules seems to be missing the point of the rule - or purposely subverting it.