3 ms·

Push everything down for better code readability printInvoice(invoice, options) // is much better than if(printerReady){ if(printerHasInk){ if(p

by Kuyawa 1y ago

Push everything down for better code readability printInvoice(invoice, options) // is much better than if(printerReady){ if(printerHasInk){ if(printerHasPaper){ if(invoiceFormatIsPortrait){ : The same can be said of loops printInvoices(invoices) // much better than for(invoice of invoices){ printInvoice(invoice) } At the end, while code readability is extremely important, encapsulation is much more important, so mix both accordingly.

lblume 1y ago
> printInvoice(invoice, options) The function printInvoice should print an invoice. What happens if an invoice cannot be printed due to one of the named conditionals being false? You might throw an exception, or return a sentinel or error type. What do to in that case is not immediately clear. Especially in languages where exceptions are somewhat frowned upon for general purpose code flow, and monadic errors are not common (say Java or C++), it might be a better option to structure the code similar to the second style. (Except for the portrait format of course, which should be handled by the invoice printer unless it represents some error.) > while code readability is extremely important, encapsulation is much more important Encapsulation seems to primarily be a tool for long-term code readability, the ability to refactor and change code locally, and to reason about global behavior by only concerning oneself with local objects. To compare the two metrics and consider one more important appears to me as a form of category error.
inetknght 1y ago
> Push everything down for better code readability > demonstrates arrow anti-pattern Ewwww gross. No. Do this instead: if(!printerReady){ return; } if(!printerHasInk){ return; } if(!printerHasPaper){ return; } if(!invoiceFormatIsPortrait){ return; } Way more readable than an expanding arrow. > printInvoices(invoices) // much better than But yes, put the loop into its own function with all of the other assumptions already taken care of? This is good.
theonething 1y ago
> printInvoice(invoice, options) // is much better than > ... in Elixirland, we'd name that function maybe_print_invoice which I like much better.
coolcase 1y ago
Everyone has different opinions as this might be the printer driver on the PC or the printers internal circuit. The printer itself absolutely shouldn't try to spook the wheels when there is no paper. Id stick that check in the function!

by Kuyawa 1y ago

lblume 1y ago

> printInvoice(invoice, options) The function printInvoice should print an invoice. What happens if an invoice cannot be printed due to one of the named conditionals being false? You might throw an exception, or return a sentinel or error type. What do to in that case is not immediately clear. Especially in languages where exceptions are somewhat frowned upon for general purpose code flow, and monadic errors are not common (say Java or C++), it might be a better option to structure the code similar to the second style. (Except for the portrait format of course, which should be handled by the invoice printer unless it represents some error.) > while code readability is extremely important, encapsulation is much more important Encapsulation seems to primarily be a tool for long-term code readability, the ability to refactor and change code locally, and to reason about global behavior by only concerning oneself with local objects. To compare the two metrics and consider one more important appears to me as a form of category error.

inetknght 1y ago

> Push everything down for better code readability > demonstrates arrow anti-pattern Ewwww gross. No. Do this instead: if(!printerReady){ return; } if(!printerHasInk){ return; } if(!printerHasPaper){ return; } if(!invoiceFormatIsPortrait){ return; } Way more readable than an expanding arrow. > printInvoices(invoices) // much better than But yes, put the loop into its own function with all of the other assumptions already taken care of? This is good.

theonething 1y ago

> printInvoice(invoice, options) // is much better than > ... in Elixirland, we'd name that function maybe_print_invoice which I like much better.

coolcase 1y ago

Everyone has different opinions as this might be the printer driver on the PC or the printers internal circuit. The printer itself absolutely shouldn't try to spook the wheels when there is no paper. Id stick that check in the function!