Programming

13389 readers

33 users here now

All things programming and coding related. Subcommunity of Technology.

This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 2 years ago

MODERATORS

alyaza@beehaw.org

Hexorg@beehaw.org

remington@beehaw.org

What does your merge/code review process look like? (beehaw.org)

submitted 1 year ago by pattern@beehaw.org to c/programming@beehaw.org

33 comments fedilink hide all child comments

Hey all! My team at work is struggling with growing pains of getting into a formalized review process, so I was wondering if any of you guys have some things to live or die by in your code reviews. How much of it is manual, or how much is just static code analysis + style guide stuff, etc?

you are viewing a single comment's thread
view the rest of the comments

[–] boopeditandnow@sh.itjust.works 5 points 1 year ago

We're a small team of 6 and follow Git Flow for branching. Every change that wants to go into the develop branch needs an approval on the pull request by one of the two senior developers on the team.

We have (virtual) meetings for any changes that require discussion; some things are difficult to quickly communicate over pull request comments.

When it comes to code style, our standard is "format it using IntelliJ". Same with warnings -- if the IDE calls it out, it's fair game in the review. Personally, I check out every branch I'm reviewing so that I can navigate easily and enable my own warnings, which are generally strict.

Most PR comments start as questions because sometimes questionable looking code can be correct, then things go from there.