Object-oriented – When should I create separate function (or class)

Architecturedesigndesign-patternsobject-oriented

I do programs for several years.
And now I know from my colleagues my pros and cons:
Pros: I can solve very complex problem
cons: I make overcomplicated solutions for simple tasks.

Now I'm trying to fix my cons and looking for generic principles and guidelines for this question:

When should I create an additional piece of code (a function, a class, a module, whatever). And when I should not.

I've seen an answer from some Python guy: whenever you can, don't create, make it as simple as possible.

Well this is a great advice, but having one big function isn't a good idea too.

The problem for me is that I have a principle when to create a separate function for sure, but I don't have an opposite one (when not create). The principle is:

Create a function when you'll have to copy-paste some code and as a result you'll have duplicated code.

(Why: duplicated code is bad, because you'll forget to fix some of copies when you fix a bug in it, you'll have to create times as many tests as you copy, and the is times more letters to read for your team and yourself later, etc…)
This can sound as an example of what kind of answers I'm looking for.

So, how do you decide whenever to create a separate function or just extend an existing one?

Thanks everyone who already answered this question, but please add at least some principles when you should not split function (when you should better keep it as a whole).

Because for now most (all?) the answers here are about only when you should split. And my problem is that I make too many functions, I split too often, as coders tell me, – and this is why my question differs from this one Should I extract specific functionality into a function and why? .

Best Answer

Seems like a pretty broad question, but I'll happily share my "wisdom" FWIW

  1. Portions of code that could be extracted to pure functions (output determined solely by inputs) should be extracted to pure functions. For example, if halfway through your function you discover that you need a string to be formatted a certain way, you can extract the string formatting logic to a string library. Even if you only use the function once, this will render the code more readable and reduce the complexity of your main function.

  2. If your function's name is ridiculous, maybe it needs to be split up, e.g. OpenFileParseContentsAndCreateObjects seems like it might be better off separated into three functions.

  3. If the function cannot be read and understood by an average developer within 1 minute, it probably could benefit from simplification or being broken into smaller bits.

  4. If the function requires ~20 or more unit tests in order to exercise 100% of the logic paths, it should be broken up.

  5. If the function is taller than a single viewable page in the IDE, unless there is a compelling reason, it should be considered for restructuring.

Related Topic