-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Clean-up project files and MSBuild logic #3893
Clean-up project files and MSBuild logic #3893
Conversation
Thanks Nirmal4G for opening a Pull Request! The reviewers will test the PR and highlight if there is any conflict or changes required. If the PR is approved we will proceed to merge the pull request 🙌 |
1825545
to
37819af
Compare
Appreciate the initiative here @Nirmal4G. Can we start with just a whitespace clean-up with no other changes to logic/structure though? It's hard to review something touching so many files when most of it is just whitespace. Then we can start other PRs with other proposed changes. There's also a git setting we can enable for this to help maintain consistency moving forward; as this was called out on a docs PR to do a similar task as well. Was there a tool you used to automate this task as well? |
Yes. For removing |
b98897c
to
fa6f017
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should keep the GhostDoc*
files as we don't have any other bespoke spell/grammar checker, unlike the *DotSettings
files which are for ReSharper and we already document a recommended IDK (VS 2017 and up).
For only spelling check, you have one of the best in the VS Extensions Store: VS Spell Checker |
This PR has been marked as "needs attention 👋" and awaiting a response from the team. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some more minor changes.
Microsoft.Toolkit.HighPerformance/Memory/ReadOnlyMemory2D{T}.cs
Outdated
Show resolved
Hide resolved
Microsoft.Toolkit.Uwp.UI.Controls.DataGrid/CollectionViews/ListCollectionView.cs
Outdated
Show resolved
Hide resolved
Microsoft.Toolkit.Uwp.UI.Controls.DataGrid/DataGrid/DataGridColumnHeader.cs
Outdated
Show resolved
Hide resolved
Microsoft.Toolkit.Uwp.UI.Controls.DataGrid/DataGrid/DataGridColumnHeader.cs
Outdated
Show resolved
Hide resolved
Microsoft.Toolkit.Uwp.UI.Controls.DataGrid/DataGrid/DataGridColumnHeader.cs
Outdated
Show resolved
Hide resolved
Microsoft.Toolkit.Uwp.UI/Extensions/FrameworkElement/FrameworkElementExtensions.LogicalTree.cs
Outdated
Show resolved
Hide resolved
Microsoft.Toolkit.Uwp.UI/Extensions/FrameworkElement/FrameworkElementExtensions.LogicalTree.cs
Outdated
Show resolved
Hide resolved
These changes are done by |
No problem @Nirmal4G, I think I will raise issues on https://github.com/dotnet/format and see what they say. It could be that we have some particular edge cases that they did not test/account for. |
@RosarioPulella I did check. It doesn't work! So, I reverted it back to text file type. I have also formatted the file little bit too! @michael-hawker @Sergio0694 All done for this PR. If anything remains, I'll do it in #3894. Is that okay? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Nirmal4G it'd be good if we could figure out how to run the tools you're using as part of our check-in process or as a validator or something from our cake script to ensure new changes are consistent with newlines and XML formatting.
Is this something you think you could help us with too as part of this PR?
|
||
<!-- .NET Standard 1.4 doesn't have the Span<T> type, ValueTuple or the [Pure] attribute --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm either way on the extra blank line, but especially with the ones below, the comments are about the packages, so it seems a bit odd to move them to outside the item group?
@michael-hawker The formatting I did in this PR is handmade! I'm also looking into updating the Cake build with format validation. But the codebase also contains some files that are custom formatted. Those won't be preserved, if I put any automated formatting tool into the build process. There are a few bug fixes coming after the PRs that I already have. Let me finish those, and then, I'll look into this. Is that okay? |
Thanks @Nirmal4G, sorry for the delay, //Build ate up some time. It's helpful for us to have focus on a PR to solve a specific problem vs. multiple things at once. This is something we should have in our guidelines for the project in the wiki, and something we plan to help outline more in the near future. On that note, this PR is still pretty huge and trying to do many different things. We should really separate it again:
For part 3, cleaning up the MSBuild logic is fine to remove potential issues; but the rest of just re-ordering things or moving comments is causing a lot of churn. If there's an automated way to do something great. We can add something to our build scripts and then run that once against the repo to organize stuff. Otherwise it's not maintainable as if we fix it now it'll get broken in the future. We're also currently trying to maintain two branches with everything for WinUI 3, so the last PR for BOM/whitespace caused a ton of manual merge conflicts that needed to be resolved. Love your enthusiasm here in this space, but we just need to be cognizant of how we can maintain things across the project as a whole now and in the future. If you could split this up and apply this general feedback, then it'll be a lot easier for us to review and merge in changes to unblock the rest of your PRs. Thanks! |
@michael-hawker I'm so sorry for the big PRs. But maintenance PRs are expected to be huge. This patch tree is final, since, the changes here completes the next PR. And that'll be the last of the refactorings. I've sent additional replies through Discord. |
As we save files with trailing white-space removed, the markdown parser tests that depends on the text with trailing white-space fails. So, to prevent any future formatting changes affecting the test result, we'll replace the actual trailing space(s) with an interpolated variable containing those trailing space(s).
The emojis and symbols applied here were corrupted since the following patch. ``` Commit: 7da4442 Author: David Catuhe <david.catuhe@live.fr> Date : Fri Jul 15 07:51:16 2016 -0700 Title : Fixed encodings ```
Runtime Directive files and the text files that have been missed in previous renames have been renamed as proposed!
Add/Remove new-lines (only in project files, xml files and some source files)
Add/Remove leading and trailing white-space (only in comments, code blocks, xml strings)
Format comments to be legible. - Place comment start and end tags on a new line for multi-line comments. - Have space between start and end tags in a single line comment. Place comments where appropriate. - If an entire block is common to the comment then place it above the block. - Only place a comment near or after the block, if it refers exclusively. Sources are not formatted!
To make diff understandable through blame and across similar project files, I have re-organized some lines in these project files. This also improves readability. Previously, the focus is per-project file but now—to maintain project logic across repos and several similar logic across project files, new way of authoring project files is required. This refactor is the start of it.
Change Nuget -> NuGet
Remove commented build logic Remove duplicated build logic
Override projects with an empty Pack target that are not packed into packages. This will prevent any any packages being accidentally produced.
These files were not formatted by the dotnet format tool. So, manually formatting it by hand!
The .NET Formatter breaks in these scenarios. Improves maintainability of code in the long run.
Update renamed files in the build logic Use correct path format in the build logic
Fixes #3896
PR Type
What kind of change does this PR introduce?
What is the current behavior?
It's hard to read and understand the repo because of the redundant logic and un-necessary new-lines and white-spaces.
What is the new behavior?
It's now little bit better to read and understand the repo now that we cleaned it up.
PR Checklist
Please check if your PR fulfils the following requirements:
Other information
rebase
on latestHEAD
and then commit, without updating from the latestHEAD
.fast-forward
orrebase
option if possible.That way, individual commits are preserved since, each commit has large set of changes.