In that spirit, I will call attention to your first sentence, specifically the comma. In my opinion, that can be improved. One of three other constructions would be more appropriate:
I am really happy when people are quite strict in code reviews. It makes me feel safer and I get to learn more.
I am really happy when people are quite strict in code reviews, because it makes me feel safer and I get to learn more.
I am really happy when people are quite strict in code reviews; it makes me feel safer and I get to learn more.
The first of my suggested changes is favoured by those who follow the school of thought that argues that written sentences should be kept short and uncomplicated to make processing easier for those less fluent. To me, it sounds choppy or that you’ve omitted someone asking “Why?” after the first sentence.
Personally, I prefer the middle one, because it is the full expression of a complete state of mind. You have a feeling and a reason for that feeling. There is a sense in which they are inseparable, so not splitting them up seems like a good idea. The “because” explicitly links the feeling and reason.
The semicolon construction was favoured by my grade school teachers in the 1960s, but, as with the first suggestion, it just feels choppy. I tend to overuse semicolons, so I try to go back and either replace them with periods or restructure the sentences to eliminate them. In this particular case, I think the semicolon is preferable to both comma and period, but still inferior to the “because” construction.
I’ve clearly spent too much time hashing stuff out in writers’ groups. :)
I agree with most of that. In formal settings, I prefer full sentences with conjunctions; however, choppy sentences are the ones that often end up in my Lemmy comments.
Reviews have to be balanced to circumstance. There is a big difference between putting out the sales brochure and the notice on the bulletin board. Likewise in coding a cryptographic framework for general consumption and that little script to create personal slideshows based on how you’ve tagged your photos.
As a general rule, wider distributions, public distributions, and long-lived distributions need more ambitious reviews. If the distribution is wide, public, and permanent, then everything needs very detailed scrutiny.
I have found some success in starting with and occasionally revisiting review goals. This helps create and maintain some consistency in a process that is scaled to the task at hand.
Correcting the reviewer.
Notes: “should of” isn’t valid, should implies a verb, of isn’t a verb. I expect you meant “should have”. Please recall this in future submissions.
They should of course keep that in mind, but it’s not that “should” should always be followed by a verb directly. The problem is that “of” in this context is a mishearing/spelling of “have”, so they should in this case have written it like that instead.
I would argue that “should of” is just a naive written rendition of the spoken contraction “should’ve”. They are homophones, so it’s a completely understandable error among those without the relevant education or background. I know only English and was in Grade 9 at a different school before someone corrected me.
Yeah, I learn so much from code reviews and they’ve saved me so much time from dumb mistakes I missed. I’ve also caught no shortage of bugs in other people’s code that saved us all a stressful headache. It’s just vastly easier to fix a bug before it merges than once it breaks a bunch of people.
Assuming you have competent leadership, then it wouldn’t be merged if you missed something obvious. I guess you’re saying that you want more positive reinforcement.
I am really happy when people are quite strict in code reviews, it makes me feel safer and I get to learn more.
Nothing worse than some silent approvals with no real feedback. What if I missed something obvious… and now it’s merged.
To be fair, I also enjoy getting my grammar corrected. I’m juggling 3 languages and things can get messy.
In that spirit, I will call attention to your first sentence, specifically the comma. In my opinion, that can be improved. One of three other constructions would be more appropriate:
The first of my suggested changes is favoured by those who follow the school of thought that argues that written sentences should be kept short and uncomplicated to make processing easier for those less fluent. To me, it sounds choppy or that you’ve omitted someone asking “Why?” after the first sentence.
Personally, I prefer the middle one, because it is the full expression of a complete state of mind. You have a feeling and a reason for that feeling. There is a sense in which they are inseparable, so not splitting them up seems like a good idea. The “because” explicitly links the feeling and reason.
The semicolon construction was favoured by my grade school teachers in the 1960s, but, as with the first suggestion, it just feels choppy. I tend to overuse semicolons, so I try to go back and either replace them with periods or restructure the sentences to eliminate them. In this particular case, I think the semicolon is preferable to both comma and period, but still inferior to the “because” construction.
I’ve clearly spent too much time hashing stuff out in writers’ groups. :)
This is what I live for. :D
I agree with most of that. In formal settings, I prefer full sentences with conjunctions; however, choppy sentences are the ones that often end up in my Lemmy comments.
That only makes sense. We are having a conversation, not creating literature.
Strange, I get a mild hostility vibe from colleagues if I review too ambitiously.
Reviews have to be balanced to circumstance. There is a big difference between putting out the sales brochure and the notice on the bulletin board. Likewise in coding a cryptographic framework for general consumption and that little script to create personal slideshows based on how you’ve tagged your photos.
As a general rule, wider distributions, public distributions, and long-lived distributions need more ambitious reviews. If the distribution is wide, public, and permanent, then everything needs very detailed scrutiny.
I have found some success in starting with and occasionally revisiting review goals. This helps create and maintain some consistency in a process that is scaled to the task at hand.
Removed by mod
Correcting the reviewer.
Notes: “should of” isn’t valid, should implies a verb, of isn’t a verb. I expect you meant “should have”. Please recall this in future submissions.
They should of course keep that in mind, but it’s not that “should” should always be followed by a verb directly. The problem is that “of” in this context is a mishearing/spelling of “have”, so they should in this case have written it like that instead.
I love that you used “should of” in a valid sentence.
Except that it would be “they should, of course,”.
I would argue that “should of” is just a naive written rendition of the spoken contraction “should’ve”. They are homophones, so it’s a completely understandable error among those without the relevant education or background. I know only English and was in Grade 9 at a different school before someone corrected me.
Removed by mod
Yeah, I learn so much from code reviews and they’ve saved me so much time from dumb mistakes I missed. I’ve also caught no shortage of bugs in other people’s code that saved us all a stressful headache. It’s just vastly easier to fix a bug before it merges than once it breaks a bunch of people.
We Americans like to forget that anyone might have any trouble understanding English especially in cases of polyglots.
I don’t know which is your native tongue but from this comment it looks like you’re doing a fine job.
Assuming you have competent leadership, then it wouldn’t be merged if you missed something obvious. I guess you’re saying that you want more positive reinforcement.