Earlier quoted context omitted.
Disagree. Highly disagree. Smarter people write shittier code. Clean code is for stupider people. Think about it. It’s because smart people don’t need clean code. It’s so trivial to them and so readable that they really don’t need things to be ultra clean and well formatted. So the tendency to have this ocd need to write clean code among smart people is random. They either have it or they don’t give a shit. But among…
Or maybe the smartest people understand that it is as important that less smart/experienced people than them can work with the code.
Clean Code vs. A Philosophy Of Software Design
251–260 of 554 posts
Re: Clean Code vs. A Philosophy Of Software Design
#252I was around before the clean code movement, and like all software movements, it was a reaction to real problems in the software industry. Massive procedural functions with deeply nested conditionals, no structure, global variables, no testing at all. That was all the norm. Clean Code pushed things in a better direction, but it over-corrected. In many ways APOSD (published in 2018) is a correction against the excesse…
I believe that there is a genuine physiological effect that makes it a good idea to have the area of code that you need to think about fit entirely on one screen, without scrolling. There is probably an upper limit to the screen height where that limit is useful: I would believe a 100-line function to be above it and a 24-line function to be safely below it, but I wouldn't want to hazard a guess in the middle. It's a…
Re: Clean Code vs. A Philosophy Of Software Design
#253Earlier quoted context omitted.
> "It's not object oriented programming" is only a good case to make if you think object oriented programming is synonomous with good. I don't think that's true. It's sometimes good, often not good. See, this is the sort of lazy ignorance that adds nothing of value to the discussion, and just reads as spiteful adhominems. Domain models are fundamentally an object-oriented programming concept. You model the business d…
> Your Order class has a collection of Product items, but you can update an order, cancel a order, repeat an order, etc. This behavior should be member functions. This is how to fuck up OO and give it a bad name: order.update(..) // Now your Order knows about the database. order.cancel(..) // Now your Order can Email the Customer about a cancellation. order.repeat(..) // Now your Order knows about the Scheduler. What…
- Cat is the subject noun
- Eats is the verb
- Rat is the object noun
In object-oriented programming, the subject is most often the programmer, the program, the computer, the user agent, or the user. The object is... the object. The verb is the method.
So, imagine the sentence "the customer canceled the order."
- Customer is the subject noun
- Canceled is the verb
- Order is the object noun
In OOP style you do not express this as customer.cancel(order) even though that reads aloud left-to-right similarly to English. Instead, you orient the expression around the object. The order is the object noun, and is what is being canceled. Thus, order.cancel(). The subject noun is left implicit, because it is redundant. Nearly every subject noun in a given method (or even system) will be the same programmer, program, computer, user agent, or user.
For additional perspectives, I recommend reading Part I of "Object-Oriented Analysis and Design with Applications" (3rd edition) by Grady Booch et. al, and "Object Thinking" by David West.
---
That said, I think you're right about the single responsibility principle in this example. A class with too many behaviors should usually be decomposed into multiple classes, with the responsibilities distributed appropriately. However, the object should not be left behavior-less. It must still be an anthropomorphized object that encapsulates whatever data it owns with behavior.
Re: Clean Code vs. A Philosophy Of Software Design
#254Earlier quoted context omitted.
To restate something I've said here last month: I'm fond of saying that anything that doesn't survive the compilation process is not design but code organization. Design would be: which data structures to use (list, map, array etc.), which data to keep in memory, which data to load/save and when, which algorithms to use, how to handle concurrency etc. Keeping the code organized is useful and is a part of basic hygien…
My take is that the book also works as a source of authority for aspiring SSR and SR devs. Comments about code style are usually subjective, and, they can be easily dismissed as a personal preference, or, in the case of a Jr dev, as a lack of skill. Until they bring up "The Uncle Bob book". Now, suddenly, a subjective opinion from a Jr dev looks like an educated advice sourced from solid knowledge. And other people n…
Re: Clean Code vs. A Philosophy Of Software Design
#255Earlier quoted context omitted.
Nothing is fixed in stone. If you have strong typing and program with pure functions and immutability while utilizing union types and matching to the full extent you typically need very few unit tests for your code to work. You just need integration and e2e tests. I write very little unit tests as my coding style that employs static checks as viciously as possible doesn’t necessitate it. I would say only 30 percent o…
I don't really agree, unit test should test behavior, having types of not should not be a defining factor in the coverage. I don't think patterns as a whole are good but there are known issues and structures to existing problems so boiling it down to art seems reductionist imo.
I can code and not test behavior and have that behavior work reliably without tests. Key word is the unit trst. Typically IO and things that live outside these boundaries need integration tests.
Most of web programming today actually doesn’t need much unit testing. You’re not doing much processing. The web layer functions as a router and that layer is a meta layer that writes code that executes somewhere else.
Over half the code executes as sql. Integration tests are by far more important.
Boiling it down to an art is not reductionist. It’s true. Where is the scientific method in programming? How was a pattern deduced using the scientific method? If it was not deduced using the method then was it created from axioms and logic like math? Is it a theorem?
No. It’s all just made up. And we have no quantitative way of verifying why one design is better than another design. That’s why software technology often moves horizontally. There’s no way to verify the current design was better than the last.
Even both you and I have a disagreement and are at a stalemate. Can you prove your unit testing is superior to my static testing? Not really. Actually tbf static checking is provably better if you don’t count the dimension of effort required to use dependent types.
Re: Clean Code vs. A Philosophy Of Software Design
#256Earlier quoted context omitted.
But there are typical practices we agree are good: using a VCS, writing tests, write comments when needed, separate different level of abstractions, etc. Right? This comes from years of common experience in software. Over time we get to find patterns, common issues and ways to fix them, etc. It doesn't have to be strict patterns but overall strategies. If we don't do that then it's just vibes right? Where's the engin…
Nothing is fixed in stone. If you have strong typing and program with pure functions and immutability while utilizing union types and matching to the full extent you typically need very few unit tests for your code to work. You just need integration and e2e tests. I write very little unit tests as my coding style that employs static checks as viciously as possible doesn’t necessitate it. I would say only 30 percent o…
I don't think patterns as a whole are good but there are known issues and structures to existing problems so boiling it down to art seems reductionist imo.
Re: Clean Code vs. A Philosophy Of Software Design
#257Uncle Bob's insistence that functions should be 2-4 lines long is baffling to me. I don't understand how he can be taken seriously. Is there a single application in the entire world with substantial functionality that conforms to this rule?
Too often I see functions that are shells that reshuffle the arguments and pass them to another function, which also reshuffles the arguments and forwards them to another, and on and on. One was 11 layers deep.
Re: Clean Code vs. A Philosophy Of Software Design
#258You just need to work on one project built by someone that implemented Uncle Bob recommendations blindly when the books came out to know how much they are worth. There were some low hanging fruits to pick at the time regarding trying to be better at software engineering and he generated some text about them. Full of terrible advices, he never wrote anything significant (in scope and notoriety) during his time as a so…
A Philosophy of Software Design on the other hand is concise, excellent, and based on decades of teaching experience.
1: I'm aware it's a software engineering book, but since there are very few B.S. Software Engineering programs out there, You Know What I Mean ™
Re: Clean Code vs. A Philosophy Of Software Design
#259I have worked with a couple of people over the years who instead of breaking functions out when something would say make sense to be reused or made some sort of logical sense as a unit, instead seemingly just bundle lines whose only real relationship was that they happened to be near each other when they decided to "refactor". Having read Clean Code back in college as it was assigned reading, it was absolutely the vi…
The warning sign I see when methods are split too much is that the method boundaries start to get messy: methods take too many arguments, or state is saved into confusingly named class members, or you end up returning some struct containing a grab bag of unrelated values.
Re: Clean Code vs. A Philosophy Of Software Design
#260Earlier quoted context omitted.
Why not put the prose in the name of the function?
Function names are limited. E.g. can't provide a circuit diagram of what you're controlling in a function name. But you can do that in a comment (either with ASCII art or an image link).