45 ms·
Beyond Clean Code
- ilrwbwrkhv 2y agothe problem with code is that the abstraction changes and data needs to be migrated: e.g. a user is enabled if they have paid... time passes... now a user is enabled if the team they belong to has paid. now you need to move the logic to another struct / class and the data to another table. now this is where "payables" and things come in and you start going the path of clean code with 1000 classes. instead, the best way to do this is immutable data streams and event listeners. after over a decade of programming, i feel for most software with a customer focus (not low level, embedded etc), immutable data streams where data flows through and listeners do things to themselves is the best way.
- pezo1919 2y agoSame conclusion here. May I ask about your stack/domain?
- charlie0 2y agoI fully agree, but this requires a certain level of experience to organize code in a way that makes it easy to navigate and modify. It's quite easy to end up with with "rube goldberg" code where you don't know what listeners are being triggered by what streams. Or to end up with a ton of edge cases where things aren't handled properly when issues occur.
- leonseled 2y agoYea agree. I feel one of the best books ive read that makes this concrete is Grokking Simplicity by Eric Normand. It’s less about functional programming and more about functional thinking. Lots of concrete great advice in that book.
- nateglims 2y agoCasey Muratori is basically describing Data Oriented Programming. Perhaps the most famous talk about it was from CPPCON 2014 [1]. I come from an embedded background (microcontrollers and bare metal) so I'm pretty sympathetic to his argument. If you work in it long enough, it feels natural and "clean". Uncle bob's Clean Code probably feels natural to Java devs. Personally, my biggest gripe comes from experiencing people trying to introduce it to a team. Inevitably someone tries to enthusiastically implement some part of it and suddenly are writing 1 line functions everywhere. I think this is the type of thing Casey is also implicitly talking about when he's railing against the rules being brought up. [1] https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc
- jpardy 2y agoIn addition to Mike Acton's talk, there is also the "DOD Book": https://www.dataorienteddesign.com/dodbook/ https://www.dataorienteddesign.com/dodbook/
- wiseowise 2y ago> Uncle bob's Clean Code probably feels natural to Java devs. No.
- tcfhgj 2y agoDon't see a problem with one line functions per se, especially if the name of the function helps understanding the code
- arp242 2y agoThere no problem with them, and they can often be useful. But there is a problem if all the code is only functions of one or two lines, or when people move things to functions when it just doesn't make much sense, "because it's Best Practice™".
- pbw 2y agoPylint warns if you have “more than X” for a lot things like local variables, number of arguments, number of member variables, etc. For most of these the limits are in the 5 - 9 range but for lines in a function/method the limit is 50 lines. I agree with this. One line functions are okay sometimes but 50 line functions can be fine as well if clear and well written. A lot depends on the cyclomatic complexity: how many loops and branches, how drastically the indentation varies basically. So I disagree with how strenuously Uncle Bob harps on short methods, although paradoxically I do agree many methods in the wild are too long. Most of them grew to be too long because it’s easier to add a few lines to an existing method than to refactor things —- particularly if a code review is required.
- LorenPechtel 2y agoYup. I would like to keep things on the screen if feasible, but it's really always cyclomatic complexity that matters. A linear flow of lines, I don't care about until I can't see it all at once but you're rarely writing a linear flow of lines.
- KaiserPro 2y agoI like this article. At the start I feared it was going to be one of those polemics written by someone who's never had to read other people's code, or worry about speed, efficiency or third party users. However thats not the case. The author has distilled lots of experience into something reasonably readable.
- Uehreka 2y agoSo like, Clean Code really does say you should write four line functions, and does not put caveats on that statement, Uncle Bob even gives a lengthy terrible-looking example of a class written with 4-line functions and holds it up as the ideal. His views as expressed in that book are extreme and uncompromising, the “everything in moderation, there are many ways to write clean code” stuff is a rhetorical act he does when people call him out. Then when they’re gone and he thinks he can get away with it he starts speaking in absolute statements again. Like, this is a conversation Uncle Bob had with Casey Muratori on GitHub, I came away feeling like Uncle Bob is more interested in playing rhetorical judo than anything else: https://github.com/unclebob/cmuratori-discussion/blob/main/cleancodeqa.md https://github.com/unclebob/cmuratori-discussion/blob/main/c...
- paulddraper 2y agoUncle Bob sounds good verbally. Like "small functions." I say, okay, okay, stop writing these 2000 lines of spaghetti, I'm a hundred percent on board. Then when you get to the concrete example, it's decomposing this 15 line function. Good idea. Calibration is waaaay off.
- booleandilemma 2y agoHe's the son of a pastor, he's definitely interested in rhetorical judo.
- icholy 2y agoHas uncle Bob actually produced any useful software? Are there any examples of his work out there which can be analysed?
- tcfhgj 2y agoPeople can give good insight about things despite even not creating these things, see e.g. physicists who study atoms
- mckn1ght 2y agoIt’s more like someone who gives talks about smashing atoms to study subatomic particles without ever having been to a particle accelerator facility. You can’t replace experience. There’s theory, then there’s practice. Ideas are worthless until tested in reality.
- tester756 2y agoThe most important thing when evaluating things you need to know is: context matters Principles arent universal across technologies Hell, principles arent even universal across software kind (e.g goto arent used in C# web dev, but std lib? yes)
- agumonkey 2y agoAnd across teams, business.
- Yasuraka 2y agoThe context in this case being that Robert "Uncle Bob" Martin is a charlatan and an impostor.
- CrimsonRain 2y agothis comment says more about you than him :)
- Yasuraka 2y agoToo many words in a line. I could not read it. Please split it into five lines. This is actually an improvement!
- DonaldPShimoda 2y agoPersonally, I'm a fan of when he has argued with academics on Twitter about things that he is actually ill-equipped to discuss, but he refuses to budge because their (factually correct) statements don't align with his limited worldview. Really made me want to get his books for sure.
- throwway120385 2y agoThe other cool thing about an OOP approach to this problem is that you can hide your optimized LUT behind the OOP if you're careful about the design of it. This lets you have your cake and eat it too. Your users who might be more comfortable with an OOP approach get a way to declare the kinds of shapes they're interested in and the number of shapes they want to work with. Then you can take responsibility for building a LUT that meets their needs and give them the supporting optimizations they need to be successful.
- pbw 2y agoThis is a great point and very true.
- icholy 2y agoIf anyone wants to read the antithesis of Clean Code, check out "A philosophy of software design"
- amai 2y agotldr; Premature optimization is the root of all evil. (Donald Knuth)
- p0w3n3d 2y agoI think a programmer can set badly any good pattern. We have onion pattern in our code and I get sick every time I enter it. All's great but it implements a graph of state changes navigating which resembles debugging a regexp, also all the ctrl+click navigation is broken because there's one general method for each message root type