7 ms·
But the expense of extra lines of coke come at significant maintenance costs. It means needing more test and the inevitable bugs that will be discovered. More
by bluejekyll 11y ago
But the expense of extra lines of coke come at significant maintenance costs. It means needing more test and the inevitable bugs that will be discovered.
More lines of code is inherently a bad thing, while I'm all for simplifying the code so that people can understand it, I'm not a fan of doing that at the cost of increasing the amount of maintenance that will be needed on the code base overtime.
- actsasbuffoon 11y ago> But the expense of extra lines of coke come at significant maintenance costs. That is the single greatest typo I have ever read.
- notNow 11y agoCode is coke at least this is true for some hardcore people here.
- FilterSweep 11y agoAnd its wonderful to see. I'm humbled a̶l̶m̶o̶s̶t̶ every time I read HN.
- to3m 11y agoAlso in the running, this priceless slip: https://news.ycombinator.com/item?id=3726842 https://news.ycombinator.com/item?id=3726842
- z92 11y agoLooks like that one was later corrected. Wondering what the mistake was originally.
- pbnjay 11y agoIf you need more tests to cover the "extra lines of code" resulting from the explicit nature if Go code, then your prior tests didn't sufficiently cover all the edge cases. So Go's verbosity is a win.
- PuerkitoBio 11y ago> But the expense of extra lines of co[d]e come at significant maintenance costs. All lines are not created equal. if err != nil { return err } Those 3 lines have very, very little maintenance cost. The obvious must also be mentioned: less lines of code usually mean building on abstractions - the lines of code are in there, somewhere, but not in your code. Better hope that abstraction is well-tested. Of course it's all a matter of balance, but I disagree with "more lines of code is inherently a bad thing", which stated another way, would mean "cram as much information as possible in a single line of code". In the end, lines of code are a bad metric of software.
- saurik 11y agoLess than other lines, but I definitely would disagree with the doubled-up "very" on "little". In addition to simply being distracting and verbose, a core issue is that you have to make certain you always have the boilerplate and that you have to make certain it is always correct. Otherwise you just https://gotofail.com/ https://gotofail.com/ :(.
- jacques_chester 11y ago> Those 3 lines have very, very little maintenance cost. These three lines are everywhere, give me no clear indication of whether they are intentional behaviour or merely a boilerplate-by-convention, and worst of all, they obscure the actual business logic.
- PuerkitoBio 11y agoError handling does not obscure the business logic, it is very much part of the business logic.
- jacques_chester 11y agoIf your business is handling full disks and HTTP timeouts, sure, exceptions and business logic are the same.
- bkeroack 11y agoGo is a little more verbose in basically two ways: it forces you to handle error states explicitly, and it doesn't let you do overly-clever things to save a few lines of typing. Neither of which increase the maintenance or testing burden.
- jacques_chester 11y ago> it forces you to handle error states explicitly, Does it? `if err != nil` is a convention. It's not a checked error. It's like saying "C has explicit array bounds checking", if the convention was to check it by hand. For all the hate Java gets, when I have a checked exception, I know what it is going to be. I don't need to dig around in sourcecode trying to work out if I should care or not. I don't need to check which of the three Golang error-distinction idioms (package-variable errors, error subtypes, plain-old-errors-with-magical-strings) is in play. As you can guess, I don't like Go.
- sagichmal 11y ago> `if err != nil` is a convention. It's not a checked error. It's... obviously both.
- jacques_chester 11y agoSorry, typo. "Checked exception", meaning that the compiler enforces error handling and that you can look a method signature and learn what kind of exceptions the method can throw without needing to read its internals.
- fooster 11y agoAnd runtime exceptions? What about them?
- jacques_chester 11y agoThey leave you in about the same position as a programmer in a dynamic language. The advantage of runtime exceptions over Go is that I will get a fatal crash and a stacktrace. I don't have computation proceeding in an undefined, difficult-to-debug way because I forgot to do `err != nil` somewhere (particularly for functions that only return err).
- clamprecht 11y ago> But the expense of extra lines of coke Please tell me that was autocorrect and not muscle memory
- erkose 11y agoYikes! Understanding the code is the key to efficient maintenance.