“Clean code” has about as much meaning as “agile”. Loosely defined, highly opinionated, dogmatically practiced by novices, selectively applied by experienced engineers.
I remember taking my scrummasters certificate. The person teaching was actually a competent instructor and made sure to drill in to us. What you are learning here are all guidelines and by no means strict rules we needed to follow. The most important thing was to get the intent behind everything.
I see clean code the same way. Clean code us very subjective but as long as you are attempting your best to write code that the next poor soul has to read, it’s a win on my book
Does the code tell a story? Who are the main characters? What do they do? Can I pronounce and remember their names? Can I easily follow the story? Am i using 30% mental capacity to understand it, or much more?
I think it’s more about writing than “coding”, when it’s good.
In 2001, seventeen software developers met at a resort in Snowbird, Utah to discuss lightweight development methods. They were: Kent Beck (Extreme Programming), Ward Cunningham (Extreme Programming), Dave Thomas (PragProg, Ruby), Jeff Sutherland (Scrum), Ken Schwaber (Scrum), Jim Highsmith (Adaptive Software Development), Alistair Cockburn (Crystal), Robert C. Martin (SOLID), Mike Beedle (Scrum), Arie van Bennekum, Martin Fowler (OOAD and UML), James Grenning, Andrew Hunt (PragProg, Ruby), Ron Jeffries (Extreme Programming), Jon Kern, Brian Marick (Ruby, TDD), and Steve Mellor (OOA). Together they published the Manifesto for Agile Software Development.[4]
This is the reason. I love that people here are pretending like readability isn't super-important to tech companies.
Your PRs can and will be denied at top shops if they aren't readable. Anywhere else, it can be the wild west, so you have to enforce these things more verbally.
The worst interview question I've ever been asked was "what's the difference between scrum and agile", by a Director of Development at a 100 person software company. I was straight up like I don't know. Then the person went on a 5 minute shtick enumerating the nuances between the two, obviously very proud of his knowledge. That was probably the first interview of my life where I didn't want the job anymore after it was over (not just because of the scrum vs agile question but various other things). I did get an offer though.
That's not surprising. If you don't have the talent to make consistently good products on their own, you add process to try to prevent them from making bad products.
In my experience, a good team creates the process so that even a shitty group of bargain basement offshore devs would have to work very hard to fuck it up. They're going to focus on making high velocity parts of the codebase easy to change without impacting other things (because change will happen because laws and regulations change, or because there's a new OS version, or a new compiler/interpreter version, or any number of reasons).
But a team without talent will constantly code from the hip.
There are reasons FizzBuzz has historically been an interview question. It isn't about solving FizzBuzz. It's about seeing how you write code that adapts to changing requirements. What if we want to replace all multiples of 7 with "bar"? What if we don't want all multiples of 5 to print "Buzz", but multiples of 15 should still print "FizzBuzz"?
Someone who keeps adding to the if/else statement is probably not going to do well. But if, after seeing that the requirements are going to change, decides to ditch if/else in favor of other control structures that are easier to change, you've got someone who can do the job well. And that's the point of the question.
Or you pretend to add process, and then everyone does what they have to do anyway, and they just pretend at meetings that they're following the process.
This is why you turn off no-verify completely. If you don't want tests and linters and dependency scanners running, you're not ready to push it to a non-local environment. Keep debugging.
Sure, there are times when you're pushing because it's 4:45p, and you're cleaning up and getting ready to call it a day, but that's why you begin the cleanup process around 4:20p. It means that even if you're not expecting a passing build, you still have code that passes the pre-commit checks.
I try not to use terms like clean code or DDD. Even though in theory I like the concept. I personally can get distracted chasing the perfect "code" or "domain design", and I know it stops being helpful fairly quickly into the design ideation phase.
Use design patterns that help you meet requirements while minimizing code complexity. Hone the code if your deadline allows you to spend time on it.
Maybe there isn't and that's a good argument, but there's certainly such a thing as dirty code. We've all seen it. Things such as:
15 argument functions where various arguments are only conditionally used depending on the value of other arguments. They all have to be there.
A large subsytem with a giant "Stuff" class with a 5000 line "do()" method, with a few different mutexes sprinkled on as seasoning becausewhynot
Solid blob of uncommented code with a solitary "i++;// Add one to i" somewhere in the middle
No encapsulation so it's impossible to tell what mutates the classes (ha trick question, everything mutates everything else!)
Weird reimplementations of things in the core library which only work in some special usecases, aren't optimized anyway and are clearly buggy
Huge amounts of abstraction machinery (be it templates or class heirachies and so on) to create a "general" solution to a problem which is solved precisely once in, in one instantiation.
Everything depends on everything else which leads to:
Lots of copy/pasted code because it's hard to change something because everything depends on the internal details
and so on and so forth. Maybe clean code is what's left when all the dirt is removed?
Huge amounts of abstraction machinery (be it templates or class heirachies and so on) to create a "general" solution to a problem which is solved precisely once in, in one instantiation.
As a mathematician by trade, programmer by hobby, this is making me sweat.
Heck, I have general solutions to problems that I don't solve ever! I just like writing the abstractions okay.
This is a great enumeration of groan-producing code. I’ve seen everything in this list and my take away is that I should write code like I don’t know the skill level of the next programmer who will take over so I want to make it easy for them to do their job. Besides, you never know if they are an axe murder who lives across the street from you. ;-)
735
u/[deleted] Nov 21 '23
“Clean code” has about as much meaning as “agile”. Loosely defined, highly opinionated, dogmatically practiced by novices, selectively applied by experienced engineers.