I am having a discussion on code style, and it's starting to sound like a matter of taste. I strongly believe otherwise, so I'm writing this to get your opinion and learn from your arguments for and against.The issue is that of hiding complexity by replacing a bunch of lines of code with a method. This discussion is unrelated to reusable functions, and I'm trying to make the argument for simple code organization, not for factoring out common functionality.So, take this example in loose java:public void purchase(Customer customer, Set<Item> items, Warehouse warehouse){     int credit = customer.getCredit();         int orderPrice;     for(Item item: items){         orderPrice+=items.getPrice();     }     if(orderPrice + customer.getPendingPayments() > customer.getCredit()) {              warehouse.reserveStock(items);           transportCenter.allocateTransport();           customer.bill(items, orderPrice);     }}As opposed to this:public boolean isCreditOk(Customer customer, Set<Item> items){     int credit = customer.getCredit();         int orderPrice;     for(Item item: items){         orderPrice+=items.getPrice();     }     return  orderPrice + customer.getPendingPayments() > customer.getCredit();}public void purchase(Customer customer, Set<Item> items, Warehouse warehouse){     if(isCreditOk(customer, items)){           warehouse.reserveStock(items);           transportCenter.allocateTransport();           customer.bill(items, orderPrice);     }}The whole discussion now is: would you have created the isCreditOk method or would you have left if inline? When do you do one or the other? does it depend, in a general case, on:The length of the function to extractHow many sub-functions and sub-subfunctions isCreditOk will end up havingAgain, this is not done because isCreditOk will be used often, but because it makes the code easier to read (in my opinion).Can I have your comments? Thanks!Note: I have found this question to be related: Is there such a thing as having too many private functions/methods?
Hiding away complexity with sub functions
readability;encapsulation;coding style
Divide into smaller functions is the best way for sure, at least for human readability.By extracting a smaller function, you are naming a block of code. That really improves readability.Readers can have a macro idea of what that function does, without having to bother with details of each step. If you want to see the details, than you look ate the sub-function. This is the Newspaper Metaphor in Uncle Bob's Clean Code.Generally speaking, complex if statements should be extracted to their own methods. Those nasty ifs should be substituted by a meaningful name that explains what is being tested so readers don't have to parse those huge lines of code.But besides that, there is more refactoring to be done there. If I were reading the purchase ou isCreditOk methods, I wouldn't want to see that for loop calculating the total value. That's not an easy-read. I'd have to stop my eyes at that point, mentally parse that block to try to figure out what it's doing. The for loop should be extracted to another method called getOrderPrice, getTotalPrice or something like that.Better than that, the items set could be extract to it's own class: OrderItems. The class would have a method like getTotal that would return the sum of its own items. That's the Single Responsibility Principle, the OrderItems class is the one that handles its own items. In addition to that, the data structure (Set in this case) would be encapsulated and you are free to change to other data structures whenever you want (if you need to change it to a list, for example).