Joined February 2014
Checkstyle 14.0.0 checkstyle.org/releasenotes.… Java Grammar updated to support module-info.java
2
2
114
Side effect of Participation in Google Summer of Code: +100 Pull Requests
2
72
Checkstyle 12.0.0 - checkstyle.org/releasenotes.… Breaking backward compatibility that will affect all third-party javadoc checks: New ANTLR Grammar for Javadoc Comments
1
104
Checkstyle 11.0.0 - checkstyle.org/releasenotes.… Migrated to jdk17. Breaking backward compatibility: 1 New functionality: 1 Bug fixes: 4
2
116
Side effect of participation in GSoC +100 Pull Requests.
5
135
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/…
1
138
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.…
1
2
141
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.
2
3
201
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?
1
1
4
161
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.
1
81
Checkstyle 10.18.0 - checkstyle.org/releasenotes.… Breaking backward compatibility: 3 New functionality: 24 Bug fixes: 14
1
1
2
117
Community driven materials on how to do contribution to open source and our project specifically. youtube.com/playlist?list=PL…
1
2
114
Image is from YouTube suggestions. I saw such eyes so many times.
2
97