Earlier quoted context omitted.
The guiding principle... a rule, so to speak!
Everything in moderation, even moderation itself.
No, no, no; it's "Everything in moderation, especially moderation.". :)
Goodbye, Clean Code
531–540 of 599 posts
Re: Goodbye, Clean Code
#532Earlier quoted context omitted.
If someone else is looking for examples too, I found those: https://www.reddit.com/r/Zig/comments/99zlc9/exceptions_or_e...
I thought all of this until I got used to Go's error handling. There's a couple aspects to this: 1. After a while, the "if err != nil {" becomes a single statement in your mind, and you only notice it if it's different (like trapping things that should error with "if err == nil {"). In other words, it only feels verbose if you're not used to it. After a while, the regular rhythm of "statement, error check, statement,…
One aspect of go error handling that still really bothers me is how easy it is to accidentally drop an error on the floor.
If you strap all the linters you can find onto your build system, you can catch the most obvious cases. But I still frequently find mishandled errors that sneak past the linters in ways that can't be solved without restricting the way devs use the language.
By making error handling something you have to deal with every time you call a function, you massively increase the number of opportunities you have for screwing it up.
I would love something like rusts ? Operator for go. You could choose to not use it when you need special handling. But it would be rare and exciting and developers would use it with care.
Re: Goodbye, Clean Code
#533Sorry for the off topic grammar question, but am I the only one who finds it confusing how people have started to use plural pronouns to refer to individual people?
Probably, I didn't even notice it in the OP, and if some other reader noticed anything, they were probably able to read on without much confusion anyway. (Did you find that one right there above confusing? I suspect not?)
Indeed. Maybe my English skills are fading with time, but my impression was that it works there because it's unclear who you're talking about. "Some other" is singular, but multiple people could have noticed that so it makes sense to use the plural there. It's kind of like how in American English they say "France _has_ won the WC", but in British English they say "France _have_ won the WC" (because a team has multiple people).
But saying "The boss fired me. They are awful." sounds no different than "The boss fired me. He are awful." or "They is awful." My auto parser is failing and I have to think it through.
Re: Goodbye, Clean Code
#534Earlier quoted context omitted.
Is that not common knowledge? I feel like this is a well-written post with a good point but it's a familiar point. You could boil part of it down to 'all's good in moderation', so don't just keep your code clean, keep it clean and easy to read, etc.
I didn’t mean to imply there’s anything novel in my post :-) someone’s gotta beat that drum once in a while.
It's a great post anyway, sorry if my tone was too critical. I enjoyed reading it, for what it's worth, just felt like expecting anything surprising or revelatory out of it wouldn't be the right approach.
Re: Goodbye, Clean Code
#535Earlier quoted context omitted.
I thought all of this until I got used to Go's error handling. There's a couple aspects to this: 1. After a while, the "if err != nil {" becomes a single statement in your mind, and you only notice it if it's different (like trapping things that should error with "if err == nil {"). In other words, it only feels verbose if you're not used to it. After a while, the regular rhythm of "statement, error check, statement,…
"It isn't magic!" mantra is often heard in Go apologetics, but every time I see it, it occurs to me that Go's definition of "magic" is somewhat akin to a 15th century peasant seeing a lightbulb. Stuff like exceptions or error types isn't magic - they have been around for a long time, they're well understood, and they have significant advantages.
Exceptions are pretty much the perfect example of (bad) magic actually; unannotated, dynamically dispatched nonlocal control flow that can execute code (ie, destructors) in completely unrelated contexts on the way past. At least 0x5F3759DF can be boxed into a function and commented in one place.
> Go's definition of "magic" is somewhat akin to a 15th century peasant seeing a lightbulb.
This is very true and well put though.
Re: Goodbye, Clean Code
#536Earlier quoted context omitted.
Except exceptions are rarely understood and used correctly by most programmers. They can simplify program structure, but at the expense of proper errorhandling and error mitigation strategies. Golang is still in the sort of niche that builds databases, queues, container-orchestration, etc., but can be built for other things given enough care for spending the extra effort simplifying the solutions.
> Except exceptions are rarely understood and used correctly by most programmers That's pretty condescending. The mechanism for exceptions has been around for more than 20 years, it is well understood by most programmers. The problem is that error handling is hard. Exceptions are an adequately sophisticated solution to that hard problem. Go's approach only encourages ignoring errors (since the compiler never enforces…
> That's pretty condescending.
Nope! Exceptions are, in fact, rarely understood and used correctly by most programmers. Including loopz. And me. And the authors of approximately every nontrivially-exception-using piece of code I've had to work with. And presumably also of the code loopz has had to work with.
The difference is that some of us have the good sense to rarely use exceptions at all.
Re: Goodbye, Clean Code
#537Code that is easier to read == better code. That's something I see most people struggling with, including myself, in particular when learning a new language. e.g. in kotlin it can be tempting to use a ton of complex operators and rely on the intricacies of let vs run vs apply .. even if the resulting code takes some thinking to understand. At the beginning of my career, the code I was the proudest of was a gigantic p…
That often depends on how familiar you are with a code base, and your personal knowledge about for example linear algebra or whatever specific thing is going on somewhere. Obviously there is no objective "right" in this matter, but always writing code that the greatest idiot can understand obviously isn't good either. Another problem with the duplication approach is that I'd you need to make some change later on, you…
Either you need to change 12 places and test those 12 (or whatever) use cases, or make one change and still test those use cases. Only with the DRY function, as the article says, it’ll wind up accumulating options and configuration to accommodate all those use cases, becoming a big hairy abstraction that’s harder to understand for any of those use cases, whereas with the duplicated functions they would all evolve separately and in isolation and remain independently simpler.
Re: Goodbye, Clean Code
#538Earlier quoted context omitted.
One of the areas where I really like "incidental duplication" is in tests. Tests can sometimes be very repetitive and identical, and it's tempting to want to refactor it in some clever way. That's almost never good. On top of the reasons laid out in parent comment, tests also function as unofficial documentation. I like having everything explicit in there, it makes them easier to read and understand.
If you try to abstract away tests, you often just end up re-implementing the same abstractions used in the actual code, and you can end up not catching unfounded assumptions that your abstraction is making in both the tests and the code. There is a scope for having test helpers / utils to make tests easier to write, but you should be minimalist with these.
The problem with abstractions in testing is - you should test it :)
Re: Goodbye, Clean Code
#539Earlier quoted context omitted.
Your supposition is that caring about the quality of your work is a problem. We should simply not continue this conversation because we fundamentally disagree. I don't get out of bed for "I don't care". This other developer has put this new business at risk of closing. Maybe you don't care, but someone somewhere does.
In a certain perspective, by quitting this conversation you too „don’t care“ about what latchkey thinks about this topic, though „someone somewhere“ (most likely their employer) definitely cares that they would tolerate the behavior your coworker displayed. You are doing what they propose, just at another perimeter of tolerance. I don’t think that you „fundamentally disagree“, but that you have different understandin…
and I'm sure there's an idiot somewhere out there that would agree with you.
meanwhile, the rest of humanity understands why we're ok with being labelled intolerant due to "intolerance of intolerance is itself intolerance".
Re: Goodbye, Clean Code
#540Earlier quoted context omitted.
Your supposition is that caring about the quality of your work is a problem. We should simply not continue this conversation because we fundamentally disagree. I don't get out of bed for "I don't care". This other developer has put this new business at risk of closing. Maybe you don't care, but someone somewhere does.
Just leave the job already. I've only seen that once in my career. One developer rewriting existing code constantly, to such an extreme degree it's unfathomable. He rewrote large amount of scripts (often overnight). Other developers would wake up the next day or continue the project next week, only to find a swath of issue reported by users and the project is gone (rewritten and moved). Did that for while, destroying…
I specifically state it was a contract and you're talking about a job.
this reminds me of Steve Yegge. He did a post on the difference between employed developers and entrepreneurs, and how they're completely different creatures.
You've allowed yourself to become a pet and you've given up the ability to care about your work for food and you think it's a moral failing in others who have not.
You're to be pitied.