1. Comment as much as possible, stating intention.
2. Don't duplicate code. You need a function that does something similar to another one, but slightly differs? Do not duplicate it. Less code is less maintenance.
3. Don't circlejerk over code quality, your goal as a programmer should be to write the best software you can. The end goal is the software, not the code. Stop circlejerking in pull requests, issue threads, wherever. Make the best software you can and move on to the next problem.
I think thats' the hidden goal of modular programming.. or functional programming to an extent. Have easy variability to allow for easy adjusting to converge to an optimal solution.
Seems more like random Chinese sentences, based on Google translate anyway. Which seems inline with all the other issues posted in English. I think people are just screwing around making jokes/memes on a joke/meme repo. Take this issue in English for example: "The cow has eaten the grass and gone, so there is nothing left" - https://github.com/kelseyhightower/nocode/issues/4201
I'll sometimes spend a couple of hours on a method, removing unnecessary code.
It does NOT always end up with more performant code (sometimes, the opposite), but it does reduce the "I don't wanna remove all that code" surface, and it usually* makes the code easier to understand.
* I write Swift. Sometimes, less code is more obscure code, and I often have to go back and put code I removed back in, to make it more understandable.
I've seen both cases (people over-avoiding dependencies to detrimental levels, and people who are VERY bad, and very zealous, at selecting dependencies). While I think it varies per language community; overall, the latter seems more common.
That said, the worst codebases I've worked with were examples of the former. So it's definitely a tricky balance.
My codebases can be difficult to maintain (I know, because I'm the one that has to maintain most of them).
It's not because the code is bad. Quite the opposite, really. It's well-structured, and incredibly well-documented.
It's because I tend to do some fairly ambitious things, and write in a modular, layered fashion that can distribute functionality throughout the stack.
I also tend to write in a fairly asynchronous fashion (would you call it "reactive"? I dunno. I've been writing code like that since long before "reactive" was an official buzzword).
One of the hardest aspects about maintaining an in-house system at a small company can be refraining yourself from removing code that would decrease the company's tech debt. Most managers don't want to admit the smart code they wrote three years ago causes more problems than it solves, and it can get really awkward.
I have seen the "not too bright but durable manager" pattern at a few jobs now. They are usually the only (former) developer who has been at the company for more than 3 years, and the main reason they are your manager is that the CEO knows they are not going away any time soon.
This is a pattern that's used in other fields too, e.g. electronic music:
When Brian Eno lectured at RBMA in New York a couple of months back, he described [James] Blake as an artist who “works mostly by subtraction, he takes lots of stuff out and ends up with very skeletal pieces.”
Blake watched the Eno lecture yesterday, and he nods avidly when I repeat this analysis of his working process back to him. “One part [of a song] that doesn’t mean anything really pisses me off. Genuinely, it irritates me if there’s something that doesn’t need to be there. The thing is, it happens in other music as well; I’m not too fascist about it when it comes to other people’s music, but when it comes to mine I really try to do a spring clean on the track, to make sure that everything that needs to be there is there, and nothing extraneous is left just buzzing in the background, clattering and distracting me from the main idea."
This is actually a different thing, though. This is pruning a working piece down to a smaller one. Kind of like gardening by only weeding. It works, but only if you have a full set of crops naturally.
This idea seems more to be about planting crops in such a way that you can remove them easily from a garden.
I just want to add that "Programming Pearls" by Jon Bentley is a treasure and (although it might not seem like it) has a lot to add to this sort of consideration (the slow painful evolution of elegant programming.)
In Safari (iPadOS), I couldn’t get out of the site using the back button (unless I hit it fast enough to get past whatever it was doing to the browser history).
Interesting, it works fine on Firefox. I was able to reproduce it using Safari. After poking around I noticed it's a tumblr blog, so I tried some other tumblr blogs with the same result. It seems Tumblr's nav code does not get along with Safari/Webkit.
Thanks. That's good to know for the future, at least when I can easily identify something as a Tumblr blog. At least this wasn't one of the more egregious browser history hijacking situations. I've been on some sites that polluted the browser history as I scrolled through the page (each subheading coming into view got an entry). Two quick taps of the back button was enough to get around this one.
Not necessarily. Code that has been extended heavily is often the hardest code to delete. The extension itself becomes the "ball of mud" that was meant to be avoided.
I feel this is somewhat muddled in push. I agree with all of the items, but I don't agree with how folks often pursue it.
My specific concern is where it pushes that a big ball of mud is easy to write, but hard to maintain. I agree, but oddly, a ball of mud is also somewhat easier to delete. Such that, it is best to grow your code from that core and only grow to reusable parts if needed.
I encountered this at work recently. I fully agree that reusable and "single responsibility" is nice. However, to extract out 5 lines of code such that we now have 3 new classes and possibly a new dependency seems the opposite of the spirit here. If we ever got where that logic isn't needed, as is, you delete 5 lines of code. In the "abstracted out" world, you have to delete several classes, making sure nobody else had taken a dependency on it.
I get that counting by lines of code is not the best metric, but it is an easy one. And, in general good faith code, the lower that metric, the better. It is less to read. Less things connected together to reason about. And, less stuff that you could delete in the future if able.
The problem with removing ball of mud code is that you don't know much of that mud is entangled with useful code.
I do think oop design patterns bring a lot of indirection sometimes but atleast we can use small well thought out functions instead of connecting all things inside one giant one
That is true of all code you delete. It had some use, or it would never have been added in the first place.
I'm not arguing for the entire thing to be a ball of mud. Just pushing that there are trade-offs. And, in general, less code is better code. Even if it is a larger method.
Granted, I think a lot of this is in strawmen. Breaking 5 lines out of a 40 line method so that you can be better abstracted is usually fighting the wrong things. Breaking it out of a 500 line function is different.
31 comments
[ 2.6 ms ] story [ 81.2 ms ] thread1. Comment as much as possible, stating intention.
2. Don't duplicate code. You need a function that does something similar to another one, but slightly differs? Do not duplicate it. Less code is less maintenance.
3. Don't circlejerk over code quality, your goal as a programmer should be to write the best software you can. The end goal is the software, not the code. Stop circlejerking in pull requests, issue threads, wherever. Make the best software you can and move on to the next problem.
Comments from the repost 4 months ago: https://news.ycombinator.com/item?id=23914486
I'll sometimes spend a couple of hours on a method, removing unnecessary code.
It does NOT always end up with more performant code (sometimes, the opposite), but it does reduce the "I don't wanna remove all that code" surface, and it usually* makes the code easier to understand.
* I write Swift. Sometimes, less code is more obscure code, and I often have to go back and put code I removed back in, to make it more understandable.
I envision your comment will be taken out of context to literally justify adding mountains of code written by other people. Invented Here Syndrome
Not necessarily a bad thing, if you are good at selecting dependencies.
But it can be a very, very bad thing, if you are not so good at selecting dependencies.
That said, the worst codebases I've worked with were examples of the former. So it's definitely a tricky balance.
It's not because the code is bad. Quite the opposite, really. It's well-structured, and incredibly well-documented.
It's because I tend to do some fairly ambitious things, and write in a modular, layered fashion that can distribute functionality throughout the stack.
I also tend to write in a fairly asynchronous fashion (would you call it "reactive"? I dunno. I've been writing code like that since long before "reactive" was an official buzzword).
Can be hard to grok.
+ simplify it + reduce it + make the code more readable
When not possible, make at least more readable, like choosing the right method & variable names.
When Brian Eno lectured at RBMA in New York a couple of months back, he described [James] Blake as an artist who “works mostly by subtraction, he takes lots of stuff out and ends up with very skeletal pieces.”
Blake watched the Eno lecture yesterday, and he nods avidly when I repeat this analysis of his working process back to him. “One part [of a song] that doesn’t mean anything really pisses me off. Genuinely, it irritates me if there’s something that doesn’t need to be there. The thing is, it happens in other music as well; I’m not too fascist about it when it comes to other people’s music, but when it comes to mine I really try to do a spring clean on the track, to make sure that everything that needs to be there is there, and nothing extraneous is left just buzzing in the background, clattering and distracting me from the main idea."
https://www.dummymag.com/features/james-blake-interview-song...
This idea seems more to be about planting crops in such a way that you can remove them easily from a garden.
I just want to add that "Programming Pearls" by Jon Bentley is a treasure and (although it might not seem like it) has a lot to add to this sort of consideration (the slow painful evolution of elegant programming.)
This is arguably easy to avoid, yet people manage to do it.
My specific concern is where it pushes that a big ball of mud is easy to write, but hard to maintain. I agree, but oddly, a ball of mud is also somewhat easier to delete. Such that, it is best to grow your code from that core and only grow to reusable parts if needed.
I encountered this at work recently. I fully agree that reusable and "single responsibility" is nice. However, to extract out 5 lines of code such that we now have 3 new classes and possibly a new dependency seems the opposite of the spirit here. If we ever got where that logic isn't needed, as is, you delete 5 lines of code. In the "abstracted out" world, you have to delete several classes, making sure nobody else had taken a dependency on it.
I get that counting by lines of code is not the best metric, but it is an easy one. And, in general good faith code, the lower that metric, the better. It is less to read. Less things connected together to reason about. And, less stuff that you could delete in the future if able.
I'm not arguing for the entire thing to be a ball of mud. Just pushing that there are trade-offs. And, in general, less code is better code. Even if it is a larger method.
Granted, I think a lot of this is in strawmen. Breaking 5 lines out of a 40 line method so that you can be better abstracted is usually fighting the wrong things. Breaking it out of a 500 line function is different.