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

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

Merged
merged 7 commits into from Oct 25, 2020

Conversation

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

Okay.

@pCYSl5EDgo
Copy link
Contributor Author

@neuecc
I followed your instruction and fixed it.

Copy link
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.

{
if (value == null)
{
writer.WriteNil();
return;
}

IFormatterResolver formatterResolver = options.Resolver;
var formatterResolver = options.Resolver;
Copy link
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
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
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.

sandbox/Sandbox/Generated.cs Outdated Show resolved Hide resolved
@pCYSl5EDgo
Copy link
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
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
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
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.

None yet

3 participants