Skip to content

Standardize set formatting #22

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

Closed

Conversation

jamescurtin
Copy link
Contributor

Creating this PR as a suggestion: please feel free to disagree & close! 🙂

Previously, sets with fewer than 5 keys were represented on a single line, whereas larger sets were broken up with one element per line. Now, all sets are serialized with the latter behavior.

I see two cases where always expanding sets is useful:

  1. When the key elements are long & the length of the line exceeds the recommended ~80-90 columns, despite there being fewer than 5 elements
  2. When a set has fewer than 5 elements, but more are added. Having consistent formatting rules will result in marginally smaller diffs.

James Curtin added 3 commits August 8, 2019 11:18
Previously, sets with fewer than 5 keys were represented on a single line, whereas larger sets were broken up with one element per line. Now, all sets are serialized with the latter behavior.
@joshtemple
Copy link
Owner

joshtemple commented Aug 12, 2019

Thanks for the suggestion! I'd like to keep this feature in place because it results in more human-looking LookML and decreases file length.

For line width, I would be interested in adding a feature to the serializer that adds line breaks when needed to constrain the width of the output LookML, which would solve that issue. I created #23 to track this. Would be interested in hearing your thoughts over there.

I hear what you're saying about diffs, but I think the amount of scrolling it takes to get through a LookML file is more important to me from a UX standpoint than the length of the diff in the less likely case where a set goes from 5 > 5+ elements.

Also, I realized from commit 7694406 that I need to update the name of that second test! It's not actually a duplicate, just has a duplicate name (it tests behavior with a name key added).

@jamescurtin
Copy link
Contributor Author

👍 Thanks for taking a look!

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.

2 participants