4 ms·

I have reviewed for pullrequest and you’d be surprised how many things one can fix. Why do you think that you don’t have context? You can look at the whole proj

I have reviewed for pullrequest and you’d be surprised how many things one can fix. Why do you think that you don’t have context? You can look at the whole project and see what’s up. And no, you can’t write programs to do this.

noduerme 5y ago
It's a rare case indeed where I'd be willing to let a third party in on business logic plus the whole source code for something I was developing. I love talking shop but if I'm really having a problem with a structural issue, it's hard to imagine someone outside giving any better advice than people inside who understand the lay of the land. Meanwhile, it's a pretty much totally unacceptable security risk. So what's the upshot to this over an internal code review?
- alexdowad 5y ago
  Well, maybe the people you have available to review code aren't all that good. Nobody ever wants to admit that their team is below average, but 50% of teams are. Maybe due to limitations on team size, it's not possible to have an in-house expert on every technology used.
tialaramex 5y ago
Variable naming is a really obvious example of "you can't write programs" to assess this. Because it needs some general intelligence. Are very short names OK? Generally not, but x is a perfectly good name for an x coordinate in a graphing application for example. On the other hand methods named colour (to get the shade) and shade (to get the colour) need some serious documentary explanation of what the hell you're up to even though in themselves they're acceptable names. Language idioms, and (if this service is expensive enough) per-project idioms are not usually or reliably machine checkable. Also beginners make lots of confusing mistakes, a program may end up missing the woods (e.g. this should just be an iterator, 90% of the code is mechanics that are doing what the language's built-in iterators do) for the trees (the variable names used for all the counters being tracked are bad)

noduerme 5y ago

It's a rare case indeed where I'd be willing to let a third party in on business logic plus the whole source code for something I was developing. I love talking shop but if I'm really having a problem with a structural issue, it's hard to imagine someone outside giving any better advice than people inside who understand the lay of the land. Meanwhile, it's a pretty much totally unacceptable security risk. So what's the upshot to this over an internal code review?

alexdowad 5y ago
Well, maybe the people you have available to review code aren't all that good. Nobody ever wants to admit that their team is below average, but 50% of teams are. Maybe due to limitations on team size, it's not possible to have an in-house expert on every technology used.

tialaramex 5y ago

Variable naming is a really obvious example of "you can't write programs" to assess this. Because it needs some general intelligence. Are very short names OK? Generally not, but x is a perfectly good name for an x coordinate in a graphing application for example. On the other hand methods named colour (to get the shade) and shade (to get the colour) need some serious documentary explanation of what the hell you're up to even though in themselves they're acceptable names. Language idioms, and (if this service is expensive enough) per-project idioms are not usually or reliably machine checkable. Also beginners make lots of confusing mistakes, a program may end up missing the woods (e.g. this should just be an iterator, 90% of the code is mechanics that are doing what the language's built-in iterators do) for the trees (the variable names used for all the counters being tracked are bad)