On Fri, Feb 28, 2020 at 9:44 PM Vinoth Chandar <
mail.vinoth.chan...@gmail.com> wrote:
> >>Also, for some files, reformatting in IDE gives me a lot of changes,
> https://hudi.apache.org/contributing#ide-setup save-actions plugin here
> should help here..
>
Thanks, that solves my problem.
>>Also, for some files, reformatting in IDE gives me a lot of changes,
https://hudi.apache.org/contributing#ide-setup save-actions plugin here
should help here..
Agree on the other two. We need a coherent strategy to keep. : checkstyle,
spotless, IDE formatting in sync...
Without a good design
Yes. Mostly when I run `mvn clean package -DskipTests -DskipITs` locally,
I saw some style issues. Two main things not well taken care of by the
auto reformatting:
- The import order.
- Depending on the format (new line for the body), the lambda function may
throw indentation errors.
Also, for
Hey Ethan,
Thanks for raising this up again. Before we go to fixes, may be it would
good to summarize the current problems one by one. We can then discuss
options?
I have been using checkstyle files to format and it’s been tolerable.
Import order etc does not work. But we have turned it off.
Reviving this thread...
I'm hitting checkstyle issues locally again and thinking that it might be
worth trying GJF. It interoperates well with IntelliJ and the automated
tool reformats the code in 1 shot as Minh suggested.
If sweeping checkstyle fixes in the codebase disrupts development, we
Awesome. Thanks!!
-- Forwarded message -
From: lamberken
Date: Mon, Dec 23, 2019 at 7:11 PM
Subject: Re:Re: IDE setup for code formatting
To:
CC: Minh Pham
Hi @Vinoth
Okay, I will talk with @leesf about the checkstyle. At the end we will give
a relatively better solution
Hi @Vinoth
Okay, I will talk with @leesf about the checkstyle. At the end we will give a
relatively better solution.
best,
lamber-ken
At 2019-12-24 11:00:12, "Vinoth Chandar" wrote:
>Ironically, google style + checkstyle is what we had few months ago :)
>
>Can we have an owner to drive
Ironically, google style + checkstyle is what we had few months ago :)
Can we have an owner to drive this to a point where, the code formatting is
well-documented for contributors?
leesf. and lamber, seems like you have the most context?
On Mon, Dec 23, 2019 at 6:24 PM lamber...@163.com wrote:
Google Java Formatter is an automated tool so it can reformat the entire
codebase in 1 shot.
Sent from my iPhone
> On Dec 23, 2019, at 4:55 PM, lamberken wrote:
>
>
>
> Hi @Minh Pham
>
>
> I agree what @Y Ethan Guo says, we can disable those checkstyle rules which
> can not be automated
Hi @Minh Pham
I agree what @Y Ethan Guo says, we can disable those checkstyle rules which can
not be automated for reformatting for now.
If we replace all new rules with google code style, it may takes more time to
fix.
best,
lamber-ken
On 12/24/2019 03:34,Minh Pham wrote:
What do you guys
Hi @Y Ethan Guo,
I am very willing to follow the community's decision. And your idea is very
good, we can disable those checkstyle rules that cannot be automated for
reformatting in IDE for now.
best,
lamber-ken
At 2019-12-24 03:38:55, "Y Ethan Guo" wrote:
>+1 on auto-formatting the
+1 on auto-formatting the code in IDE based on the checkstyle rules.
Based on my experience with Java and Scala in IntelliJ, there's is indeed
discrepancy on auto formatting code on some custom checkstyle rules. For
such cases, I tried to avoid using them if they do not sacrifice too much
on the
What do you guys think about Google Java Formater?
My opinion is that code style that can’t be automated is not worth enforcing.
Vinoth,
+1 on automating the manual work required at the moment to fix the
checkstyle errors. I think if we are able to use spotless and
at the same time know upfront all the things that would require manual
work, there are few options IMO :
a) Have a template of steps that can easily fix it ->
My 2 cents:
I am also a big fan of code formatting in general, given that its
fully automated. But if that comes at the cost of taking some time off
everyone's time(manual fixing), we need to think through if its really
worth it. Especially, wrt import order, I am not sure if that really adds
Can we exhaustively list all that will be manually even after spotless
plugin is brought back?
On Mon, Dec 23, 2019 at 3:01 AM leesf wrote:
> After bringing spotless plugin back to project, it would automatically fix
> comment check error except for import order error, we need to fix this
>
After bringing spotless plugin back to project, it would automatically fix
comment check error except for import order error, we need to fix this
error manually. In Apache Flink/Calcite, we also fix it manually, and will
also look for other plugins to fix import order error if exist.
Best,
Leesf
I understand. I am saying - we should automate all of this formatting.. :)
How do other projects do it? Other folks, who worked on the code
refactoring/formatting, may be you can also chime in?
On Mon, Dec 23, 2019 at 12:24 AM lamberken wrote:
> Hi @Vinoth,
>
>
> The ImportOrder is a custom
Hi @Vinoth,
The ImportOrder is a custom rule, IDE may can not reformat codes rightly. We
can highlight this rule on contributing guide.
The new ImportOrder rule split import statements into groups and groups are
separated by one blank line.
These groups are 1) org.apache.hudi 2) third
+1 on 1/3 and improving the contributing guide. But on 2, IMO it would be
overloading PULL_REQUEST_TEMPLATE.
Bigger point here is: We need a fully automated way of formatting code
either using IDE or using something like spotless.
I pulled the checkstyle rules into intellij and even then I
Hello all,
I know a bunch of work has happened to format the code base, closer to what
other project are doing..
While working through some checkstyle violations today, I noticed that the
IDE formatting is now out of date with the checkstyle enforced? Manually
fixing these checkstyle issues are
22 matches
Mail list logo