unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Aaron Jensen <aaronjensen@gmail.com>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: 60186@debbugs.gnu.org
Subject: bug#60186: 29.0.60; ruby-mode indentation of multi-line expressions
Date: Fri, 23 Dec 2022 19:17:11 -0500	[thread overview]
Message-ID: <CAHyO48wn2CBMmzBH25mFT_u_Fk_qDQA=NRnv29MkqDfzRYvA4A@mail.gmail.com> (raw)
In-Reply-To: <902440c7-706a-20e1-55af-4e12e8cdda2c@yandex.ru>

On Fri, Dec 23, 2022 at 5:26 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> Is that also true for the other "codebases you've seen" referred to in
> the first message here?

Mostly we work with Rails (and I try to avoid looking at that code as
much as I can, though I often find myself in there...) and the
Eventide framework: https://github.com/eventide-project

Given that the two founders of that are on my team we tend to follow
their indentation and coding style (and it is well-thought out, with
everything considered with respect to human cognition/eye tracking
studies/etc.). That's probably the best example I could offer, though
what you will find in there is that not many lines of code span more
than one line. They (and we) tend to allow longer lines when the right
side of the line is less important.

> > With either indentation style, the
> > first argument (which is the most significant one when a method is
> > properly designed) will have the least presence when scanning. It's
> > just not a good format in my experience. In our code we take it a step
> > further and always use parentheses except for in class level "macros".
>
> That's also my preference and true of the code I've seen. But "class
> level macros" are often an important part of projects, be that
> ActiveRecord validations, or DSL-like calls in Grape (routes, params, etc).
>
> So I wonder whether we should alter parenless calls' indentation for the
> "simplified" style.

I think I would tend towards saying yes, make it simple/like the chef
codebase. That's consistent and if one wants to line things up, then
one can use parens, even with class level macros (or use long lines
and not care).

> I checked out some popular projects out there. Rails' style is
> inconsistent, with class-level parenless calls lined up vertically and
> the rare use of them inside methods seem to go the "simplified" route.
> I'm not sure if that's intentional, or whether it's just written by
> different people.
>
> Redmine mixes styles, but mostly on the side of lining up.
>
> Spree lines up and overall seems to vindicate the default "lispy"
> indentation style, e.g. here:
>
> https://github.com/spree/spree/blob/main/core/app/models/spree/zone.rb
> https://github.com/spree/spree/blob/main/core/app/models/spree/tax_rate.rb
>
> Though they also like to line up the keyword arguments according to
> Rubocop's defaults
> (https://github.com/spree/spree/blob/main/core/app/models/spree/product.rb#L63),
> something we don't support yet.

This line is rather painful to read and inconsistent with the call
just below it on line 70. I would certainly not advocate for that.

> Do you have a source-available example of a project in your preferred
> coding style?
>
> Chef, perhaps?
>
> https://github.com/chef/chef/blob/main/lib/chef/application/base.rb
> https://github.com/chef/chef/blob/main/lib/chef/application/client.rb

Yeah, I think this is probably the closest with regard to indentation
aside from Eventide, but again, you won't find much indentation there.
Whatever you find will likely be Vim's default, which I believe is the
same simple two space indent we are discussing.

> > This means that any time we decide to split a method invocation on
> > multiple lines we use the basic newline after ( style.
>
> For "class-level macros" as well?

I found inconsistencies in our codebase, so it is time for us to
establish a new norm. My guess is that we will land on using parens
for it. When we do it without parens, it is in the simplified style.

Thank you for your research and work on this, I appreciate it.

Aaron





  reply	other threads:[~2022-12-24  0:17 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-19  2:54 bug#60186: 29.0.60; ruby-mode indentation of multi-line expressions Aaron Jensen
2022-12-20  2:12 ` Dmitry Gutov
2022-12-20  2:17   ` Dmitry Gutov
2022-12-20  4:48   ` Aaron Jensen
2022-12-20  5:56     ` Aaron Jensen
2022-12-20 15:53       ` Dmitry Gutov
2022-12-20 16:19     ` Dmitry Gutov
2022-12-20 17:31       ` Dmitry Gutov
2022-12-21  1:34         ` Aaron Jensen
2022-12-20 20:05       ` Aaron Jensen
2022-12-21 22:48         ` Dmitry Gutov
2022-12-22  2:31           ` Aaron Jensen
2022-12-22 21:21             ` Dmitry Gutov
2022-12-23  4:12               ` Aaron Jensen
2022-12-23 22:26                 ` Dmitry Gutov
2022-12-24  0:17                   ` Aaron Jensen [this message]
2022-12-24 22:47                     ` Dmitry Gutov
2022-12-25  0:12                       ` Aaron Jensen
2022-12-25 21:23                         ` Dmitry Gutov
2022-12-25 21:29                         ` bug#60321: 29.0.60; ruby-mode indentation of hash or array as first arg in multiline method call Dmitry Gutov
2022-12-25 23:46                           ` Aaron Jensen
2022-12-27  1:16                             ` Dmitry Gutov
2022-12-27  1:38                               ` Aaron Jensen
2022-12-25  0:14                       ` bug#60186: 29.0.60; ruby-mode indentation of multi-line expressions Aaron Jensen
2022-12-25 21:29                         ` Dmitry Gutov
2022-12-27  1:28                         ` Dmitry Gutov
2022-12-27  1:47                           ` Aaron Jensen
2022-12-27 15:56                             ` Dmitry Gutov
2022-12-27 16:34                               ` Aaron Jensen
2022-12-27 23:04                                 ` Dmitry Gutov
2022-12-28  0:38                                   ` Aaron Jensen
2022-12-28  1:02                                     ` Dmitry Gutov
2022-12-28  3:47                                       ` Aaron Jensen
2022-12-28 12:47                                         ` Dmitry Gutov
2022-12-28 21:24                                           ` Dmitry Gutov
2022-12-29 22:59                                             ` Aaron Jensen
2022-12-30 15:02                                               ` Dmitry Gutov
2022-12-30 18:00                                                 ` Aaron Jensen
2022-12-30 18:16                                                   ` Aaron Jensen
2022-12-30 22:07                                                     ` Dmitry Gutov
2022-12-31  1:11                                                       ` Aaron Jensen
2023-01-22  3:02                                                         ` Dmitry Gutov
2023-01-22  5:15                                                           ` Aaron Jensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHyO48wn2CBMmzBH25mFT_u_Fk_qDQA=NRnv29MkqDfzRYvA4A@mail.gmail.com' \
    --to=aaronjensen@gmail.com \
    --cc=60186@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).