Timeline for Is the fluent interface pattern suitable in casual scenarios?
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 12, 2022 at 21:22 | comment | added | candied_orange | Again, never advocated giving anyone veto powers. And I've dealt with reviewers who couldn't stand dealing with concepts as simple as assignments that returned a value (code I wrote was identical to code in the language standard!). I've felt this pain. But understand, the reason we program in source code at all is for the maintenance programmer who comes after us. If you ignore that and just code to make the CPU happy then you get code like this. | |
| Sep 12, 2022 at 20:04 | comment | added | Doc Brown | @Steve: a writer who isn't able to accept some critics and try to listen to people saying "hey, can you do this in a more common and less astonishing fashion" may be technically competent, but socially incompentent (same can be said about a reviewer who insists on "their" style). This is not about "black and white", this is about finding a compromise in a team. | |
| Sep 12, 2022 at 19:56 | comment | added | Steve | @DocBrown, if readability counts so highly, then you are effectively saying that the results in this case must be incompetent. I still think the only good standard for overriding the writer on code that is already fully implemented, and where they decline advice, is one that would involve grave judgment upon the code - "completely unreasonable", "incompetent execution", "unworkmanlike results", "derelict of sense", "unfathomable". If the manager is not even tempted to talk in those terms - and there's no flavour of that from the OP - then I would return the matter to the control of the writer. | |
| Sep 12, 2022 at 13:11 | comment | added | Ewan | Obviously its hard to judge the readableness of your own code. However all work is a compromise between competing demands. Letting people veto for style reasons doesn't result in readableness, They can just pick up on single instances they don't like without having to work out a solution that works holistically. | |
| Sep 12, 2022 at 8:05 | comment | added | Doc Brown | ... with the only valid criteria for declining a PR is "the results are so bad that no reasonable programmer would have produced them in the circumstances", a code base will quickly start to get a little bit less readable with each merge, which over time will turn the whole thing into an unreadable mess. The road to hell is paved with good intentions. | |
| Sep 12, 2022 at 5:49 | comment | added | Doc Brown | "decisions of the writer(s) should be accorded respect." - The writer may not be even be here in the company next year, so if a reviewer has trouble with their style, reviewer and writer should find a compomise. I don't want writers in my team who stubbornly insist on "my code - my decision". | |
| Sep 11, 2022 at 17:45 | comment | added | Steve | @candied_orange, I agree that if you've got several objective people saying the code is unfathomable, then there must be some problem. But the OP has one guy saying only that the code could have been simpler, not two guys saying they can't grasp it. I fully agree with your thesis that code should be readable - the questions are "what standard" and "who decides", and I don't think any one reader should be capable of vetoing code just because they have an idea that it could be simpler. That would be an extreme burden for writers. | |
| Sep 11, 2022 at 14:27 | comment | added | candied_orange | Just to clarify, I'm not claiming Bob (one reader) should have veto power. I'm saying Alice (the writer) gets no vote. That's why her only hope is what Charlee (another reader) thinks. If that doesn't solve it then flip a coin and get back to work. | |
| Sep 11, 2022 at 10:02 | history | answered | Steve | CC BY-SA 4.0 |