Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code style #663

Merged
merged 7 commits into from
Oct 25, 2017
Merged

Code style #663

merged 7 commits into from
Oct 25, 2017

Conversation

krlmlr
Copy link
Member

@krlmlr krlmlr commented Oct 24, 2017

Each commit represents a styling level of styler. Some pieces are converted incorrectly, I have added issues to the styler repo and left the code untouched in these cases. One commit is a manual change, all other changes are automatic.

Reference:

CC @lorenzwalthert.

@krlmlr krlmlr requested a review from hadley October 24, 2017 11:44
Copy link
Member

@hadley hadley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great overall. I added a few comments

@@ -48,7 +48,6 @@ NULL
#' @param ... other values passed to [all.equal()]
expect_equal <- function(object, expected, ..., info = NULL, label = NULL,
expected.label = NULL) {

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally styler wouldn't strip this new line. It doesn't matter here, but in general it seems like a bad idea

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we define a rule when to add/keep a newline after an opening brace? Is this just for top-level functions or for blocks in general?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I generally prefer a newline if the function def span multiple lines as it more clearly distinguishes the body from the args.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So should we

  • Add a section to the tidyverse style guide to leave one line blank after a multi-line function declaration and
  • make styler in general preserving line breaks
    ?

Not sure whether for the second bullet, we could also make some blank line formatting optional, but I could not think of anything particularly meaningful. Maybe one can choose to either to not touch blank lines, or to reduce the amount of blank lines to one if there is at least two blank lines next to each other.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how consistently I adhere to this style. There's also the question of wrapping multiline formals - we should probably be consistent with other calls, and if all arguments don't fit on one line, each argument gets it's own line.

@@ -67,7 +67,8 @@ show_failure <- function(expr) {
#' @rdname expect_success
#' @param path Path to save failure output
expect_known_failure <- function(path, expr) {
FailureReporter <- R6::R6Class("FailureReporter", inherit = CheckReporter,
FailureReporter <- R6::R6Class(
"FailureReporter", inherit = CheckReporter,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why doesn't "FailureReporter" stay on the first line? (Given that it's an unnamed argument that fits)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because that is not yet implemented in styler. See r-lib/styler#246. For now, the line is broken after the first parenthesis with strict = TRUE if the whole call does not fit on one line.

timer = NULL,
doc = NULL,
errors = NULL,
results = NULL,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if there's a way that styler could detect if the = were aligned, and if so, leave as is

R/stack.R Outdated
@@ -43,8 +42,8 @@ Stack <- R6Class(
),

private = list(
stack = NULL, # A list that holds the items
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Preserving this alignment would also be nice

test_that('simple', { # line 2
expect_true(FALSE) # line 3
}) # line 4
context("testing testFile") # line 1
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you manually revert the changes to this file? The indenting of the comments is particularly important here

@krlmlr krlmlr mentioned this pull request Oct 25, 2017
4 tasks
@krlmlr
Copy link
Member Author

krlmlr commented Oct 25, 2017

Thanks. I've changed alignment and applied a few more tweaks. The code of this PR doesn't change when running styler:::style_pkg(scope = "tokens") except in situations for which I have created issues in the styler repo.

@krlmlr krlmlr merged commit 1faa32f into r-lib:master Oct 25, 2017
@krlmlr krlmlr deleted the f-styler branch October 25, 2017 07:14
@lorenzwalthert
Copy link

Reference: r-lib/styler#240

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants