Side effect of Participation in Google Summer of Code: 100 Pull Requests

End of 2025

Some thoughts on clean code habr.com/ru/amp/publications…

Checkstyle 12.0.0 - checkstyle.org/releasenotes.… Breaking backward compatibility that will affect all third-party javadoc checks: New ANTLR Grammar for Javadoc Comments

Checkstyle 11.0.0 - checkstyle.org/releasenotes.… Migrated to jdk17. Breaking backward compatibility: 1 New functionality: 1 Bug fixes: 4

Side effect of participation in GSoC 100 Pull Requests.

To expedite open source Pull Request reviews, split unrelated changes into separate submissions. joshuakgoldberg.com/blog/spl…

End of 2024:

Last release of 2024: 10.21.1 checkstyle.org/releasenotes.…

We banned pure unit tests several years ago in our project, moved almost 90% of functional coverage to end-to-end. Glad that at 2024 there are more articles on it. Increase Test Fidelity By Avoiding Mocks: testing.googleblog.com/2024/… Beyond the Test Pyramid: testing.googleblog.com/2024/…

checkstyle.org/releasenotes.… New functionality: 2 Bug fixes: 7 This release is most compatible with google-java-format and updated to latest Google Java Style Guide checkstyle.org/google_style.…

Clean Code is Coding with Empathy medium.com/bigcommerce-devel…

We welcoming hackers from all over the world. hacktoberfest.com/ digitalocean.com/open-source… We have a lot of materials on how to start github.com/checkstyle/checks… , search even in YouTube to get bunch of materials.

On approval comments. A friend of mine came up with a new way to approve pull requests, replacing the usual LGTM (looks good to me) with IOTC (I own this code). The reasoning behind this is that LGTM is often used too casually - it's easy to say something looks good without really taking responsibility for the code. After all, "good" can mean different things to different people. It's almost like saying, "This code looks okay to me, but I'm not really connected to it." In contrast, IOTC puts more on your shoulders as the reviewer. It forces you to think more critically about what you're approving to merge into the main branch. When you say IOTC, you're taking full responsibility for the code - even if you didn't write it. This makes perfect sense in a team environment, where once code is merged, it's owned by the team. Any issues or bugs become your responsibility, especially if the original author isn't around. Using IOTC means you're attaching yourself to the code even before it is merged, ensuring you fully understand it and confirm its quality. It reminds you that you're going to support this stuff. And what's your go-to approval comment?

Checkstyle 10.18.2 - checkstyle.org/releasenotes.… Bug fixes: 7

Reasonable opinion on code quality - pvs-studio.com/en/blog/posts… But in our project we are fanatic. We use all free quality tools, we reached and keep 100% coverage for about 10 years, we close to reach 100% on all mutations of pitest. We never regret about our fanaticism.

Checkstyle 10.18.0 - checkstyle.org/releasenotes.… Breaking backward compatibility: 3 New functionality: 24 Bug fixes: 14

Community driven materials on how to do contribution to open source and our project specifically. youtube.com/playlist?list=PL…

Image is from YouTube suggestions. I saw such eyes so many times.

This year, I will mentor a #GSoC project to improve the Checksyle Plugin for @Gradle in the @Kotlin Foundation! It includes offering better declarative syntax in Kotlin DSL, and alignment with new @checkstyle_java features Looking for interested users! summerofcode.withgoogle.com/…