4 ms·

Also, having consistent formatting makes it very easy to read through large amounts of code. If you know how the code is laid out, you don’t need to focus on ev

by d3nj4l 6y ago

Also, having consistent formatting makes it very easy to read through large amounts of code. If you know how the code is laid out, you don’t need to focus on everything and can “squint” through it to get a good idea of what’s going on.

Rapzid 6y ago
I believe though that you should just have some system in place to automatically check/fix these issues(for the most part). I've been in far too many environments though where PR reviews are just surface-level formatting nits and don't address functionality or architecture at all..
gpanders 6y ago
Agreed with you and the GP. In one project I’m on, I pushed for linting and formatting checks in our CI not because I’m an “insane weirdo” who cares too much about formatting, but precisely because I don’t care, I just want it to be consistent. I don’t really have an opinion about which style or format or whatever is better, I just don’t want to have to read through 6 different coding styles when I scan through my colleagues’ code.
- SAI_Peregrinus 6y ago
  Having a consistent style enforced by an automatic tool set (linter/autoformatter/etc) means no time needs to be wasted in any given PR arguing about style, or waiting for someone to fix a style mistake. You might still waste time arguing about what the rules should be, but that's often less than the cumulative waste of fixing avoidable crap.
RcouF1uZ4gsC 6y ago
The solution to this is to use an automated formatting tool for the entire team and have it automatically run prior to review and be done with it.
- rmk 6y ago
  This is done in many teams. Go has made it really easy via its gofmt tool. The trouble is that it's hard to do on a large existing codebase that's not consistently formatted: doing a mass format messes with the line-by-line commit history, and on occasion introduces bugs.

by d3nj4l 6y ago

Rapzid 6y ago

I believe though that you should just have some system in place to automatically check/fix these issues(for the most part). I've been in far too many environments though where PR reviews are just surface-level formatting nits and don't address functionality or architecture at all..

gpanders 6y ago

Agreed with you and the GP. In one project I’m on, I pushed for linting and formatting checks in our CI not because I’m an “insane weirdo” who cares too much about formatting, but precisely because I don’t care, I just want it to be consistent. I don’t really have an opinion about which style or format or whatever is better, I just don’t want to have to read through 6 different coding styles when I scan through my colleagues’ code.

SAI_Peregrinus 6y ago
Having a consistent style enforced by an automatic tool set (linter/autoformatter/etc) means no time needs to be wasted in any given PR arguing about style, or waiting for someone to fix a style mistake. You might still waste time arguing about what the rules should be, but that's often less than the cumulative waste of fixing avoidable crap.

RcouF1uZ4gsC 6y ago

The solution to this is to use an automated formatting tool for the entire team and have it automatically run prior to review and be done with it.

rmk 6y ago
This is done in many teams. Go has made it really easy via its gofmt tool. The trouble is that it's hard to do on a large existing codebase that's not consistently formatted: doing a mass format messes with the line-by-line commit history, and on occasion introduces bugs.