hn also struggles with this.
a few days ago: an open source implementation of k (!) was mainly discussed in terms of coding style and “readability”
Goodbye, Clean Code
411–420 of 599 posts
Re: Goodbye, Clean Code
#412Earlier quoted context omitted.
Future coding has lead to some of the most overcomplicated systems I've worked with. It's one of the reasons (among many) I quit my last job. I was constantly told code that had no use cases was "important to have" because "we needed it".
So does that same idea apply to all of the many abstractions thst geeks do just to stay vendor or cloud agnostic just in case one day AWS/Azure go out of business?
Yes. There's no point abstracting over a vendor API if you're not actually using an alternative implementation (even for testing). Otherwise, keep your code simple, and pull out an abstraction if and when you actually have a use case for doing so.
Re: Goodbye, Clean Code
#413[deleted]
Re: Goodbye, Clean Code
#414Someone once taught me a phrase I often use "Lowest common denominator coding." What it means is that you should code to the most common abilities held by the group of coders you are working with.
In practice what that means is when you are writing a piece of code you should do so in a way that the new hire fresh out of university with less that a years real world experience should be able grasp what you are doing fairly quickly.
Abstractions, using the latest and greatest additions to the language you are using and obsessing over reducing the code line count can help the code run faster, but it also increases the learning curve for people looking at the code for the first time.
Re: Goodbye, Clean Code
#415Earlier 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,…
> 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.
The whole point of programming is to abstract away repetitive work. Yes, a human will spot that the pattern is the same, but this is both fallible and a waste of human effort. And even if you can see the difference, those extra characters are still filling up your lines and making it hard to keep functions on a single screen where you can comprehend them more easily.
> 2. 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 only thing the language defines about errors is that they have a method called Error that returns a string. That's it. This means that you can create complex error handlers if you need it, entirely within the standard language. This is extremely powerful.
There's nothing magic about something like https://fsharpforfunandprofit.com/rop/ either. Just plain old functions and values written in the language (that talk literally gives the definitions of all the types and functions it uses, written in plain old F# code). You need functions as values, but everyone agrees that's a good idea anyway, and you need proper sum types, but you need those anyway if you're ever going to be able to model a domain properly.
Re: Goodbye, Clean Code
#416I'm 52 many would consider my code a mess. Been a professional coder -> solution architect all my life, I work for me now with my own apps. With my own code I clean things up when I can, but sometimes it isn't worth it. I used to write clean code, spend time doing it but no more. - Rewriting requires retest, introduces new bugs. - If it ain't broke, don't fix it. - Users don't care about clean code. They only care ab…
> - If your code requires constant maintenance you are doing it wrong.
Disagree. Your code should reflect the business you're in, and changes to the business are what creates opportunity and let you turn your skills into profit.
Clean code is absolutely a means to an end, and if you've got a codebase that's just sitting there fulfilling some static business purpose then yes, it makes sense to leave it ugly. (Similarly with code that you know is being end-of-lifed soon - if there is not going to be a need to make changes to the code in the future then it's fine to load it up with technical debt until it sinks). But that's the exception rather than the rule.
Re: Goodbye, Clean Code
#417The original code was clean.
The thing about the handling of different shapes is that they have idiosyncrasies. Resizing one side of a square resizes all of its sides; resizing one side of a rectangle resizes two out of four sides; resizing one side of an arbitrary quadrilateral only resizes the one.
These are very different abstractions, with different behaviors. Even though all shape functions technically use the same code, they're not conceptually doing the same thing. Linking these abstractions by way of a shared extracted functions is inviting bugs.
Re: Goodbye, Clean Code
#418I’ve usually heard this phenomenon called “incidental duplication,” and it’s something I find myself teaching junior engineers about quite often. There are a lot of situations where 3-5 lines of many methods follow basically the same pattern, and it can be aggravating to look at. “Don’t repeat yourself!” Right? So you try to extract that boilerplate into a method, and it’s fine until the very next change. Then you ne…
The best way I’ve had this explained is that refactoring != DRY. Some methods have a similar structure, but if the problem they’re solving isn’t fundamentally similar then it’s not truly refactoring and you’re setting yourself up for more work in the future.
Re: Goodbye, Clean Code
#419Earlier quoted context omitted.
That can be boiled down to the “Rule of 3”. My CTO often asks me to implement a feature to do X and make it “generic enough to handle future use cases”. My answer is always the same - either give me at least three use cases now or I am going to make it work with this one use case. If we have another client that needs the feature in the future then we will revisit it. Of course, there are some features that we know in…
From (I think) an old Joshua Bloch talk on API design, paraphrased: * If you generalise based on one example, you will get a flexible API that can handle only that example. * If you generalise based on two examples, you will get a flexible API that can switch between those two examples. * If you generalise based on three examples, you have a chance of abstracting over the common essence.
Yes, he mentions it in Effective Java. When designing APIs, collaborate with 3 clients if possible.
Re: Goodbye, Clean Code
#420Earlier quoted context omitted.
That can be boiled down to the “Rule of 3”. My CTO often asks me to implement a feature to do X and make it “generic enough to handle future use cases”. My answer is always the same - either give me at least three use cases now or I am going to make it work with this one use case. If we have another client that needs the feature in the future then we will revisit it. Of course, there are some features that we know in…
The Rule of 3 is a great rule, except when it isn't. I had a colleague some time ago who wrote a couple of data importers for FAA airspace boundaries. There were two data feeds we cared about, "class airspace" and "special use airspace". These airspace feeds have nearly identical formats, with altitudes, detailed boundary definitions, and such. There are a few minor differences between the two, for example different…
Are you sure merging code for different datafeeds would be better though? In such cases, what is identical and what is not, should be references to eachother in comments. But you don't know beforehand which approach would be better, unless you know the datafeeds will stay the same as now.
The sad story here is that if you know the datafeeds will stay pretty static, there's little to gain making an advanced abstraction over them. Which is why you often find duplicated code that haven't been touched for years.. The original target was met with a naive approach, and no new changes lead to stale codebases.