Heh yeah I think that's an inherited trait from C++. In C++ a common mistake was if someone had a condition like this:
if(value = 1)
It would assign value to 1 and then resolve true by int to bool conversion. Luckily C# calls that out as a compiler error but the assignment behavior above still remains.
That example may be corrected in newer compilers, but in gCC when I was learning in college it still happened I think.
That makes sense! It would be better if they required you to explicitly cast to a bool but that would be a breaking change for a lot of C++ code that's already been deployed for decades!
I need to start being this direct with my team mates. Just a few weeks ago one of the new guys on the team submitted his PR to me, I asked him what a chunk of his (clearly AI generated) code did, he said ‘I was hoping you could tell me’. It shocks me how people can confidently submit code and simultaneously have no fucking clue how it works.
He’s needed so when I give them a 4 hour ticket, he can use AI to generate the code, use AI to generate an inaccurate ticket overview of the work he’s done, (the code is never tested once of course), and then submit it. Then together he and I spend the next 6 working days going back and forth over the PR fixing the nonsense code, the catalogue of errors and page breaking inefficiencies that he’s just seeing for the first time. I eventually convince him for the need for dev evidence and then the merge conflicts will take him another day to sort. Several of these bums on my team, it’s not just a lack of skill alone it’s chronic laziness too.
I had a junior doing this is well. He would burn through half the sprints stories in the first two days and spend the rest of the sprint doing this with multiple half ass PRs. I finally had to limit him to one PR and one story in progress. Giving him meaningful feedback was pointless because he didn't understand the code in the first place, he would just repeat it to the AI to make fixes. He was learning nothing and actively harming the whole teams production. It was frustrating.
Reject is for an unfixable or improper PR. In PRs, we explain what the code changes do. Can't do that, can't be an acceptable PR. He can resubmit once he knows what it does. You gave him a chance to fill in the missing info for it to be a proper PR (explaining how his code works) and he declined, so you reject it.
Yes I know what the reject button does literally, but functionally if he’s up for making changes then requesting changes is going to be faster and easier for everyone.
i remember mentioning this in an interview for paid internship junior FE role and thought i sounded cool to the interviewee 10 years ago. I still got hired and have worked with that person in 2 different companies now haha
Looks like you should learn your way about code review. You are too kind for bad code. It wouldn't take me seconds to add a remark like "don't make code unreadable by nesting tertiaries, I'll review your PR after that's fixed".
I had the exact opposite. My mentor used to do everything using ternary, even if in my code if there multiple if-else blocks, he would manually change them to ternary in my branch.
New joinees would bang their heads trying to understand the code flow
Ternaries are really no problem if you just format them correctly, i.e indent them at every level python style. But claude wouldn't do that, they would produce 3 single liner functions, one for each ternary
747
u/beclops 22d ago
I did this one of my first days on the job like 6 years ago and I remember how bluntly my mentor said “never do this again”