this post was submitted on 10 Aug 2024
140 points (94.9% liked)

Programming

17313 readers
74 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 1 year ago
MODERATORS
 

Seeing that Uncle Bob is making a new version of Clean Code I decided to try and find this article about the original.

top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 52 points 2 months ago (1 children)

I felt the same when reading that book, and I never finished it because following the rules he suggested produced horrible code.

If memory serves, he also suggested that the ideal if statement only had one line inside, and you should move multiple lines into a function to achieve this.

I once had to work on a codebase that seemed like it had followed his style, and it was an awful experience. There were hundreds of tiny functions (most only used once) and even with an IDE it was a chore to follow the logic. Best case the compiler removed most of this "clean" code and the runtime wasn't spending most of its time managing the stack like a developer had to do.

[–] [email protected] 26 points 2 months ago (2 children)

There's nothing quite like the unique pain of navigating an unfamiliar codebase that treats abstraction as free and lines of code in one place as expensive. It's like reading a book with only one sentence per page, how are you supposed to understand the full context of anything??

[–] [email protected] 9 points 2 months ago

Haha, the horrors of trying to fix a bug in OpenOffice flash before my eyes

[–] [email protected] 7 points 2 months ago

It’s abstract art!

[–] [email protected] 37 points 2 months ago (2 children)

There's a piece of code in our hobby game project that I've written after attending classes in college about how to write clean and SOLID code. It's the most overengineered piece of shit I've ever written. I'm not saying it's the fault of the lectures, of course it's on me being a little bit over zealous, but it does check all the boxes - It's a simple "show selectable list of stuff", follows MVC, it's extensible without rewriting to adittional data-types and formats, extensible view that can show any part of data you need, generic, and in general it could be used anywhere we need, for any kind of data.

There's only one place where we need and use such list in our game.

I needed to rewrite a part of it, since the UI changed drastically, to not need this kind of list, while also adding events into the process. I haven't seen the code for almost 4 years, and it's attrocious. Super hard to understand what's going on, since it's too generic, interfaces and classes all over the place, and while it probably would be possible to rewrite the views for the new features we need, it's just so complex that I don't have the mental capacity to again figure out how it was supposed to work and properly wire it up again.

I'm not saying it's fault of the classes, or SOLID. It's entirely my fault, because the classes inspired and hyped me with ideas about what a clean code should look like, that I didn't stop and think whether it's really needed here, and went over-the-top and overengineered the solution. That's what I'd say is the danger of such Clean Code books and classes - it's easy to feel clever for making something that passes SOLID to the letter, but extensibility usually comes at a complexity, and it's super important to stop and think - do I really need it?

[–] [email protected] 18 points 2 months ago (1 children)

Academia has a disconnect with the industry when it comes to coding practices. Most teachers haven’t much industry experience. They don’t know how it is to maintain a 10 year old project using SOLID and clean code principles.

They just teach whatever has already been in the curriculum for decades. They don’t know that whatever they’re teaching is actually harmful in the industry.

load more comments (1 replies)
[–] Treczoks 6 points 2 months ago (1 children)

Super hard to understand what’s going on, since it’s too generic

In other words, you wrote nice code, but forgot to document it?

[–] [email protected] 4 points 2 months ago (1 children)

That's a good question, and I never through about it like that. I think that the lack of documentation isn't that much of a problem, rather that the code stands out in the project in that it is complex to understand and requires some more though, effort and imagination to grasp, since it's generic with lot of interfaces and polymorphism.

Now, that usually wouldn't be much of an issue, however - the project is a game we've been actively working on in our spare time in a team of 2 programmers for the last 6 years, and we are all fed up with it and just want it to end. Most of the (pretty large by now) codebase is kind of simple - it's a game code, after all, and since we started it when we were 20, there aren't many overenginered ideas or systems, but everything is mostly written in the ugly, but simple and direct way, so if we had wanted to change something, we may have had to rewrite a part of it, but it never really needed much effort to understand what's going on.

But now I need to change this code, which is one of the only parts that requires some kind of imagination and actually sitting down and trying to understand it, and since my motivation about the project is so low, it's a pretty large hurdle to cross. One that is also unnecessary, since most of the generalism isn't needed and will never be used. But since the code is written in such extensible way, it's hard to just hack up a simple and ugly solution somewhere into it and be done with it, without really figuring out what the hell is going on.

A documentation wouldn't help with that - it would still take the same amount of mental effort to be able to work with that code, which we generally lack in the project. I think that if I actually took the time to properly look through the code, figuring out what's going on wouldn't be too hard - the naming convention is pretty ok and it's not that difficult, it just requires some mental effort.

I'm not trying to make excuses, the code very probably has problems, I'm just trying to better sort my thoughts about why I have so much problems working on it. It probably has more to do with my motivation, rather than the code in itself, and the fact that the complexity here wasn't required, and is now a needless hurdle that actually hinders progress. Not due to it's quality, but do to unrelated motivation issues and us having to basically force ourselves to work on and finish the damn project.

[–] [email protected] 3 points 2 months ago (1 children)

Is it possible that you just chose the wrong abstractions?

[–] [email protected] 3 points 2 months ago (1 children)

Usually it doesn't matter what abstractions you choose when you try to factor them to support hypothetical future work, because chances are you incorrectly anticipate future needs.

In other words, generic code that only supports one use case will almost certainly have to be deconstructed to allow a good generic implementation for 2 use cases, so it is better to just write simple code and factor code out when you can see the real commonalities.

In other, other words, KISS, YAGNI

[–] [email protected] 2 points 2 months ago

Good abstractions are important for the code to be readable. An AbstractEventHandlerManager is probably not a good abstraction.

The original commenter said that their code was "generic with lot of interfaces and polymorphism" - it sounds like they chose abstractions which hindered maintainability and readability.

[–] [email protected] 21 points 2 months ago (2 children)

I feel like it’s wrong to idolize anything in the same way that it’s wrong to throw out many things (there are some clear exceptions usually in the realm of intolerance but that’s unrelated to this). Clean Code, like every other pattern in software development, has some good things and some bad things. As introduction to the uninitiated, it has many good things that can be built on later. But, like Gang of Four, it is not the only pattern we apply in our craft and, like Agile, blind devotion, turning a pattern into a prescription, to Clean Code is going to lead to a lot of shit code.

Cognitive load helps us understand this problem a lot better. As a junior with no clue how to write production code, is Clean Code going to provide with a decent framework I can quickly learn to start learning my craft, should I throw it out completely because parts are bad, or should I read both Clean Code and all its criticism before I write a single line? The latter two options increase a junior’s extraneous cognitive load, further reducing the already slim amount of power they can devote to germane cognitive load because their levels of intrinsic are very high by the definition of being a junior.

Put a little bit differently, perfection (alternatively scalable, maintainable, shipped code) comes from learning a lot of flawed things and adapting those patterns to meet the needs. I am going to give my juniors flawed resources to learn from to then pick and choose when I improve those flaws. A junior has to understand the limitations of Clean Code and its failures to really understand why the author is correct here. That’s more cognitive science; we learn best when we are forming new connections with information we already know (eg failing regularly). We learn worse when someone just shows us something and we follow it blindly (having someone solve your problem instead of failing the problem a few times before getting help).

I’m gonna be super hand-wavy with citations here because this a soapbox for me. The Programmer’s Brain by Felienne Hermans does a good job of pulling together lots of relevant work (part 2 IIRC). I was first introduced to cognitive load with Team Topologies and have since gone off reading of bunch of different things in pedagogy and learning theory.

[–] [email protected] 17 points 2 months ago

The article goes into that. Clean Code has some good advice. But it also got bad advice.

Problem is, the good advice is basic. Anyone working in the industry will pick most of these up. All the good advice could be summed up in 10 pages or so.

The bad advice is incredibly bad - and in the worst cases even be counter productive. A newbie won’t be able to tell these advice apart. Some professionals might not either. So they adopt these techniques to their code, and slowly their code turns into an unmaintainable mess of spaghetti.

So no, the book shouldn’t be recommended to anybody. It has already done enough harm to the industry.

[–] [email protected] 6 points 2 months ago (1 children)

As a junior with no clue how to write production code, is Clean Code going to provide with a decent framework I can quickly learn to start learning my craft, should I throw it out completely because parts are bad, or should I read both Clean Code and all its criticism before I write a single line?

I see what you’re getting at it, and I agree we shouldn’t increase the load for juniors upfront. But I think the point is mainly there are better resources for juniors to start with than Clean Code. So yeah, the best option is to throw it out completely and let juniors start elsewhere instead, otherwise they are starting with many bad parts they don’t yet realize are bad. That too would increase cognitive load because they would need to unlearn those lessons again.

[–] [email protected] 2 points 2 months ago (7 children)

Exactly. The article is pretty clear with this point. Junior devs aren't the ones we should be giving mixed bags of advice to.

load more comments (7 replies)
[–] [email protected] 9 points 2 months ago

IMO it would be best to present code that fits in a single file to people on the net and refactor it to their liking while keeping the same functionality, then let others rate the style and pick a few characteristics. Then the code can be ranked by the different characteristics to obtain the top 5 or so "cleanest" coding styles.

I feel it's worth doing an entire study instead of relying on what one dude says is clean code. Let the people speak.

Anti Commercial-AI license

load more comments
view more: next ›