The problem with this approach (that their first example already demonstrates), is that you'll almost immediately start with a "this type of file is OK" solution, and whether something should go in git doesn't really have a super strong correlation with file type.
It hobbles `git status` and essentially forces you to keep track of what you've changed yourself (since ignored files won't show up there), and it can instill a false sense of security that `git add .` is safe when it might not be.
I use alint [0][1] to define and enforce rules about files/globs that should or shouldn't be committed, among other things. You can configure it run as a pre-commit hook or in CI.
I find the other direction works ok as well - Sonnet 5 with Opus as an advisor - all the "Opusisms" get hidden from you since the convo is between Sonnet and Opus but you still get pretty decent results.
I don't think there's any functional difference between "chat about this" and just directly entering what you'd like to do / ask about in the "Tell Claude what to do" option, I think that's pretty much exactly what you're looking for.
In this hypothetical, at that point, those people are going to be literal no exaggeration oligarchs (arguably they are now) - just saying they should give up what would amount to a large percentage of their wealth isn't going to go over well.
1. There's far less product managers
2. What makes you so sure that product managers won't be automated away? The breathless pronouncements from the people running these companies aren't that there won't be software developers, it's that there won't be knowledge workers.
As someone that as teenager observe traditional shoe factories being automated away, or the production being sent offshore, the robot factory can function with 10% of the original staff, or even less.
Now for the sake of argument multiply the 90% of the employees that were laid off, with the amount of companies that do the same, there aren't enough roles whatever those may be for everyone else now at the job center.
Fortunately we are humans, and professionally trained humans at that, and we can judge readability and comprehensibility of methods through better measures than whether it crosses a boundary of number of lines.
There is absolutely a place for PR reviews, and I don't think the person you were replying to was against that, just that PR reviews would be better by actually judging things like readability directly rather than relying on measures that estimate those qualities.
I can think of many times arbitrary rules like linting or Clean Code-esque standards resulted in a "solution" of making my code less readable.
> Fortunately we are humans, and professionally trained humans at that, and we can judge readability and comprehensibility of methods through better measures than whether it crosses a boundary of number of lines.
It's very hard to make a function you need to scroll back and forth to understand readable. Break it into smaller ideas that are more easily reasoned about. We love to think we are too clever, but we are not and we always need to keep an eye on cognitive load - having epifanies when you finally understand how something works is a great feeling, but relying on epifanies coming to you when you are trying to figure out how something works because it's not working now, is a terrible practice.
I think the rule that "functions should be small enough that they should be easily reasoned about" is a reasonable rule, and it makes sense to follow it 95% of the time.
"Functions should be 5 lines or less" is a measure that approximates that rule, but isn't exactly the same thing - I hope you agree we could both come up with 4 line functions that are impossibly complex or 6 line functions that are easily reasoned about.
I think with Clean Code (and a lot of these kinds of things - Design Patterns is a great old example of this), people can get too dogmatic about applying these sort of approximated rules, when it would make a lot more sense for someone else (i.e. not the code writer) to use their best judgement and just directly answer the question "is this function easy to reason about?" rather than using the approximate measure.
This can’t really be a serious guideline unless you are writing APL, in which 5 lines can already be daunting to grasp. This guidance depends on the language. For Python, once you get over 50 lines it starts to look like you don’t actually know what you are doing anymore.
Sorry, you're right - 20 lines or less is the recommendation in the actual text of Clean Code. I have seen people try to push that down to 5 in Ruby on Rails development (IIRC, the most popular linter at one time tried to enforce 5 lines)
In any case, the point stands - there are 19 line functions that are too sense, and 21 line functions that are sensible.
I think it’s very easy to over apply that rule, and break a large function into a lot of small functions that you need to scroll up and down to reason about.
Here’s a 150 line long function I wrote which I think is quite beautiful:
This function traverses a DAG given 2 points in the dag, A and B. It breaks the dag into 4 regions - the nodes which are (transitively) only in the parent subgraph of A, B, in both or - implicitly - in neither. It runs in O(n log n) time.
How would you improve this function? It could use a better doc comment. But do you honestly think it would be better if it were broken into a lot of small functions, each called once? How would you do it?
> Fortunately we are humans, and professionally trained humans at that, and we can judge readability and comprehensibility of methods through better measures than whether it crosses a boundary of number of lines.
Lines or code is an indicator, not a goal. If you write long-winded functions, your code is bug prone and harder to test and verify. If you refactor it, it gets shorter. Where do you draw the line?
The same goes for how many characters you accept between two line breaks. Some go for 76. Some for 130 or more. There is no difference if your line has 129 or 131 chatacters, but if you spew a comment with 999 characters in a single line then your feedback is actionable if you say "hey man, don't be that guy. Rewrite your comment and make it readable."
> (...) PR reviews would be better by actually judging things like readability directly rather than relying on measures that estimate those qualities.
Not really. Calling out basic things like "this function is far too long" is clear, objective, and actionable feedback. That is a good PR comment.
Dismissing clear and actionable feedback as some guys whims is a red flag, and a telltale sign of someone who has no interest to improve their output and address issues.
I think what I intended to get across isn't too incompatible with what you're saying. I think it's fine to say "this function is too long", and long functions generally speaking should be something that's worthy of a code review comment.
I think the issue that originally launched this thread of the discussion is people who take the specific rules to a dogmatic level and apply rules blindly, and transform "functions should not be long" to "functions should be less than 20 lines no matter what". 20 lines (or whatever standard you land on) should be a guideline and not an inviolable law of the universe, and if reducing a method below 20 lines harms comprehensibility and readability, you're letting the guideline get in the way of the actual goal.
The difference between "if you have nothing to hide" and the argument you're replying to is that "if you have nothing to hide" is used as a justification for why it's not a problem for authorities to be able to randomly search you, while the parent comment isn't attempting to justify, just acknowledge the reality of the situation.
A blank phone is suspicious in and of itself and probably invites more questioning and suspicion.
And from personal experience, once a border guard is suspicious of you and you're a non-citizen, you're fighting a losing battle to get into that country, regardless of whether you're doing anything shady / illegal.
The most straightforward answer I think is to use common apps for more commonplace social media activities and separate apps that can be removed from your phone when you're crossing a border for things you want to keep private. It's not perfect privacy, but I think a border is one thing that for better or worse you'll need to accept some compromises on.
I like the look of the new design (mostly, there's some cases where whitespace can get a bit excessive), but I still don't like the technology behind it. It's funny that modern javascript based sites were built to make things feel more interactive and snappy, but at least in Reddit's case completely failed at that and the old HTML based site feels way more responsive and fast, if a little ugly.
If there was an option to use the modern CSS with the old technology that would be the sweet spot for me.
It hobbles `git status` and essentially forces you to keep track of what you've changed yourself (since ignored files won't show up there), and it can instill a false sense of security that `git add .` is safe when it might not be.
reply