general programming issues

think about three problems A, B, and C.

A uses x,y methods to be solved;

B uses x,z and

C uses x,y,z.

which one would be better and which one could give better performance, and which one could be more readable:

1. "writing three different methods"

2. "writing one method and taking one or two parameter and deciding which part will run in if开发者_运维问答 statement"

And please explain why.

You need to make a tradeoff between performance and modularity here.

Performance - When you make three methods probably there is a higher overhead of saving the current function on the stack and allocating a new function frame and making a call etc. But with every day our machines & memories are getting faster and larger, and the very fact that you've choosen to write code on .NET framework itself says something in itself. Performance for this kind of trivial decision is not really a big deal, so I'd prefer to make it modular.

Modularity - A method exactly does one thing, and can be easily understood by other programmers without actually having to understand how you think, is a better code in the long run. Imagine the cost of bugs, fixes, testing, time it takes to understand your code over and over by different developers at different points in time in future. If you have a method/function which is very modular, which can be tested in isolation also has a higher chance of reusability compared to a complex function, as other developers feel confident if they understand your API/code or both.

This is a personal opinion and I'd lean towards lower cost of maintanance in long term, higher reusability, testability over performance.

I would break apart the feature you are implementing with x, y, z and make as many methods. This follows the simple simple rule: Every method does one job nothing more nothing less. You can then compose these methods to achieve whatever features are wanted for A, B, C.

Fastest would be to write a function for A,B,C but it would probably eat more ram. Every method call means a jump in the machine code and so costs processor time. The difference is too small to be worth the higher maintenance. Thats why you make more functions.

It's better in every way to write separate methods.

If you use some kind of conditional structure, your programme will definitely have to go through that structure at run time.

By contrast, using the methods, a sufficiently optimising compiler (I'm not familiar with the F# compiler, and whether it does this) can expand out the method text, saving on creating new stack frames. Even if your compiler isn't that optimising, creating a new stack frame is relatively cheap.

Edit: As Cody Gray says, larger programme text may reduce performance, as it may increase processor cache misses.

I would favour the "three methods" approach. In the interest of managing complexity, one should exploit any opportunity to eliminate conditionals and branching in code.

Consider that as the code base evolves I might want to perform some refactoring that requires me to identify the uses of z. In the "three method" case, this is trivial as I simply look for all z call sites -- something most modern IDEs and cross-reference tools will do for me. In the "one method" case, the analysis is more complex. Not only do I have to identify all call sites, but I then need to do a flow analysis to determine the values of the parameters that trigger the different behaviours. If those parameters are constants, this may not be too burdensome. But if they are calculated then it could be a lot of work, especially if they are calculated somewhere up the call chain.

If, and only if, application profiling revealed that the three methods were a significant performance bottleneck would I consider merging the three methods into one as an optimization.