There is one issue that I haven’t seen mentioned: testing.
The real problem with duplicated code in my opinion is that it either remains untested or bloats your test suite. And a bloated test suite can slow you down to a crawl.
Goodbye, Clean Code
391–400 of 599 posts
Re: Goodbye, Clean Code
#392Earlier 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,…
> The point of Go's error handling is that it isn't magic. There's nothing special about error values, and they are handled exactly the same way as every other variable in the system The error maybe, but not the result of the call . The multiple-value return x, err is not a first-class value. It cannot be handled like any other variable. This was demonstrated very clearly with proposal for try. try would have automat…
Sorry, I don't understand what you're saying. Are you saying that because there's a proposal in v2 for error values to not be 1st class values, therefore they're not in v1?
Re: Goodbye, Clean Code
#393Earlier quoted context omitted.
The guiding principle... a rule, so to speak!
Everything in moderation, even moderation itself.
> Everything in moderation, even moderation itself.
This was my guiding principle in life, and I thought I was pretty clever for coming up with it, but later found out that someone far more clever got a lock on the phrase in history: https://www.goodreads.com/quotes/22688-everything-in-moderat...
Re: Goodbye, Clean Code
#394Code 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 piece of code doing some very complex stuff. It took a lot of effort to understand. Nowadays I am extremely happy when I take a complex problem and solve it only by writing very simple code that even the most junior dev we would hire can easily understand.
The downside I can see is that in some orgs more respect is given if you write black box code making you unfireable but that's a good sign you don't want to work there/need to make the culture evolve.
Re: Goodbye, Clean Code
#395Earlier 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.
I kinda prefer this to the Rust apologetics, where every post about Go is replied to with three posts about how Rust does it so much better ;)
I've used lots of other languages, as have a lot of other Gophers. I'm not saying "Go's approach is good" out of some strange tribalism or a need to assert my preference. I'm saying this because, having spent over 35 years programming, I really appreciate the simplicity of Go and the lack of magic. I'm not apologising for Go's simplicity, I'm trying to explain why I like it.
Re: Goodbye, Clean Code
#396Yet React state management remains an academic exercise.
Re: Goodbye, Clean Code
#397Earlier quoted context omitted.
I am such a huge fan of Big 'Ol Switch Statements over using polymorphism/types/generics/whatever. So easy to understand, and it's all there in a huge scrolling list of cases. If something needs to change, it's easy to change it, and you know what else is affected.
That works until you have 20 different Big Ol' Switch Statements, each switching on (mostly) the same cases, essentially implementing a set of related behaviors in 20 different places instead of grouping the 20 behaviors under the same umbrella. Overall, I think there is an equilibrium between the number of cases in the switch and the number of different switches with the mostly the same cases. The fewer cases ypu ha…
you're entirely right, of course. I just wanted to express my enthusiasm for the approach :)
Re: Goodbye, Clean Code
#398Code 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…
It's funny how one can feel ashamed for not using the esoteric language features.
Whenever someone new joins the firm, and they know all the cool operators ect., I get so nervous around them! But I've caused myself so much stress trying to do something clever, having to go back and update the behaviour, only to curse myself for trying to be clever!
Re: Goodbye, Clean Code
#399Code 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 need to apply it to 12 places and are pretty much guaranteed to mess up one of them, since this is the most boring task ever and your brain switches to lie power auto pilot after the third instance.
Re: Goodbye, Clean Code
#400Code 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…
It's funny how one can feel ashamed for not using the esoteric language features. Whenever someone new joins the firm, and they know all the cool operators ect., I get so nervous around them! But I've caused myself so much stress trying to do something clever, having to go back and update the behaviour, only to curse myself for trying to be clever!
> Whenever someone new joins the firm, and they know all the cool operators ect., I get so nervous around them! But I've caused myself so much stress trying to do something clever, having to go back and update the behaviour, only to curse myself for trying to be clever!
On the upside, this process is all about learning. It's easy to be clever, it's hard to be clever and successful. Making these mistakes and fixing them is how you turn knowledge into wisdom.