622
know the features of your language
(lemmy.world)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 08 Dec 2023
622 points (96.4% liked)
Programmer Humor
32509 readers
466 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
My coworker flips his shit every time I include a ternary operator in a PR. He also insists on refactoring any block of code longer than two lines into its own function, even when it's only used once.
He is not well liked.
Thanks, uncle Bob.
His advice is great for newer programmers. They are taken literally by newer programmers, but the goal is not to force the dogma onto everyone. Maybe that should be more clear before the new people make a fool of themselves. They'll learn why or how to apply these rules once they get more experience.
I know the episode you're referring to and the important part is to realize you can use functions names/signatures to convey and structure information about your code, not just as a way to reuse code. This is often misunderstood by newer programmers, self-taught programmers. Your code should be easy to understand so it's up to us to make it well structured. Functions aren't only to avoid duplicate code
Then refactor those two freshly-refactored lines into their own function as well for polymorphism, right?
Sounds delightful. I'm sure that nothing is explained at length repeatedly in a 35 minute meeting that could have been a message
Sounds like they learned programming from heavily object oriented languages.
As far as ternary operators go, I personally find them less readable than the longer if else format, but with any reasonably modern IDE or git setup that should be just a simple pass of an auto-formatting tool to convert them to the project/team standard. No need for any team friction. That should be automatically handled before it goes to review.
I'm not in a position with a PR process or anything like that (I'm a glorified scripter in over his head where we need a dev team for internal tools) but I struggle with over reliance on functions as well.
To keep from going overboard I always try to evaluate how often the block of code will see re-use (want to eliminate copy/paste and the footgun of forgetting to update a copy somewhere), how useful it would be to maintainers to have that section abstracted away into a black box (so you only have to worry about the part of the code that's not working instead of the whole damn thing when something breaks), and how likely that block of code may need to be completely replaced later (if it's separated out into a function, it's a discrete chunk where we only have to maintain the same input and output formatting and ideally the rest of the program just werks).