Skip to content

Refactoring of int-key mpc.exe tt file#1088

Merged
AArnott merged 7 commits into
MessagePack-CSharp:developfrom
pCYSl5EDgo:mpc-fix-beautify-only
Oct 25, 2020
Merged

Refactoring of int-key mpc.exe tt file#1088
AArnott merged 7 commits into
MessagePack-CSharp:developfrom
pCYSl5EDgo:mpc-fix-beautify-only

Conversation

@pCYSl5EDgo

Copy link
Copy Markdown
Contributor

This is a refactoring of int-key mpc.exe tt file.
This is a subset of #1074.
This PR does not contain any optimization.

This is a refactoring of int-key mpc.exe tt file.
@neuecc

neuecc commented Oct 24, 2020

Copy link
Copy Markdown
Member

Please don't change original formatting.

For example

-
<# } else { #>

+
<#
        }
        else
        {
#>

As a basic policy, I don't want to include a lot of logic or multiple lines of code in the template section.

@pCYSl5EDgo

Copy link
Copy Markdown
Contributor Author

Okay.

Change the iterator `i` type from `int` to `var`.
@pCYSl5EDgo

Copy link
Copy Markdown
Contributor Author

@neuecc
I followed your instruction and fixed it.

@AArnott AArnott left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Thanks for contributing, but I'm left wondering what this PR actually does that's useful. "Refactoring" isn't by itself valuable unless it makes some change in the future easier. Can you update your PR description to 'sell' it more? What does it make better/easier to do in the future?
One thing I can see is that you add global:: to several things, which I imagine makes the generated code more resilient. But you have a bunch of other changes (mostly whitespace which I'd like to see reverted). If there's other good stuff here, can you list them so we know what to look for and appreciate while reviewing?
T4 is particularly obtuse, so anything you can describe in your PR description is appreciated.

Comment thread sandbox/Sandbox/Generated.cs Outdated
}

IFormatterResolver formatterResolver = options.Resolver;
var formatterResolver = options.Resolver;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Why? Please stop mixing irrelevant changes with your PRs. It just makes reviews take longer.
Also, even if you made this style change in a separate PR, I would reject it. var should only be used when the type name already appears elsewhere on the line such that it is obvious.

@pCYSl5EDgo pCYSl5EDgo Oct 25, 2020

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Please stop mixing irrelevant changes with your PRs.

I'm sorry. I take your pointing out seriously and will not do it next time.

var should only be used when the type name already appears elsewhere on the line shuch that it is obvious.

I have a different thought that all generated C# codes must not use using namespace directives.
using namespace directive causes ambiguous type name errors.
var is one good solution to avoid using namespace directives like global::.
var and global:: make the program more resilient.

global::MessagePack.IFormatterResolver formatterResolver = options.Resolver;

The above seems the better.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Oh! A very interesting point. Good insight into the danger of being explicit on typing in a type generated file. Ok, go ahead and use var for IFormatterResolver. But when you can use a keyword (e.g. int) please use that instead of var, as that should still be safe to use.

Comment thread sandbox/Sandbox/Generated.cs Outdated
Comment thread src/MessagePack.GeneratorCore/Generator/FormatterTemplate.tt Outdated
@pCYSl5EDgo

Copy link
Copy Markdown
Contributor Author

Thank you for your review, @AArnott !
All reverts seem to be done. Are there any more changes?
The future PR for #1085 will be based on this.

@AArnott AArnott left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Thanks!

@AArnott

AArnott commented Oct 25, 2020

Copy link
Copy Markdown
Collaborator

The future PR for #1085 will be based on this

Would you prefer that I merge instead of squash to complete this PR then?

@pCYSl5EDgo

pCYSl5EDgo commented Oct 25, 2020

Copy link
Copy Markdown
Contributor Author

Thank you for the approval.

I like merge --squash.
It does not matter to me.

@AArnott
AArnott merged commit f86ec02 into MessagePack-CSharp:develop Oct 25, 2020
@pCYSl5EDgo
pCYSl5EDgo deleted the mpc-fix-beautify-only branch October 25, 2020 16:22
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