3 ms·

I curse the inferior linter formatting and at the same time would not have it any other way because why? Some diva would come in and put up a MR reformatting ha

I curse the inferior linter formatting and at the same time would not have it any other way because why? Some diva would come in and put up a MR reformatting half the code base to their preferred way, mixed in with the actual change they are making and I would have to hunt for the actual changes in the reformatting noise. And then we would spend half a day arguing about it like in the good old days. Fast forward six months and there would be 6 different code styles in the codebase and it would just be terrible. :deep breaths:

busterarm 3y ago
Sorry. Guilty party here. I used to be that diva at times, but also came around to your point of view after being on the other side of that several times myself. But I think the biggest thing as I move up and spend more time reviewing code than writing it...style preferences make it so much easier to review code. Linters have given back years of my life at this point!
resters 3y ago
Why not just set up a rule to auto-format the code before it is committed so that nobody wastes time discussing formatting trivialities and the repo stays consistent?
- foobarian 3y ago
  It would be fantastic if there was a good normal-form formatter I could use for local work, and let automation format the code back to lint style. Unfortunately with something like IntelliJ/Java the commit-time reformat is not reversible. Maybe google's Java formatter is, hmm.
  - kcrwfrd_ 3y ago
    In JavaScript land, prettier auto-formatting the code on file save is quite lovely. I would not be a fan of commit hook auto-formatting.
beryilma 3y ago
In my experience, it is not the divas who are the problem, but inexperienced developers (especially ones from non-CS background) who have a weird/no sense of formatting. I have seen my share of strange, inconsistent formatting in code reviews with junior developers.
aulin 3y ago
I've worked in a place where reviews were obsessed with coding style. No one noticed serious bugs, but forget a space in the right place and you'd be doomed. And yet people still managed to rewrite stuff to their preferred style while managing to not violate any rule. No prescription about function and variable names? they'd change every single one their way. No prescription about argument alignment, they'd change it. Everything not esplicitly forbidden was an outlet to express their creativity or maybe tame their frustration.
JTyQZSnP3cQGa8B 3y ago
This has never been a problem for me. Coding guidelines, clang-format and precommit scripts can do this automatically. Also a senior should reject or revert the work of the diva. You shouldn't accept this at all.
fransje26 2y ago
> Some diva would come in and put up a MR reformatting half the code base to their preferred way, mixed in with the actual change they are making Nice. It adds a bit of spice to your git-bisect bug-hunting, to keep you on your toes.. Who doesn't like a good challenge?

busterarm 3y ago

Sorry. Guilty party here. I used to be that diva at times, but also came around to your point of view after being on the other side of that several times myself. But I think the biggest thing as I move up and spend more time reviewing code than writing it...style preferences make it so much easier to review code. Linters have given back years of my life at this point!

resters 3y ago

Why not just set up a rule to auto-format the code before it is committed so that nobody wastes time discussing formatting trivialities and the repo stays consistent?

foobarian 3y ago
It would be fantastic if there was a good normal-form formatter I could use for local work, and let automation format the code back to lint style. Unfortunately with something like IntelliJ/Java the commit-time reformat is not reversible. Maybe google's Java formatter is, hmm.
- kcrwfrd_ 3y ago
  In JavaScript land, prettier auto-formatting the code on file save is quite lovely. I would not be a fan of commit hook auto-formatting.

beryilma 3y ago

In my experience, it is not the divas who are the problem, but inexperienced developers (especially ones from non-CS background) who have a weird/no sense of formatting. I have seen my share of strange, inconsistent formatting in code reviews with junior developers.

aulin 3y ago

I've worked in a place where reviews were obsessed with coding style. No one noticed serious bugs, but forget a space in the right place and you'd be doomed. And yet people still managed to rewrite stuff to their preferred style while managing to not violate any rule. No prescription about function and variable names? they'd change every single one their way. No prescription about argument alignment, they'd change it. Everything not esplicitly forbidden was an outlet to express their creativity or maybe tame their frustration.

JTyQZSnP3cQGa8B 3y ago

This has never been a problem for me. Coding guidelines, clang-format and precommit scripts can do this automatically. Also a senior should reject or revert the work of the diva. You shouldn't accept this at all.

fransje26 2y ago

> Some diva would come in and put up a MR reformatting half the code base to their preferred way, mixed in with the actual change they are making Nice. It adds a bit of spice to your git-bisect bug-hunting, to keep you on your toes.. Who doesn't like a good challenge?