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

[ntuple] use raw strings in ntuple_show for ease of reading #17784

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

silverweed
Copy link
Contributor

Aesthetic-only change: use raw strings instead of string concatenation for the expected values in ntuple_show.

Checklist:

  • tested changes locally
  • updated the docs (if necessary)

@silverweed silverweed requested review from hahnjo and enirolf February 20, 2025 14:43
@silverweed silverweed self-assigned this Feb 20, 2025
@silverweed silverweed requested a review from jblomer as a code owner February 20, 2025 14:43
+ "* Field 1.1.2 : myFloat (float) *\n"
+ "********************************************************************************\n" };
std::string outputFields{
"************************************ NTUPLE ************************************\n"
Copy link
Member

Choose a reason for hiding this comment

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

This portion is better matched the indentation/format.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure if I interpret this comment correctly: you mean you like this more than the raw strings? In this case I could do without a raw string because there are no tons of " to escape, so it works; in all other cases I personally find the raw string much more readable.
However, as it's a subjective choice, the only way to decide is by majority vote I think.

+ " \"atomic\": false\n"
+ "}\n" };
std::string fString{
R"({
Copy link
Member

Choose a reason for hiding this comment

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

This PR both this syntax and compile time string concatenation (#17784 (comment)).

The main disadvantage (not fatal) is that this section is not indented like the surrounding code (whereas the other syntax is).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

True, but I'd argue the advantage in having a "heredoc-style" string where you see the expected output 1:1 outweighs the misindentation

Copy link

Test Results

    18 files      18 suites   4d 9h 22m 49s ⏱️
 2 718 tests  2 718 ✅ 0 💤 0 ❌
47 241 runs  47 241 ✅ 0 💤 0 ❌

Results for commit a3c5416.

Copy link
Member

@hahnjo hahnjo left a comment

Choose a reason for hiding this comment

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

I don't really mind either way, but I think there are again formatting-only changes in the commit that make it hard to determine which lines just have whitespace-changes and which are actually modified...

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

Successfully merging this pull request may close these issues.

3 participants