261–270 of 302 posts
Earlier quoted context omitted.
I'll say what I said downthread to someone who made something similar: This costs more than twice as much as GitHub, does it provide twice the value?
GitHub's code review is pretty mediocre imo... just left Meta and I miss phabricator. I'm interested to see new stuff, hope I can get off the waitlist!
Earlier quoted context omitted.
I'll say what I said downthread to someone who made something similar: This costs more than twice as much as GitHub, does it provide twice the value?
Fair question. We're aiming to provide enough value for the price we'll ultimate target. We aren't charging yet, but wanted to provide people with some of our rough thoughts on pricing since it's a common question. For now, it's free for folks who want to kick the tires.
Earlier quoted context omitted.
This looks like a good tool, and I was tempted to try it, but it costs twice as much as GitHub itself, and I'm not sure it would give us twice as much value.
Honestly that’s fair because GitHub is very good and probably too cheap. If they doubled their prices tomorrow I wouldn’t even consider leaving. What would you pay for CodeApprove? Also if you email me I’m happy to set you up with a 6-month free trial with no credit card required. Maybe you’ll like it more than you think!
Yeah, that's probably true, it's just that I'm getting subscription fatigue, with every little tool like "Google Meet links for Slack!" wanting $5/mo/user. I commented something similar upthread, but maybe "free for the first five users, $9/mo/user after" would be much more aligned with your customers' incentives, and would allow you to get a foothold in companies when they're small, and be paid as they expand.
I don't know yet what I'd pay, as I haven't tried it and don't know what value it gives me (it might well be worth the $9!). I'd appreciate a trial, I could send it around the company and see if it makes reviews less painful.
Earlier quoted context omitted.
It’s called cspell https://cspell.org/
Does that understand that when talking about HTTP headers I talk about "referer" but when talking about JavaScript I have to use "referrer"? - What is wrong in one place can be different elsewhere. Terminology, spelling, accepted abbreviations depend very much on context. And sometimes even a wrong spelling is right as it's in some standard ...
I bet GPT-4 understands that.
(Though I have no personal experience using it for code review.)
Earlier quoted context omitted.
IMO you should never provide feedback that can be implemented as an automated check. If you don't like deeply nested control flow, then you should catch that with static analysis. If you need code coverage, you should require it for merging. Implement your check and provide a new PR to fix your nitpicks, or shut up. The goal is to put 100% of the focus on correctness.
This seems precisely backward to me. Programmers are humans, not input/output machines, and there's definitely a role for encouraging a certain standard of judgment that doesn't require tooling to enforce. To argue otherwise seems akin to arguing that any bad behavior is fine that isn't explicitly banned in paragraph 5 subsection D. Tooling is expensive, especially for smaller teams, and should be saved for phenomena…
Earlier quoted context omitted.
IMO you should never provide feedback that can be implemented as an automated check. If you don't like deeply nested control flow, then you should catch that with static analysis. If you need code coverage, you should require it for merging. Implement your check and provide a new PR to fix your nitpicks, or shut up. The goal is to put 100% of the focus on correctness.
On that note, what good code coverage tools are out there? GitHub and Gerrit, as well as (egads) ReviewBoard don't seem to have native support for this in the review. It's unfortunate since it seems super useful to have be up front and visible.
I generally like the tool. When your code review tool is really nice one unexpected negative is that it can create a culture of nitpicking. Sometimes it’s not worth arguing over small details like variable naming but the tool makes it really easy for things to head in that direction. Sometimes variable naming isn’t a small detail. But sometimes it is and it’s a waste of everyone’s time to argue about it.
but naming is quite important. May be it's not that this is a nitpick, but that previous review tools prevent the fruitful discussion of names.
Earlier quoted context omitted.
You experience one extreme ans then decided to take the opposite extreme stance. I recommend being more pragmatic.
Eventually, sure. I'm also starting to think this is how the Paradox of Tolerance happens. I'm intolerant of intolerance these days. I'm much more tolerant of people having their way of doing things than I was just 10 years ago. However, as soon as one person comes along and says "It MUST be this way because QUALITY!" I go into intolerance mode and don't tolerate it. Now, if you can give me a reason grounded in compu…
I have spent almost 15 years in mostly AWS and I want to keep myself in check and make sure people don't take my suggestions as the vague "quality" as you so mention just because of my seniority.
Here is the most recent PR I did for a relatively young person in my org. Part of the PR was doing a type of snake_case to CamelCase conversion from some user inputs to some enums classes. It was done manually with String manipulation and playing with indexes etc. It also came with a bunch of unit tests to make sure the conversion was working correctly.
I put in a comment along the lines of "hey, this conversion seems like it can be done with this Apache Commons Text library; given that we are already using it in the same project in some other place, we can remove this manual code and call the library function; we can even remove the tests assuming the well-tested library is doing the right thing".
Was this comment warranted? If you think this is a reasonable comment, what computer science principle would you say it is based on?
One thing I like about it is that reviewers can suggest changes and you can accept them inline. Makes it really easy to deal with nits.
You can do that in Github, but for some reason a lot of reviewers are not familiar or bother doing that. Fixing nits that way or giving a suggestion improves turnaround speed greatly and builds a relationship between reviewer and proposer and the final product/commit(s).
Earlier quoted context omitted.
Fair question. We're aiming to provide enough value for the price we'll ultimate target. We aren't charging yet, but wanted to provide people with some of our rough thoughts on pricing since it's a common question. For now, it's free for folks who want to kick the tires.
I'll probably try it, but there's no way I can get our finance department to pay $900/mo for something we aren't sure if we're going to use. Maybe pricing it as "Free for the first five users, $9/mo/user afterwards" would be much better aligned with the customers' incentives.