I'm a first year computer science student. We are currently programming in java and I often try decompose my program into well named methods so that my main method logic can read as close to pseudo-code as possible.
The problem I find is that often I'm ending up writing so many small private methods that I feel I might be overdoing it. Are there any good rules of thumb or stylistic considerations to take into account when deciding whether to decompose a problem even further?
My philosophy is to break up code into atomic, logical single units of work. Something I can usually give a name to - and then I put that work into a method and give it that name.
I think most important part of breaking up code is Single Responsibility Principle (SRP). Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class
The rule of thumb is the Single Responsibility Principle. Every unit of code should be responsible for exactly one thing. That applies to methods as well as classes. If you can put a simple, concise name to what each of your many private methods are for, then it's fine. If you can only describe it as "part of" a larger operation, then it probably shouldn't be a separate method.
But from your question, it sounds like you're doing it right already.
Most new developers go the other way - huge functions that have many responsibilities. Your situation is infinitely preferable to this!
There's very little downside to creating lots of small methods, and lots of upside!
Short methods are:
Considering this, I would suggest that you mercilessly refactor duplication into small methods. Your IDE will give you an extract method refactoring to make this faster.
I also think your aim of aspring to a sort of readable pseudo code is, in general, a good one. A lot of the code you see won't be written like this, but it can really aid readability and the notion that 'code is documentation.'
Some people will talk about performance overhead of method calls, but only in very rare cases would that be a concern to you.
Edit - Other posters have mentioned Single Responsibility Principle. Though this is a good guideline, I personally think it goes further than this. Even some code fragment that has one well defined responsibility could potentially be decomposed for reuse and readability.
My general rule is that if a function doesn't fit on a single screen (think an old 24 line by 80 column terminal), there better be a good reason. Sometimes there is. You have to keep in mind that in general, anyone reading your function has to understand the entire thing. When it is long, that is harder to do.
That being said, two or three line functions don't add much. They are often TOO easy to understand on their own, and the name you give them won't convey as much information as the code itself when embedded in some longer function.
There are always exceptions. There isn't any RIGHT way. Your work will improve with experience.