Skip to content

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

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

Refactoring of int-key mpc.exe tt file#1088
AArnott merged 7 commits intoMessagePack-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
Copy link
Copy Markdown
Member

neuecc commented Oct 24, 2020

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.

Copy link
Copy Markdown
Collaborator

@AArnott AArnott left a comment

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.

}

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.

Copy link
Copy Markdown
Contributor Author

@pCYSl5EDgo pCYSl5EDgo Oct 25, 2020

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.

@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.

Copy link
Copy Markdown
Collaborator

@AArnott AArnott left a comment

Choose a reason for hiding this comment

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

Thanks!

@AArnott
Copy link
Copy Markdown
Collaborator

AArnott commented Oct 25, 2020

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
Copy link
Copy Markdown
Contributor Author

pCYSl5EDgo commented Oct 25, 2020

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