Programmer Humor

hideshow 5 child comments

[–] bort@feddit.de 36 points 2 years ago (2 children)

He also insists on refactoring any block of code longer than two lines into its own function

Thanks, uncle Bob.

hideshow 2 child comments

parent

[–] qevlarr@lemmy.world 18 points 2 years ago*

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

parent

[–] PoolloverNathan@programming.dev 5 points 2 years ago

Then refactor those two freshly-refactored lines into their own function as well for polymorphism, right?

parent

[–] SpicyLizards@reddthat.com 15 points 2 years ago

Sounds delightful. I'm sure that nothing is explained at length repeatedly in a 35 minute meeting that could have been a message

parent

[–] wizardbeard@lemmy.dbzer0.com 3 points 2 years ago

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).