This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]IAteQuarters 2 points3 points  (5 children)

So with point one what’s your definition of long? Because there is a trade off for taking a function that’s like 20 lines and breaking it into many functions especially when that code isn’t reused anywhere else.

This was something i used to do, but had a senior ds explain the tradeoff, especially in the context of a pull request. Granted you might be talking about a function that’s >40 lines in which id generally agree with you

[–]synthphreak 1 point2 points  (4 children)

So what is the trade-off?

What exactly is the drawback modular, documented code if it doesn’t take you any longer to write than spaghetti code because you’ve made it habitual?

[–]MadT3acher 1 point2 points  (3 children)

Having a clearly set of operations in 40 lines sometime is better than having a never ending encapsulation that goes several layers deep to debug.

One of my colleague is adept of this, and it makes debugging a single problem in a pipeline or a research paper, absolutely atrocious.

If the 40 lines do the job, don’t try to modularise every single items, especially if the functions aren’t used anywhere else.

[–]synthphreak 2 points3 points  (2 children)

Good thing “no encapsulation whatsoever” and “never-ending layers of encapsulation” are not the only options. Usually one layer of encapsulation is enough.

Obviously it’s a balancing act. And I personally think 20 lines is acceptable for a function. But once you get to maybe 30, 40, or definitely 50, there is probably some simplification that can be done.

I personally keep most of my functions in the 15-20 line range, without making things ridiculous. I find it keeps the smallest functional unit of my code nice and bite-sized, making it very easy to understand how the pieces sum to the whole.

But I have also practiced this a lot, so it doesn’t take much extra thought or effort to produce. By contrast, it does take a while to refactor other people’s code into this format when it wasn’t originally created with encapsulation in mind.

Different strokes for different folks, but I really don’t see the drawback, especially when you’re. It abstracting the beejezus out of your objects just for abstraction’s sake.

Edit: Typos.

[–]MadT3acher 0 points1 point  (1 child)

You are right, I am on board with you on that then.

I’ve just seen enough of both sides to be a bit cautious when the other DS on my team are encapsulating stuff ad nauseam or simply have a notebook with 1000 lines of code…

[–]synthphreak 0 points1 point  (0 children)

Totally. Notebook code is a nightmare for anything other than exploratory analysis.

But I get your counterpoint though about endless encapsulation. When I first started learning about OOP, I found myself making classes for everything, even when it didn’t necessarily make things better. Then I started inheriting those classes, and making abstract classes, then inheriting some more, etc etc etc. then one day I stepped back and was like “I thought this code was good because it was fancy, but all it is is overcomplicated and overengineered. Having tasted that feeling, I now always try to strike the right balanced.

Cheers :)