Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Is there a good practice to split part of complex method’s functionality to several smaller methods only in terms of good code readability (but maybe paying some performance for methods calling)? Or this is some kind of “bad style”?
The very basic rule is that your method should do only one thing. If you detect that is doing many different things, then you have a clear refactoring oportunity.
If you reach the point where your method has a single responsability but the size is too long anyway, try to extract “helper” functionality to separated methods. You might even detect code that can be promoted to separated classes.
TDD development is a great methodology to avoid this kind of issues since it really helps to clearly separate concerns and to avoid a bunch of code on single methods just for the sake of testability. If you don’t write concise methods, it becames too hard to test them properly.