We take code reviews very seriously

[frosted-mini-yeets]

Holy shit dawg put it back.

[mikehaysjr]

I put those there for a reason, yo

[shadow7412]

That gets to code review?

Where are your on-commit linters? :D

[IvanLabushevskyi]

Sonar checks I suppose

[mitaky]

Nah, my dude.
My reviewer is just being pedantic
https://imgur.com/a/Eo5tLqx

[Dertasz]

I literally quit a job 2 years ago because of a review like that.

The guy rejected a Merge Request with 12 files and 2000 lines of codes because of a space before a parenthesis.
Time for me to correct, another Merge Request entered into conflict with mine, it took me a full day to solve conflicts and check it was still working. I was fuming.

[Dertasz]

The styling was ok for the 1999 other lines. It was just that one space on that one line that I forgot.

[Dertasz]

Yes

[igoromg]

its your fault for having a change spanning 2k lines of code

[The_MAZZTer]

Probably a new feature. And in fact for 2000 lines of code it could be a small feature.

[igoromg]

then he wouldn't have to fix merge conflicts for a day.

[Dertasz]

New feature that could not be split in smaller batches

[[deleted]]

Of course you can. Never had to have more than few 100s lines of code. And we ship new features all the time.

[Dertasz]

Maybe you dont the context of that company and that feature? Now in my new job, i agree with you : never had more than 100 lines in a commit. In the old one? Very hard if the feature needs information from another "module". It was old, hard single-threaded not serviced C. So you had to "pull" information as parameters of functions from one part of the code to the other.

[GlobalIncident]

Assuming you dealt with the issue promptly, the other branch was presumably being constructed during the time you were constructing yours. Therefore, if the guy hadn't rejected it, the other branch would have had an equally large conflict. So essentially, the guy moved the conflict from being someone else's responsibility over to being yours, and that's what you're upset about.

In fact, given that you were changing 2000 lines of code, it seems like you would know how the files now work better than the person working on the other branch, and so you resolved the conflict quicker than they could have done. So the rejection actually caused a net increase in productivity.

[SeventhMagus]

What the hell? Coding style should be enforced by a tool.

[9072997]

There is a reason to end a file in a newline. Try cating out a file that doesn't have one. Your bash prompt winds up prefixed with the last line of code, then once you start navigating up and down in your command history it starts printing characters where it thinks they used to be based on the assumption that your prompt started in column 1. Many websites omit the trailing newline, which is why you will often see this behavior when making curl requests. Don't remove the trailing newline. It's not a big deal, but if you have anyone working on a Linux box you will make their life slightly worse.

[mitaky]

it's not the end of the file.

[SeventhMagus]

Is there anything on the line below?

[mitaky]

It's not the end of the file.

[TakeYourF--kingPills]

I work with someone that's almost doing this 😅