Too many methods?

I’ve got a question with regards to the number of methods there are in a project. Let’s say that I’ve got a button whose Action event runs three related, but otherwise independent processes. The event code lists the code for the first process, followed by the second process, and then the third process.

Should these three processes be put into their own methods that are sequentially called from the event Action? If these processes are moved into their own methods, does an overabundance of methods in a project slow down the performance of the application?

Thanks in advance for your feedback! :slight_smile:

[quote=159710:@Michael Nagel]I’ve got a question with regards to the number of methods there are in a project. Let’s say that I’ve got a button whose Action event runs three related, but otherwise independent processes. The event code lists the code for the first process, followed by the second process, and then the third process.

Should these three processes be put into their own methods that are sequentially called from the event Action? If these processes are moved into their own methods, does an overabundance of methods in a project slow down the performance of the application?

Thanks in advance for your feedback! :-)[/quote]

my opinion?
Yes… make methods of each of the 3 processes… this way the code is self contained, easier to maintain, and can be reused by other actions or events later if necessary

Does an over-abundance of methods affect performance? No… but all the more reason to encapsulate and reuse code within the app as much as possible.

Readability -> Maintainablity -> Performance

The method use question sounds like a negligible performance difference too me.

If you have a more maintainable project, you will find it easier to optimize your code. As Dave said, make your project easier to manage. Worry about optimizing your code once you get it to work.

My two cents: I prefer lots of little methods rather than a few large methods. Smaller methods are easier to debug and get error reports back. Smaller generally means that they’re easier to understand.

For example, finding the cause of a nil object exception in a 10 line method is way easier than a nil object exception in 100 line method.

Anyway, my other thought is that if any of these processes use common variables/properties/methods you might want to put them into a class. That way they you run an instance of the class which contains all the variables and if another process (kicked off by another event or possibly another user in web apps) happens to run you’re not colliding with variables being written over at inopportune time. Leads to some strange results and users that swear at you vehemently.

Thanks for the feedback! :slight_smile: