Preach it. I feel like you took the words right out of my mouth. I left my last job because I couldn’t keep sitting and listening to the bullshit about how everything had to be built the same, citing “uncle Bob” every.single.day… coerced into long, drawn out PRs that oscillated between “I don’t like how much you’re changing, can you break it up?” to “what’s the reason for this change?” — lol you literally asked me to break it up. I dunno wish them the best, but god that place was a drag. I knew it was a red flag when I logged into the rabbitmq cluster and immediately notices there was no TLS and when I tried to talk about it I got waved off and asked what was assigned to me, 3 months later I open a 2 line PR and the shadow architect goes “wait, we’re not using TLS?” “Nope” “did you mention this before?” “Yep” SMH
There’s No Such Thing as Clean Code
31–40 of 395 posts
Re: There’s No Such Thing as Clean Code
#32And yet, everyone will agree:
void dothing1(Args..){...}
//old version of dothing1 the programmer keeps around to copy code from later // which should never be used void dothing1_backup(Args..){...}
is not clean.
People often strive for explicit and complete inclusive definitions for concepts better defined by what they are not. The former is more powerful when it applies, but the latter case is much more common.
Re: There’s No Such Thing as Clean Code
#33Language is often about being able to take shortcuts, to infer meaning, to talk about things in the abstract an everyone understand what you mean.
Clean Code is just a concept, it’s up to you to define it within your culture or community.
I think most developers will have a basic grasp of the difference between clean and ugly code, you just might need to discuss the finer details as you learn.
Because it’s not well defined globally doesn’t mean there’s no such thing or it doesn’t exist.
Re: There’s No Such Thing as Clean Code
#34There is such a thing as simple code.
The job of the engineer is to make complexity simple, even when your target market is other engineers.
The complexifiers and verbose Vogons persist heavily today though, as well as project management processes that create an infested myriad of complexity from shallow code to legions of dependencies and asset flipping rather than an effort to be close to the actual standards that run things, abstraction overuse is a major problem.
Simplicity takes a professional to achieve and maintain. Simplicity and simple parts lead to "clean" code.
Re: There’s No Such Thing as Clean Code
#35Coding is a highly subjective and creative endeavor. "Clean code" is akin to "well written" for writers. Sure, you can analyze and even be able to define some good practices, but because we are always creating something new that has never done before, and the field is infinitely complex, no rules can be set in stone and applied across everything. In my opinion there's nothing wrong with calling code clean, we don't h…
People are rewriting things all the time for various reasons.
Re: There’s No Such Thing as Clean Code
#36Clean code is code that does what you expect it to do without many surprises. It is simple, not clever. Effortless to follow. Each part handles one idea at a time, at the same abstraction level. Doesn't force you to mentally juggle many balls at the same time. The code often tells you a story, it communicates how the programmer (author) described the problem, the solutions and the trade-offs. Very similar to writing.…
>> It is simple, not clever. Effortless to follow.
This is the crux of it for me. I want to read code not solve code. If I have to "figure out what's going on" then it's not great code.
Re: There’s No Such Thing as Clean Code
#37Beauty is in the eye of the beholder.
But, I think there are cases where it's quite obvious that one solution is "cleaner" than the other. Sometimes a refactor is just strictly better in all ways.
I once had a service that wrapped a core algorithm in our code, but the code for the server and the code for that algorithm were all jumbled together. It became hard to write tests for the algorithm because the server wanted sockets and a specific protocol and blah blah blah.
So, I simply separated them - the server instantiated the algorithm and called simple functions in it. Tests could do the same - it was strictly better in every sense - it made each part easier to reason about, test, read, understand... And with no real performance difference. "Clean"
Re: There’s No Such Thing as Clean Code
#38The only clean code is the one that doesn't do anything.
Apart from that you can only hope to avoid adding too much dirt.
Re: There’s No Such Thing as Clean Code
#39Clean code is code that does what you expect it to do without many surprises. It is simple, not clever. Effortless to follow. Each part handles one idea at a time, at the same abstraction level. Doesn't force you to mentally juggle many balls at the same time. The code often tells you a story, it communicates how the programmer (author) described the problem, the solutions and the trade-offs. Very similar to writing.…
In my work history, I've never come across code like this, especially "effortless to follow". All the codebases I've worked with have been head scratch causing balls of mud.
Am I unlucky or is what you are describing the rare exception?
Re: There’s No Such Thing as Clean Code
#40Earlier quoted context omitted.
Wait until you work on a 100k line code base where someone enforced this kind of thing
Fair enough - I haven't done that. I'd be surprised if having loads of anonymous, untested functions would make such a thing more manageable, though.
Do you test every line of code you write separately? Probably not. You test a function that has 5 lines of code.
Same for anonymous functions. You test the functions that use them and that's usually enough. If not, then that is a good indicator of separating them out into named functions.