3 ms·
Totally. I'm also curious about consistency: if you get reviewers who prefer different idioms and stylistic points between review, what does that do for codebas
by kornish 9y ago
Totally. I'm also curious about consistency: if you get reviewers who prefer different idioms and stylistic points between review, what does that do for codebase style over time? I wonder how their quality control operates on the reviewer side.
- encoderer 9y agoIf that’s what you’re covering or expecting from code reviews you’re doing it wrong. The only right answer here is automated code formatting and linting.
- aassddffasdf 9y agoThat is not what is meant by "idioms and stylistic aspects". Take, e.g. `o.map(v => ...).getOrElse(v2)` vs `o match case Some(v) => ... case None => v2`. The former is idiomatic and preferred over the latter (but of course some jackass somewhere will disagree and argue incessantly about it).
- kornish 9y agoExactly right. I'm not referring to which line the braces go on, but rather how domains get modeled, how errors are handled, how functional or imperative the code is, etc.
- paulddraper 9y agoSide point, but AFIAK `fold()()` is most idiomatic in Scala.
- Nullabillity 9y agoAnd yet, `match` is the only one that gets correct type inference. `.map(ifSome).getOrElse(ifNone)` infers the type from `ifSome`, and forces `ifNone` to conform. `.fold(ifNone)(ifSome)` infers the type from `ifNone`, and forces `ifSome` to conform. Meanwhile, `match { case Some(x) => ifSome(x); case None(x) => ifNone }` will correctly infer from both cases at once, and give you the greatest common ancestor.
- paulddraper 9y agoYeah, I agree. ¯\_(ツ)_/¯
- lyal 9y agoWe both internally and have customer rate reviews -- we also establish corpus details with customers during the onboarding process. On the whole, we believe it's valuable to stay within the structure established within a team and nudge things forward rather than making wholesale changes to disrupt.