CODEWITHSUNDEEP
c#.netperformancemethodsbreak
PRAKASH CHANDRA GUPTA
PRAKASH CHANDRA GUPTA

Reputation: 67

Is it better to break non repetitive code in multiple methods?

Eg: When we are generating a report we know that the particular block of code is not going to be used in future in any other place, but it is having hundreds of line. Suppose if we break that code in 10 small methods and now when we are exporting report for 1000 items then, Is it good to call 10 methods 1000 times or just keep simple it without breaking into methods.

Upvotes: 0

Views: 119

Answers (3)

bokan
bokan

Reputation: 3692

If you could write it like that :

GenerateReport(){
   var myReport = new ReportHelper();
   myReport.addPieChart(getSalesByCategories());
   myReport.addTable(getTopProducts(10));
   ...
   return myReport;
}

Go for it.

Create a helper class that will make your life easier (or find one). Methods of this helper class could be addTable(), addPieChart(), which all takes objects. Use simple functions, make sure their name is self explanatory (as always) and write them in order of execution, your code will be more readable. The main function will contain calls to all subfunctions, put it at the beginning, it will be a good entry point for future developer to understand the whole process later. It makes it easier to jump to the right place to change something. You can also write tests for each small functions whereas you can't for big mammoth method. It is worth writing an helper class to ease the report generation so they all looks like this.

Real life : We are talking of a report generator here. It is kind of separate part of code in the application, it does not interact with other part of code. I guess there is no test planned (which is bad). Each function may need data from previous steps and be very intricate. Writing it in one flow may be easier. It will avoid juggling with global vars, passing dozen of parameters... But make sure you put comments every 10-20 lines, like you will do with above functions declarations. I'll recommend to also add a description of the process at the beginning (it will look like the main function of the other case). The problem here is that future maintainer could change code and not reflect changes to the main process explanation whereas he will be forced to do it with small functions.

For me it will depends on language used, I do prefer small functions (theory), but I often write spaghetti code (reality). I create functions when I need to reuse a part of code. It also depend on language used. I don't like having to write 'this.' in front of all vars to refer to a global var.

Regarding performance, each function call takes a little time, but it makes no difference for this case.

Upvotes: 0

rverdelli
rverdelli

Reputation: 48

Always keep maintainability in mind. I cases like this I like to split the Main method in sub-steps and have the main method look like:

MainMethod(){
   step1();
   step2();
   step3();
   ...
}

This way you can take a look at it and get at a glance what it is doing at high level. In case of need you can then step through the steps and get the execution details. The same approach could be applied to the steps: you can divide them in sub-steps and get the same results, giving the reader a high level overview of the step and letting him step through for the details if needed.

The ideal situation for this approach is when the interaction between steps is limited because you don't have to worry about passing data between steps.

Upvotes: 0

Pratap Bhaskar
Pratap Bhaskar

Reputation: 408

Any method which has 100 lines of code is bad for maintainability and complexity. My recommendation would be to keep each function to be a maximum of 20 lines.

Upvotes: 1

Related Questions