Working on some #code written by an #intern a few years ago and it's taking all of my energy to just add the feature and not refactor the whole thing. What's the point of having an intern and not reviewing their code as they go to prevent these issues? So verbose, so much duplication

I guess I've been writing tools all by myself here with no review either, hopefully whoever takes them over eventually feels like I designed them reasonably

gör CR o snubben har skapat en (totalt onödig dessutom) variabel:

var10000

...?
det luktar chatGpt
sorry, blir decline på den

Our next workshop will be presented by SORTEE president Ed Ivimey-Cook:

"Reproducible data analysis in R"

Ed will introduce the basics of reproducible projects, data & code, and conduct a code review.

Register at https://events.humanitix.com/sortee-workshop-reproducible-data-analysis-in-r

Looking for resources on how to do good code reviews - technically, as a crafts-person, socially. Do you have suggestions?

I would love to read a zine by @b0rk on the subject

One interesting article I recently read was “Understanding and Effectively Mitigating Code Review Anxiety” by @grimalkina and @CSLee. https://doi.org/10.1007/s10664-024-10550-9

Thesis statement

Hey, has anyone seen a good #AI #CodeReview tool? It's one of the few areas I think it could add value. Ideally something you have experience with.

Nitpicking does not really help anyone

I finally fixed the asynchronous block placement logic. I've attached the code. Something just doesn't feel right about his. Roast me in the comments with a code review! #codereview #gamedev #unity #csharp

Unpopular opinion on software development

Yesterday, I came across CI cultists.
They were preaching one should merge in main multiple times a day.

Quite frankly, I associate this behaviour to lab rats compulsively clicking the button to get gratifications (please don't do that to rats).

I think developers should refrain from becoming merge junkies. Code review is essential for good code quality. Automated tests suck at detecting logical errors, security vulnerabilities, and even decent code coverage.

Also, I believe pair programming is absolutely not a strategy to allow continuous integration. Everybody involved in the development process is drunk on their own bullshit reasons they made up to justify their poor design. Either the code review should be done by someone else, or the developers should sober up for a fortnight before code reviewing their own code.

PS: I am a software developer. I get drunk on my own bullshit as well.

#fediverse hivemind, I have a code review question.

I have done a massive refactor of a codebase, and I want my team to review it. Do you prefer:

a) massive pull request and iterate on it over days/weeks
b) break it down into chunks and integrate progressively

I know b) sounds intuitively like the right choice, but what do you do if you find errors in the first PR? How do you propagate that to other branches?

I'm sure there are good reasons to use `Vec<Option<T>>`. But I'm equally sure that yours isn't one of them. Sorry.

#proTip: When you open a file of #code to edit it, fill in the #commitMessage with the goal of the changes you want to make in your #versionControl interface.

After you make your changes, only "Add" the changes necessary to accomplish the goal in the commit message; anything else should go in a separate #commit.

This keeps you focused on the task, and prevents your #commits from getting polluted with unrelated work that may confuse #codeReview.

Review Board 7 is here! This release is all about improving your code review flow, day or night, with:

Dark Mode and Light Mode themes
Image review in the diff viewer
Microsoft Teams support
Mobile diff review

https://www.reviewboard.org/news/2024/06/06/review-board-7-its-a-bright-day-for-code-review/

Codereview feedback should only be in the form of automated tests.

If your suggested changes don't result in testable outcomes then they are a waste of time.