38 ms·

It's probably time to stop recommending Clean Code (2020)

• PaulHoule 5y ago
  Java is still popular. JDK 17 looks as much like ML (e.g. oCAML) as they can make it as fast they can make it without breaking things.
  • MrBuddyCasino 5y ago
    Also, the tooling and compiler speed aren't fucked like they are in Scala or Kotlin. I like Kotlin, especially the null-safety, but the ecosystem's quality is kinda shoddy. Everything is just faster and less buggy in Java.
• danielskogly 5y ago
  Previous discussion from 11 months ago: https://news.ycombinator.com/item?id=23671022 https://news.ycombinator.com/item?id=23671022
• zabzonk 5y ago
  Martin is, and always has been, a plagiarist, ghost-written, clueless, idiot, with a way of convincing other know-nothings that he knew something. At one time he tried to set up a reputation on StackOverflow, and was rapidly seen off. Toxic. Avoid.
• dham 5y ago
  Yes let's please do this. I'm tried of this book being brought up at work. My clean code book: * Put logic closest to where it needs to live (feature folders) * WET (Write everything twice), figure out the abstraction after you need something a 3rd time * Realize there's no such thing as "clean code"
  • anonyfox 5y ago
    > WET (Write everything twice), figure out the abstraction after you need something a 3rd time so much this. it is _much_ easier to refactor copy pasta code, than to entangle a mess of "clean code abstractions" for things that isn't even needed _once_. Premature Abstraction is the biggest problem in my eyes. Write Code. Mostly functions. Not too much.
    • allo37 5y ago
      I think where DRY trips people up is when you have what I call "incidental repetition". Basically, two bits of logic seem to do exactly the same thing, but the contexts are slightly different. So you make a nice abstraction that works well until you need to modify the functionality in one context and not the other...
      • bradstewart 5y ago
        So much this. Especially early in project's life when you aren't sure what the contexts/data model/etc really need to be, so much logic looks the same. It becomes so hard to untangle later.
      • fiddlerwoaroof 5y ago
        If you mostly deduplicate by writing functions, fixing this problem is never very hard: duplicate the function, rename it and change the call-site. The interesting thing about DRY is that opinions about it seem to depend on what project you’ve worked on most recently: I inherited a codebase written by people skeptical of DRY, and we had a lot of bugs that resulted from “essential duplication”. Other people inherit code written by “architecture astronauts”, and assume that the grass is greener on the WET side of the fence. Personally, having been in both situations, I’d almost always prefer to untangle a bad abstraction rather than maintain a WET codebase.
        • jakelazaroff 5y ago
          Conversely, fixing duplication is never hard. Just move the duplicated code into a function. Going in reverse can be much tougher if the function has become an abstraction, where you have to figure out what path each function call was actually taking. Or, put another way: I'd much rather deal with duplication than with coupling problems.
          • fiddlerwoaroof 5y ago
            The issue I have is that duplication is a coupling problem, but there’s no evidence in the coupled parts of the code that the coupling exists. It can be ok on a single-developer project or if confined to a single file, but my experience is that it’s a major contributor to unreliability, especially when all the original authors of the code have left.
  • BurningFrog 5y ago
    https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...
  • innagadadavida 5y ago
    How do you deal with other colleagues that have all the energy and time to push for these practices and I feel makes things worse than the current state?
    • Spivak 5y ago
      Explain that the wrong abstraction makes code more complicated than copy-paste and that before you can start factoring out common code you need to be sure the relationship is fundamental and not coincidental.
      • bluGill 5y ago
        And get ignored or laughed at. Some people know the rules and nothing but.
  • 29athrowaway 5y ago
    > Realize there's no such thing as "clean code" You can disagree over what exactly is clean code. But you will learn to distinguish what dirty code is when you try to maintain it. As a person that has had to maintain dirty code over the years, hearing someone saying dirty code doesn't exist is really frustrating. Noone wants to clean up your code, but doing it is better than allowing the code to become unmaintainable, that's why people bring up that book. If you do not care about what clean code is, stop making life difficult for people that do.
    • rendall 5y ago
      > hearing someone saying dirty code doesn't exist is really frustrating Not sure why you're being downvoted, but as an unrelated aside, the quote you're responding to literally did not say this. > that's why people bring up that book I think the point is that following that book does not really lead to Clean Code.
      • 29athrowaway 5y ago
        > I think the point is that following that book does not really lead to Clean Code. And that is why I started saying "You can disagree over what exactly is clean code". Different projects have different requirements. Working on some casual website is not the same as working on a pacemaker firmware.
        • rendall 5y ago
          Yeah, I don't know that we're disagreeing here. For me, there's definitely good code and bad code. I read OP more as saying perfect is the enemy of good, not that all code is good code. I'd say if you want good code in your working environment, set up a process for requiring it. Automated testing and deployment, and code reviews would be the way to go. Reading Clean Code won't get you there.
    • ljm 5y ago
      I think it's more that clean code doesn't exist because there's no objective measure of this (and those services that claim there are are just as dangerous as Clean Code, the book); anyone can come along and find something about the code that could be tidied up. And legacy is legacy, it's a different problem space to the one a greenfield project exists in. > As a person that has to maintain dirty code This is a strange credential to present and then use as a basis to be offended. Are you saying that you have dirty code and have to keep it dirty?
  • UglyToad 5y ago
    I think this ties in to something I've been thinking, though it might be project specific. Good code should be written to be easy to delete. 'Clever' abstractions work against this. We should be less precious about our code and realise it will probably need to change beyond all recognition multiple times. Code should do things simply so the consequences of deleting it are immediately obvious. I think your recommendations fit with this.
    • Benjammer 5y ago
      >code should be written to be easy to delete This article tends to make the rounds on here every once in a while: https://programmingisterrible.com/post/139222674273/how-to-write-disposable-code-in-large-systems https://programmingisterrible.com/post/139222674273/how-to-w...
    • msluyter 5y ago
      Aligns with my current meta-principle, which is that good code is malleable (easily modified, which includes deletion). A lot of design principles simply describe this principle from different angles. Readable code is easy to modify because you can understand it. Terse code is more easily modified because there’s less of it (unless you’ve sacrificed readability for terseness). SRP limits the scope of changes and thus enhances modifiability. Code with tests is easier to modify because you can refactor with less fear. Immutability makes code easier to modify because you don’t have to worry about state changes affecting disparate parts of the program. Etc... etc... (Not saying that this is the only quality of good code or that you won’t have to trade some of the above for performance or whatnot at times).
    • munificent 5y ago
      The unpleasant implication of this is that code has a tendency towards becoming worse over time. Because the code that is good enough to be easy to delete or change is, and the code that is too bad to be touched remains.
      • jasonwatkinspdx 5y ago
        One of John Carmack's maxims is "Fight code entropy." As simple as that is it carries a lot of meaning imo.
  • thefourthchime 5y ago
    Ah hahha. I love WET. I always say the only way to write something correctly is to re-write it.
    • HWR_14 5y ago
      That's not what WET means. The GP is saying you shouldn't isolate logic in a function until you've cut-and-pasted the logic in at least two places and plan to do so in a third.
  • amelius 5y ago
    > WET (Write everything twice) In practice (time pressure) you might end up duplicating it many times, at which point it becomes difficult to refactor.
    • Frost1x 5y ago
      If it's really abstractable it shouldn't be difficult to refactor. It should literally be a substitution. If it's not, then you have varied cases that you'd have to go back and tinker with the abstraction to support. It's a similar design and planning principle to building sidewalks. You have buildings but you don't know exactly the best paths between everything and how to correctly path things out. You can come up with your own design but people will end up ignoring them if they don't fit their needs. Ultimately, you put some obvious direct connection side walks and then wait to see the paths people take. You've now established where you need connections and how they need to be formed. I do a lot of prototyping work and if I had to sit down and think out a clean abstraction everytime I wanted to get for a functional prototype, I'd never have a functional prototype--plus I'd waste a lot of cognitive capacity on an abstraction instead of solving the problem my code is addressing. It's best, from my experience, to save that time and write messy code but tuck in budget to refactor later (the key is you have to actually refactor later not just say you will). Once you've built your prototype, iterated on it several times had people break designs forcing hacked out solutions, and now have something you don't touch often, you usually know what most the product/service needs to look like. You then abstract that out and get 80-90% of what you need if there's real demand. The expanded features beyond that can be costly if they require significant redesign but at that point, you hopefully have a stable enough product it can warrant continued investment to refactor. If it doesn't, you saved yourself a lot of time and energy worrying trying to create a good abstract design that tends to fail multiple times at early stages. There's a balance point of knowing when to build technical debt, when to pay it off, and when to nullify it. Again, the critical trick is you have to actually pay off the tech debt if that time comes. The product investor can't look bright eyed and linearly extrapolate progress so far thinking they saved a boatload of capital, they have to understand shortcuts were taken and the rationale was to fix them if serious money came along or chuck them in the bin if not.
      • 5y ago
  • golergka 5y ago
    > * WET (Write everything twice), figure out the abstraction after you need something a 3rd time There are two opposite situations. One is when several things are viewed as one thing while they're actually different (too much abstraction), and another, where a thing is viewed as different things, when it's actually a single one (when code is just copied over). In my experience, the best way to solve this is to better analyse and understand the requirements. Do these two pieces of code look the same because they actually mean thing in the meaning of the product? Or they just happen to look the same at this particular moment in time, and can continue to develop in completely different directions as the product grows?
    • whimsicalism 5y ago
      Solving the former is generally way uglier/more obnoxious IMO than solving the latter, esp. if you were not the person who designed the former.
  • throw1234651234 5y ago
    WET is great until JSON token parsing breaks and a junior dev fixes it in one place and then I am fixing the same exact problem somewhere else and moving it into a shared file. If it's the exact same functionality, move it into a service/helper.
  • Cthulhu_ 5y ago
    This is what I'm doing even while creating new code. There's a few instances for example where the "execution" is down to a single argument - one of "activate", "reactivate" and "deactivate". But I've made them into three distinct, separate code paths so that I can work error and feedback messages into everything without adding complexity via arguments. I mean yes it's more verbose, BUT it's also super clear and obvious what things do, and they do not leak the underlying implementation.
  • KaiserPro 5y ago
    repeat after me: Document. Your. Shit. everything else can do one. Just fucking write documentation as if you're the poor bastard trying to maintain this code with no context or time.
    • caymanjim 5y ago
      Documentation is rarely adequately maintained, and nothing enforces that it stay accurate and maintained. Comments in code can lie (they're not functional); can be misplaced (in most languages, they're not attached to the code they document in any enforced way); are most-frequently used to describe things that wouldn't require documenting if they were just named properly; are often little more than noise. Code comments should be exceedingly-rare, and only used to describe exception situations or logic that can't be made more clear through the use of better identifiers or better-composed functions. External documentation is usually out-of-sight, out-of-mind. Over time, it diverges from reality, to the point that it's usually misleading or wrong. It's not visible in the code (and this isn't an argument in favor of in-code comments). Maintaining it is a burden. There's no agreed-upon standard for how to present or navigate it. The best way to document things is to name identifiers well, write functions that are well-composed and small enough to understand, stick to single-responsibility principles. API documentation is important and valuable, especially when your IDE can provide it readily at the point of use. Whenever possible, it should be part of the source code in a formal way, using annotations or other mechanisms tied to the code it describes. I wish more languages would formally include annotation mechanisms for this specific use case.
      • KaiserPro 5y ago
        > Documentation is rarely adequately maintained, yes, and the solution is to actually document. > wouldn't require documenting if they were just named properly I mean not really. Having decent names for things tells us what you are doing, but not why. > only used to describe exception situations Again, just imagine if that wasn't the case. Imagine people had the empathy to actually do a professional job? > The best way to document things is to name identifiers well, write functions that are well-composed and small enough to understand, stick to single-responsibility principles. No, thats the best way to code. The best way to document is to imagine you are a new developer to the code base, and any information they should know is where they need it. Like your code, you need to test your documentation. I know you don't _like_ documenting, but thats not the point. Its about being professional, just imagine if an engineer didn't _like_ doing certification of their stuff? they'd loose their license. Sure you could work it out later, but thats not the point. You are paid to be professional, not a magician.
  • TeMPOraL 5y ago
    > Put logic closest to where it needs to live (feature folders) Can you say more about this? I think I may have stumbled on a similar insight myself. In a side project (a roguelike game), I've been experimenting with a design that treats features as first-class, composable design units. Here is a list of the subfolder called game-features in the source tree: actions collision control death destructibility game-feature.lisp hearing kinematics log lore package.lisp rendering sight simulation transform An extract from the docstring of the entire game-feature package: "A Game Feature is responsible for providing components, events, event handlers, queries and other utilities implementing a given aspect of the game. It's primarily a organization tool for gameplay code. Each individual Game Feature is represented by a class inheriting from `SAAT/GF:GAME-FEATURE'. To make use of a Game Feature, an object of such class should be created, preferably in a system description (see `SAAT/DI'). This way, all rules of the game are determined by a collection of Game Features loaded in a given game. Game Features may depend on other Game Features; this is represented through dependencies of their classes." The project is still very much work-in-progress (procrastinating on HN doesn't leave me much time to work on it), and most of the above features are nowhere near completion, but I found the design to be mostly sound. Each game feature provides code that implements its own concerns, and exports various functions and data structures for other game features to use. This is an inversion of traditional design, and is more similar to the ECS pattern, except I bucket all conceptually related things in one place. ECS Components and Systems, utility code, event definitions, etc. that implement a single conceptual game aspect live in the same folder. Inter-feature dependencies are made explicit, and game "superstructure" is designed to allow GFs to wire themselves into appropriate places in the event loop, datastore, etc. - so in game startup code, I just declare which features I want to have enabled. (Each feature also gets its set of integration tests that use synthetic scenarios to verify a particular aspect of the game works as I want it to.) One negative side effect of this design is that the execution order of handlers for any given event is hard to determine from code. That's because, to have game features easily compose, GFs can request particular ordering themselves (e.g. "death" can demand its event handler to be executed after "destructibility" but before "log") - so at startup, I get an ordering preference graph that I reconcile and linearize (via topological sorting). I work around this and related issues by adding debug utilities - e.g. some extra code that can, after game startup, generate a PlantUML/GraphViz picture of all events, event handlers, and their ordering. (I apologize for a long comment, it's a bit of work I always wanted to talk about with someone, but never got around to. The source of the game isn't public right now because I'm afraid of airing my hot garbage code.)
  • thebackup 5y ago
    I read Clean Code in 2010 and trying out and applying some of the principles really helped to make my code more maintainable. Now over 10 years later I have come to realize that you cannot set up too many rules on how to structure and write code. It is like forcing all authors to apply the same writing style or all artists to draw their paintings with the exact same technique. With that analogy in mind, I think that one of the biggest contributors to messy code is having a lot of developers, all with different preferences, working in the same code base. Just imagine having 100 different writers trying to write a book, this is the challenge we are trying to address.
    • TheCoelacanth 5y ago
      I'm not sure that's really true. Any publication with 100 different writers almost certainly has some kind of style guide that they all have to follow.
  • bosswipe 5y ago
    Your name WET is kind of funny but it is usually refered to as the rule of 3, https://en.m.wikipedia.org/wiki/Rule_of_three_(computer_programming) https://en.m.wikipedia.org/wiki/Rule_of_three_(computer_prog...
  • Chris2048 5y ago
    > figure out the abstraction after you need something a 3rd time That's still too much of a "rule". Whenever I feel (or know) two functions are similar, the factors that determine if I should merge them: - I see significant benefit too doing so, usually the benefit of a utility that saves writing the same thing in the future, or debugging the same/similar code repeatedly. - How likely the code is to diverge. Sometimes I just mark things for de-duping, but leave it around a while to see if one of the functions change. - The function is big enough it cannot just be in-lined where it is called, and the benefit of de-duplication is not outweighed by added complexity to the call stack.
  • bengale 5y ago
    I’ve never heard the term WET before but that’s exactly what I do. The other key thing I think is not to over-engineer abstractions you don’t need yet. But to try and leave ‘seams’ where it’s obvious how to tease code about if you need to start building abstractions.
  • YeBanKo 5y ago
    > WET One of the most difficult to argue comments in code reviews: “let’s make it generic in case we need it some place else”. First of all, chances that we need it some place else aren’t exactly high, unless you are writing a library and code explicitly design to be shared. And even if such need arises, chances of getting it right generalizing from one example are slim. Regarding the book though, I have participated in one of the workshops with the author and he seemed to be in favor of WER and against “architecting” levels of abstraction before having concrete examples.
  • heisenbit 5y ago
    My experience interviewing recently a number of consultants with only a few years experience was the more they mumbled clean code the less they knew what they were doing.
• thrower123 5y ago
  Clean Code is fine. It's a little dated, as you would expect, and for the most part, everything of value in it has been assimilated into the best practices and osmotic ether that pervades software development now. It's effectively all the same stuff as you see in Refactoring or Code Complete or Pragmatic Programmer. I suspect a lot of backlash against it centers around Uncle Bob's less than progressive political and social stances in recent years.
  • commandlinefan 5y ago
    TFA really seems to be saying that there's no such thing as clean code, so don't even bother trying.
  • simias 5y ago
    I never read Clean Code and know nothing about its author so I'm willing to trust you on the first part, but the second paragraph is really uncalled for IMO. The article is long and gives precise examples of its issues with the book. Assuming an ulterior motive is unwarranted.
    • thrower123 5y ago
      I don't think it is uncalled for when there have been several instances of boycotts organized for that reason. Nobody is that upset about anodyne OOP design patterns
• raverbashing 5y ago
  Yeah I agree with the author, and I would go further, it's a nice list of reasons why Uncle Bob is insufferable. Because of stuff like this: > Martin's reasoning is rather that a Boolean argument means that a function does more than one thing, which it shouldn't. Really? Really? Not even for dependency injection? Or, you know, you should duplicate your function into two very similar things to have one with the flag and another one without. Oh but DRY. Sure. > . He says that an ideal function has zero arguments (but still no side effects??), and that a function with just three arguments is confusing and difficult to test Again, really? I find it funny who treats him as a guru. Or maybe that's the right way to treat him, like those self-help gurus with meaningless guidance and whishy-washy feel-good statements. > Every function in this program was just two, or three, or four lines long. Each was transparently obvious. Each told a story. And each led you to the next in a compelling order. Wow, illumination! Salvation! Right here! Until, of course you have to actually maintain this and has to chase down 3 or 4 levels of functions deep what is it that the code is actually doing. And think of function signature for every minor thing. And passing all the arguments you need (ignoring that "perfect functions have zero arguments" above - good luck with that) Again, it sounds like self-help BS and not much more than that.
  • Kototama 5y ago
    It's actually a good marketing trick. He can sell something slightly different and more "pure" and make promises on it and then sell books, trainings and merchandises. That's what the wellness industry do all the time.
  • ziml77 5y ago
    The boolean issue is probably the one that's caused me the most pain. That contradiction with DRY has actually had me go back and forth between repeating myself and using a flag, wasting a ton of time on something incredibly pointless to be thinking that hard about. I feel like the best thing for my career would have been to not read that book right when I started my first professional programing job.
    • vbezhenar 5y ago
      It might make sense to divide your function with boolean flag into two functions and extract common code into third private function. Or may be it'll make things ugly. I treat those books as something to show me how other people do things. I learn from it and I add it to my skill book. Then I'll apply it and see if I like it. If I don't like it in this particular case, I'll not apply it. IMO it's all about having insight into every possible solution. If you can implement something 10 different ways, you can choose the best one among them, but you have to learn those 10 different ways first.
• strict9 5y ago
  10 or so years ago when I first got into development I looked to people like Martin's for how I should write code. But I had more and more difficulty reconciling bizarrely optimistic patterns with reality. This from the article perfectly sums it up: >Martin says that functions should not be large enough to hold nested control structures (conditionals and loops); equivalently, they should not be indented to more than two levels. Back then as now I could not understand how one person can make such confident and unambiguous statements about business logic across the spectrum of use cases and applications. It's one thing to say how something should be written in ideal circumstances, it's another to essentially say code is spaghetti garbage because it doesn't precisely align to a very specific dogma.
  • joshribakoff 5y ago
    Can you provide a source where he said that? Or did he actually say something more like "thats when I consider refactoring it"? My recollection of the clean code book and Fowler books were very much “I think these are smells, but smells in the code are also fine” Note: Robert Martin and Martin Fowler are different people. Are you saying Fowler said this?
    • strict9 5y ago
      It's directly from the article, and Clean Code was one of the first books I purchased. Fixed the typo, thanks.
      • joshribakoff 5y ago
        The article is not written by Robert Martin, so that doesn’t necessarily establish he said that. You also implied Fowler said it. Thanks for clarifying. I believe Robert Martin did say this, but there was probably a preface from the book that didn’t make it into the article, so the quote in the article may be a bit out of context.
  • headbee 5y ago
    This is the point that I have the most trouble understanding in critiques of Fowler, Bob, and all writers who write about coding: in my reading, I had always assumed that they were writing about the perfect-world ideal that needs to be balanced with real-world situations. There's a certain level of bluster and over-confidence required in that type of technical writing that I understood to be a necessary evil in order to get points across. After all, a book full of qualifications will fail to inspire confidence in its own advice.
• rockbruno 5y ago
  One mistake I think people like the author make is treating these books as some sort of bible that you must follow to the letter. People who evangelised TDD were the worst offenders of this. "You HAVE to do it like this, it's what the book says!" You're not supposed to take it literally for every project, these are concepts that you need to adapt to your needs. In that sense I think the book still holds up.
  • deleted 5y ago
    [deleted]
  • jugg1es 5y ago
    But that's what some people are doing - they take this book as the programming bible.
    • rockbruno 5y ago
      Sure, but it doesn't mean the book itself is bad. It's that beginners should be aware that what's "right" differs from project to project.
    • lobstrosity420 5y ago
      I understand that the people that follow Clean Code religiously are annoying, but the author seems to be doing the same thing in reverse: because some advice is nuanced or doesn't apply all the time then we should stop recommending the book and forget it altogether.
      • cloverich 5y ago
        Its not just that it doesn't always apply. Its that the absracted rules are not useful as stand alone guides to developing code, although they are presented as such. Its the entire purpose of the book isn't it? The argument against this book isn't that books about code style and rules are bad. Its that this one is bad. And its often recommended as core reading material to new developers (several examples of that in this thread). I've read several code style / guide books over the last decade. This is one of the few I put down fairly early on because it just didn't seem very good.
• ziml77 5y ago
  I agree. Trying to apply the lessons in there leads to code that is more difficult to read and reason about. Making it "read like a book" and keeping functions short sound good on the surface but they lead to lines getting taken up entirely by function names and a nightmare of tracking call after call after call. It's been years since I've read the book and I'm still having trouble with the bad ideas from there because they're so well stuck with me that I feel like I'm doing things wrong if I don't follow the guidelines in there. Sometimes I'll actually write something in a sensible way, change it to the Clean Code way, and then revert it back to where it was when I realize my own code is confusing me when written like that. This isn't just a Robert C Martin issue. It's a cultural issue. People need to stop shaming others if their code doesn't align with Clean Code. People need to stop preaching from the book.
  • ffhhj 5y ago
    I make my code "read like a book" with a line comment for each algorithmic step inside a function, and adding line-ending comments to clarify. So functions are just containers of steps designed to reduce repetition, increase visibility, and minimize data passing and globals.
• jugg1es 5y ago
  Finally! I'm glad to hear I'm not the only one. I've gone against 'Clean Code' zealots that end up writing painfully warped abstractions in the effort to adhere to what is in this book. It's OK to duplicate code in places where the abstractions are far enough apart that the alternative is worse. I've had developers use the 'partial' feature in C# to meet Martin's length restrictions to the point where I have to look through 10-15 files to see the full class. The examples in this post are excellent examples of the flaws in Martin's absolutism.
  • ziml77 5y ago
    Seriously? That's an abuse of partial and just a way of following the rules without actually following them. That code must have been fun to navigate...
    • pdpi 5y ago
      Many years ago I worked on a project that had a hard “no hard coded values” rule, as requested by the customer. The team routinely wrote the equivalent to const char_a = “a”; And I couldn’t get my manager to understand why this was a problem.
      • jandrese 5y ago
        Clearly it is still a hardcoded value! It fails the requirement. Instead there should be a factory that loads a file that reads in the "a" to the variable, nested down under 6 layers of abstraction spread across a dozen files.
        • mkoryak 5y ago
          thats too enterprisey, at a startup you would write it like this: const charA = (false+"")[1];
          • bosswipe 5y ago
            That has three constants.
• nicklecompte 5y ago
  I don’t disagree with the overall message or choice of examples behind this post, but one paragraph stuck out to me: > Martin says that it should be possible to read a single source file from top to bottom as narrative, with the level of abstraction in each function descending as we read on, each function calling out to others further down. This is far from universally relevant. Many source files, I would even say most source files, cannot be neatly hierarchised in this way. The relevance is a fair criticism but most programs in most languages can in fact be hierarchized this way, with the small number of mutually interdependent code safely separated. Many functional languages actually enforce this. As an F# developer it can be very painful to read C# programs even though I often find C# files very elegant and readable: it just seems like a book, presented out of order, and without page numbers. Whereas an .fsproj file provides a robust reading order.
  • dmurray 5y ago
    > "with the level of abstraction in each function descending as we read on, each function calling out to others further down." ... > Many functional languages actually enforce this. Don't they enforce the opposite? In ML languages (I don't know F# but I thought it was an ML dialect), you can generally only call functions that were defined previously. Of course, having a clear hierarchy is nice whether it goes from most to least abstract, or the other way around, but I think Martin is recommending the opposite from what you are used to.
    • nicklecompte 5y ago
      Hmm, perhaps I am misreading this? Your understanding of ML languages is correct. I have always found “Uncle Bob” condescending and obnoxious so I can’t speak to the actual source material. I am putting more emphasis on the “reading top-to-bottom” aspect and less on the level of abstraction itself (might be why I’m misreading it). My understanding was that Bob sez a function shouldn’t call any “helper” functions until the helpers have been defined - if it did, you wouldn’t be able to “read” it. But with your comment, maybe he meant that you should define your lower-level functions as prototypes, implement the higher-level functions completely, then fill in the details for the lower functions at the bottom. Which is situationally useful but yeah, overkill as a hard rule. In ML and F# you can certainly call interfaces before providing an implementation, as long as you define the interface first. Whereas in C# you can define the interface last and call it all you want beforehand. This is what I find confusing, to the point of being bad practice in most cases. So even if I misread specifically what (the post said) Bob was saying, I think the overall idea is what Bob had in mind.
• rileymat2 5y ago
  It is interesting that he uses a fitnesse example. Years ago we started using fitnesse at a place I was working, and we needed something that was not included, I think it was being able to make a table of http basic auth tests/requests. The code base seems large and complex at first, but I was able to very quickly add this feature with minimal changes and was pretty confident it was correct. Also, I had little experience in Java at the time. All in all it was a pretty big success.
  • SketchySeaBeast 5y ago
    Fitnesse is Uncle Bob's baby so it makes sense to use that example, he can't get through a book without talking about it at length.
    • rileymat2 5y ago
      Interesting, is probably the wrong, word. I should say interesting to me, because I had a different experience with it. And it was not any sort of theoretical analysis, it was a feature I needed to get done.
• ItsMonkk 5y ago
  This is an interesting article because as I was reading Martin's suggestions I agreed with every single one of them. 5 lines of code per function is ideal. Non-nested whenever possible. Don't mix query/pure and commands/impure. Then I got to the code examples and they were dreadful. Those member variables should be readonly. Using Martin's suggestion with Functional Hexagonal Architecture would lead to beautiful code. I know because that's what I've been writing for the past 3 years.
• hcarvalhoalves 5y ago
  > But mixed into the chapter there are more questionable assertions. Martin says that Boolean flag arguments are bad practice, which I agree with, because an unadorned true or false in source code is opaque and unclear versus an explicit IS_SUITE or IS_NOT_SUITE... but Martin's reasoning is rather that a Boolean argument means that a function does more than one thing, which it shouldn't. I see how this can be polemic because most code is littered w/ flags, but I tend to agree that boolean flags can be an anti-pattern (even though it's apparently idiomatic in some languages). Usually the flag is there to introduce a branching condition (effectively breaking "a function should do one thing") but don't carry any semantic on it's own. I find the same can be achieved w/ polymorphism and/or pattern-matching, the benefit being now your behaviour is part of the data model (the first argument) which is easier to reason about, document, and extend to new cases (don't need to keep passing flags down the call chain). As anything, I don't think we can say "I recommend / don't recommend X book", all knowledge and experience is useful. Just use your judgment and don't treat programming books as a holy book.
  • lobstrosity420 5y ago
    > As anything, I don't think we can say "I recommend / don't recommend X book", all knowledge and experience is useful. Just use your judgment and don't treat programming books as a holy book. People don't want to go through the trouble of reading several opposing points of view and synthesize that using their own personal experience. They want to have a book tell them everything they need to do and follow that blindly, and if that ever bites them back then that book was clearly trash. This is the POV the article seems to be written from IMHO.
    • Izkata 5y ago
      Not even that, this book gets recommended to newbies who don't yet have the experience to read it critically like that.
  • Twisol 5y ago
    As far as the boolean flag argument goes, I've seen it justified in terms of data-oriented design, where you want to lift your data dependencies to the top level as much as possible. If a function branches on some argument, and further up the stack that argument is constant, maybe you didn't need that branch at all if only you could invoke the right logic directly. Notably, this argument has very little to do with readability. I do prefer consolidating data and extracting data dependencies -- I think it makes it easier to get a big-picture view, as in Brook's "Show me your spreadsheets" -- but this argument is rooted specifically in not making the machine do redundant work.
• ericbarrett 5y ago
  Another thing Martin advocates for is not putting your name in comments, e.g. "Fixed a bug here; there could still be problematic interactions with subsystem foo -- ericb". He says, "Source control systems are very good at remembering who added what, when." (p. 68, 2009 edition) Rubbish! Multiple times I've had to track down the original author of code that was auto-refactored, reformatted, changed locations, changed source control, etc. "git blame" and such are useless in these cases; it ends up being a game of Whodunit that involves hours of search, Slack pings, and what not. Just put your name in the comment, if it's documenting something substantial and is the result of your own research and struggle. And if you're in such a position, allow and encourage your colleagues to do this too.
  • ziml77 5y ago
    What is even the downside of adding a few extra characters to the end of a comment to show who wrote it? And has Martin ever even worked on large, non-greenfield projects? That's the only way I could see anyone professing such idealism.
    • jen20 5y ago
      > What is even the downside of adding a few extra characters to the end of a comment to show who wrote it? You're right - in fact we should do this for every line of code, so that we know of whom to ask questions! func main() { // jen20 fmt.Println("Hello World") // ziml77 } // jen20 What's the downside of adding a few extra characters!? Of course, this view is already available to people: `git blame` - and it's the same for comments, so there is no need. The exception is "notes to future self" during the development of a feature (to be removed before review), in which case the most useful place for them to appear is at the _start_ of the comment with a marker: // TODO(jen20): also implement function X for type Y Then they are easy to find...
      • ericbarrett 5y ago
        What you've shown is code clutter and reductio ad absurdum to what I wrote in the top-level comment. I am speaking of architectural comments, bug-fixes, and especially in service architecture where unusual and catastrophic interactions might happen (or have happened) with code that's not under your control.
• hashkb 5y ago
  Let's not throw the baby out with the bathwater. We can still measure how quickly new (average) developers become proficient, average team velocity over time, and a host of other metrics that tell us if we are increasing or decreasing the quality of our code over time. Ignoring it all because it's somewhat subjective is selfish and bad for your business. Leave off the word "clean" or whatever... DO have metrics and don't ignore them. You have people on your team that make it easier for the others, and people who take their "wins" at the expense of their teammates' productivity.
• deleted 5y ago
  [deleted]
• Yajirobe 5y ago
  > output arguments are to be avoided in favour of return values what is an output argument?
  • jacquesm 5y ago
    That's a C/C++ trick where a location to dump the output is presented as an argument to the function. This makes functions un-pure and leads to all kind of nastiness such as buffer overruns and such if you are not very careful. sprintf(buffer,"formatstring", args) 'buffer' is an output argument.
    • pjc50 5y ago
      Not only in C land; C# has "ref" (pass by reference, usually implying you want to overwrite it) and "out" (like ref but you _must_ set it in all code paths). Both are a bit of a code smell and you're nearly always better off with tuples. Unfortunately in C land for all sorts of important system APIs you have to use output arguments.
    • deleted 5y ago
      [deleted]
    • jlarocco 5y ago
      It's wrong to call output parameters a "C/C++ trick" because the concept really has nothing to do with C, C++, buffer overruns, purity, or "other nastiness". The idea is that the caller tells the function its calling where to store results, rather than returning the results as values. For example, Ada and Pascal both have 'out' parameters: https://stackoverflow.com/questions/3003480/the-use-of-in-out-in-ada#3004067 https://freepascal.org/docs-html/ref/refsu66.html#x182-20600014.4.3 http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-6-1.html Theoretically, other than different calling syntax, there's conceptually no difference between "out" parameters and returning values. In practice, though, many languages (C, C++, Java, Python, ...) support "out" parameters accidentally by passing references to non-constant objects, and that's where things get ugly.
  • deleted 5y ago
    [deleted]
• hprotagonist 5y ago
  "Promote I/O to management (where it can't do any damage)" is the actionably good thing i've taken from Brandon Rhoades' talk based on this: https://www.youtube.com/watch?v=DJtef410XaM https://www.youtube.com/watch?v=DJtef410XaM Living in a world where people regularly write single functions that: 1. loads data from a hardcoded string path of file location 2. does all the analysis inside the same loop that the file content iteration happens in and 3. plots the results ... that cleavage plane is a meaningfully good one. The rest of the ideas fall into "all things in moderation, including moderation", and can and should be special-cased judiciously as long as you know what you're doing. But oh god please can we stop writing _that_ function already.
• phibz 5y ago
  This is the first time I've heard of this book. I certainly agree some of these recommendations are way off the mark. One guideline I've always tried to keep in mind is that statistically speaking, the number of bugs in a function goes way up when the code exceeds a page or so in length. I try to keep that in mind. I still routinely write functions well over a page in length but I give them extra care when they do, lots of comments and I make sure there's a "narrative flow" to the logic.
  • rantwasp 5y ago
    4 line functions everywhere is insanity. yes, you should aim for short functions that do one thing, but in the real world readability and maintainability would suffer greatly if you fragment everything down to an arbitrarily small number.
  • sumtechguy 5y ago
    The big one to keep an eye on is cyclomatic complexity with respect to function length. Just 3 conditional statements in your code gives you no less than 8 ways through your code and it only goes up from there. All of these 'clean code' style systems have the same flaw. People follow them without understanding why the system was made. It is why you see companies put in ping pong tables, but no one uses them. They saw what someone else was doing and they were successful so they copy them. Not understanding why the ping pong table was there. They ignore the reason the chesterton's fence was built. Which is just as important if you are removing it. Clean code by itself is 'ok'. I personally am not very good at that particular style of coding. I do like that it makes things very nice to decompose into testing units. A downside to this style of coding is it can hide complexity with an even more complex framework. It seems to have a nasty side effect of smearing the code across dozens of functions/methods which is harder in some ways to get the 'big picture'. You can wander into a meeting and say 'my method has CC of 1' but the realty is that thing is called at the bottom of a for loop, inside of 2 other if conditions. But you 'pass' because your function is short.
  • tziki 5y ago
    Number of bugs per line also goes way up when the average length of functions goes below 5, and the effect in most studies is larger than the effect of too large functions.
• bena 5y ago
  The problem with Clean Code is also the problem with saying to ignore Clean Code. If you treat everything as a dogmatic rule on how to do things, you're going to have a bad time. Because, they're more like guidelines. If you try not to repeat yourself, you'll generally wind up with better code. If you try to make your methods short, you'll generally wind up with better code. However, if you abuse partial just to meet some arbitrary length requirement, then you haven't really understood the reason for the guideline.
  • darksaints 5y ago
    But the problem isn't so much because the book has a mix of good and bad recommendations. We as an evolutionary race have been pretty good at selectively filtering out bad recommendations over the long term. The problem is that Uncle Bob has a delusional cult following (that he deliberately cultivated), which takes everything he says at face value, and are willing to drown out any dissenting voices with a non-stop barrage of bullshit platitudes. There are plenty of ideas in Clean Code that are great, and there are plenty that are terrible...but the religiosity of adherence to it prevents of from separating the two.
• tuckerpo 5y ago
  Uncle "Literally who?" Bob claims you should separate your code into as many small functions spread across as many classes as you can and makes a living selling (proverbial) shovels. John Carmack says you should keep functions long and have the business logic all be encapsulated together for mental cohesion. Carmack makes a living writing software.
  • rantwasp 5y ago
    Uncle Bob makes a living selling snake oil. Which one should we listen to?
  • watwut 5y ago
    I work with long functions right now. It does not give mental cohesion. Instead, it makes it difficult to figure out what author intended to happen.
    • cloverich 5y ago
      Or perhaps the length of the function is orthogonal to the quality of the author's code. Make the function as long as necessary to be readable and maintainable by the people most likely to read and maintain it. But that's not a very sellable snippet, nor a rule that can be grokked in 5 minutes.
  • LorenPechtel 5y ago
    Short functions make it much harder for bugs to hide.
    • marcosdumay 5y ago
      Bugs favorite place to hide is in interfaces.
    • darksaints 5y ago
      Long functions make it much harder for bugs to hide. See what I did there?
  • 5y ago
• jeffreyrogers 5y ago
  Most of these types of books approach things from the wrong direction. Any recommendation should look at the way well designed, maintainable systems are actually written and draw their conclusions from there. Otherwise you allow too much theorizing to sneak in. Lots of good options to choose from and everyone will have their own pet projects, but something like SQLite is probably exemplary of what a small development team could aim for, Postgres or some sort of game engine would maybe be good for a larger example (maybe some of the big open source projects from major web companies would be better, I don't know). There are books that have done something like this[0], but they are a bit high level. There is room for something at a lower level. [0]: http://aosabook.org/en/index.html http://aosabook.org/en/index.html for example.
  • dsego 5y ago
    I would say Code Complete is one such book.
• aristofun 5y ago
  I’d say “Stop recommending Clean Code to noobs! It’s dangerous” Because Clean Code is really a good book once you have enough experience to understand when each idea works and when does not. And why. And noobs tend to over-engineer, so any book like CC or design patterns give them additional excuse and reason to over engineer and make a mess.
• theflyinghorse 5y ago
  Robert Martin and his aura always struck me as odd. In part because of how revered he always was at organizations I worked. Senior developers would use his work to end arguments, and many code reviews discussions would be judged by how closely they adhere to Clean Code. Of course reading Clean Code left me more confused than enlightened due precisely to what he presents as good examples of Code. The author of the article really does hit the nail on the head about Martin's code style - it's borderline unreadable a lot of times. Who the f. even is Robert Martin?! What has he built? As far as I am able to see he is famous and revered because he is famous and revered.
  • pydry 5y ago
    I think part of his appeal lies in his utter certainty that he is correct. This is also the problem with him.
  • keithnz 5y ago
    He ran a consultancy and knew how to pump out books into a world of programmers that wanted books I was around in the early 90s through to the early 2000s when a lot of the ideas came about slowly got morphed by consultants who were selling this stuff to companies as essentially "religion". The nuanced thoughts of a lot of the people who had most of the original core ideas is mostly lost. It's a tricky situation, at the core of things, there are some really good ideas, but the messaging by people like "uncle bob" seem to fail to communicate the mindset in a way that develops thinking programmers. Mainly because him, and people like Ron Jerfferies, really didn't actually build anything serious once they became consultants and started giving out all these edicts. If you watched them on forums/blogs at the time, they were really not that good. There were lots of people who were building real things and had great perspectives, but their nuanced perspectives were never really captured into books, and it would be hard to as it is more about the mentality of using ideas and principles and making good pragmatic choices and adapting things and not being limited by "rules" but about incorporating the essence of the ideas into your thinking processes. So many of those people walked away from a lot of those communities when it morphed into "Agile" and started being dominated by the consultants.
• jacquesm 5y ago
  Like everything else: it's fine in moderation. Newbies should practice clean code, everybody else gets to make their own decisions. Treating anything as dogma whether it is Clean Code, TDD, Agile or whatever is the flavor of madness of the day is going to lead to suboptimal outcomes. And they're also a great way to get rid of your most productive and knowledgeable team members. So apply with caution and care and you'll be fine.
• pjmlp 5y ago
  For me all this kind of stuff is only to sell books, conferences and consulting services, and a big headache when working in teams whose architects have bought too much into it.
• golergka 5y ago
  Great! While we're on it, can we retire the gang of four as well? I mean, the authors are obviously great software engineers, and the Patterns have helped to design, build, and most importantly read, a lot of software. But as we move forward, more and more of these goals can be achieved much more elegantly and sustainably with new languages and more functional approaches. Personally, I find re-teaching junior programmers, who are still trying to make everything into a class, very tiring.
• applepple 5y ago
  This article is garbage. The argument is basically like saying "famous scientist X was wrong about Y, let's stop doing science. Clearly there is no point to it." I cannot believe what I am reading here. My open source community knows exactly what good code looks like and we've delivered great products in very short timeframes repeatedly and often beating our own expectations. These kinds of articles make me feel like I must have discovered something revolutionary... But in reality I'm just following some very simple principles which were invented by other people several decades ago. Too many coders these days have been misled into all sorts of goofy trends. Most coders don't know how to code. The vast majority of the people who claim to be experts and who write books about it don't know what they're talking about. That's the real problem. The industry has been hijacked by people who simply aren't wise or clever enough to be sharing any kind of complex knowledge. There absolutely is such a thing as good code. I'm tired of hearing developers who have never read a single word of Alan Kay (the father of OOP) tell everyone else how bad OOP is and why FP is the answer. It's like watching someone drive a nail straight into their own hand and then complain to everyone that hammer and nails are not the right tool for attaching two pieces of wood together... That instead, the answer is clearly to tie them together with a small piece of string because nobody can get hurt that way. Just read the manual written by the inventor of the tool. Alan Kay said "The Big Idea is Messaging"... Yet almost none of the OOP code I read designs their components in such a way that they're "communicating" together... Instead, all the components try to use methods to micromanage each other's internal state... Passing around ridiculously complex instances to each other (clearly a whole object instance is not a message).
  • deleted 5y ago
    [deleted]
  • oriolid 5y ago
    > The argument is basically like saying "famous scientist X was wrong about Y, let's stop doing science. Clearly there is no point to it." In my opinion the argument is more "famous paper X by scientist Y was wrong, let's stop citing it". Except that Clean Code isn't science and doesn't pretend to be.
    • 5y ago
• sidcool 5y ago
  I am glad the author meant the book Clean Code and not the concept.
• devtul 5y ago
  I just bought the book, god damn it
  • gilbetron 5y ago
    It's an ok book to read and think about, but understand it is written by someone that hasn't really built a lot of great software, but rather is paid to consult and give out sage advice that is difficult to verify. Read with great skepticism, but don't feel bad if you decide not to read it at all.
• avinassh 5y ago
  I have found other good articles on the same topic, by Hillel Wayne author of Practical TLA+ Uncle Bob is ruining software - https://hillelwayne.com/post/10x/ https://hillelwayne.com/post/10x/ Uncle Bob and Silver Bullets - https://hillelwayne.com/post/uncle-bob/ https://hillelwayne.com/post/uncle-bob/
• deleted 5y ago
  [deleted]
• yoz-y 5y ago
  Articles like these make me feel better about never having read any of the 'how to code' books. Mainly substituting them by reading TheDailyWTF during the formative years.
• rglover 5y ago
  FWIW the clean code approach led me to this pattern which has allowed me to build some seriously complex systems in JS/Node: https://ponyfoo.com/articles/action-pattern-clean-obvious-testable-code https://ponyfoo.com/articles/action-pattern-clean-obvious-te.... I agree with the sentiment that you don't want to over abstract, but Bob doesn't suggest that (as far as I know). He suggests extract till you drop, meaning simplify your functions down to doing one thing and one thing only and then compose them together. Hands down, one of the best bits I learned from Bob was the "your code should read like well-written prose." That has enabled me to write some seriously easy to maintain code.
  • hackinthebochs 5y ago
    Absolutely this. Code should tell a story, the functions and objects you use are defined by the context of the story at that level of description. If you have to translate between low-level operations to reconstruct the high level behavior of some unit of work, you are missing some opportunities for useful abstractions. Coding at scale is about managing complexity. The best code is code you don't have to read because of well named functional boundaries. Natural language is our facility for managing complexity generally. It shouldn't be surprising that the two are mutually beneficial.
  • watwut 5y ago
    Yes, that one did a lot to me too. Especially when business logic gets complicated, I want to be able to skip parts by roughly reading meaning of the section without seeing details. One long stream of commands is ok to read, if you are author or already know what it should do. But otherwise it forces you to read too many irrelevant details on a way toward what you need.
  • MaxBarraclough 5y ago
    > your code should read like well-written prose That strikes me as being too vague to be of practical use. I suspect the worst programmers can convince themselves their code is akin to poetry, as bad programmers are almost by definition unable to tell the difference. (Thinking back to when I was learning programming, I'm sure that was true of me.) To be valuable, advice needs to be specific. If you see a pattern of a junior developer committing unacceptably poor quality code, I doubt it would be productive to tell them Try to make it read more like prose. Instead you'd give more concrete advice, such as choosing good variable names, or the SOLID principles, or judicious use of comments, or sensible indentation. Perhaps I'm missing something though. In what way was the code should read like well-written prose advice helpful to you?
• lovebes 5y ago
  woah shots fired
• watwut 5y ago
  I did actually found the SetupTeardownIncluder class author complains about really easier to read and interpret then the original version. I know from the start what the intention was and where I should go if I have issue with some part of the code. I dont even take issue with name. It makes it easy to find the class just by remembering what it should do. I dont really care all that much about verbs vs nouns. I want to be able to find the right place by having rough idea about what it should do. I want to get hint about class functionality from its name too.
• mabbo 5y ago
  I think one should always be careful not to throw out the baby with the bathwater[0]. Do I force myself to follow every single crazy rule in Clean Code? Heck no. Some of them I don't agree with. But do I find myself to be a better coder because of what I learned from Bob Martin? Heck yes. Most of the points he makes are insightful and I apply them daily in my job. Being a professional means learning from many sources and knowing that there's something to learn from each of them- and some things to ignore from each of them. It means trying the things the book recommends, and judging the results yourself. So I'm going to keep recommending Clean Code to new developers, in the hopes that they can learn the good bits, and learn to ignore the bad bits. Because so far, I haven't found a book with more good bits (from my perspective) and fewer bad bits (from my perspective). [0]https://en.wikipedia.org/wiki/Don%27t_throw_the_baby_out_with_the_bathwater https://en.wikipedia.org/wiki/Don%27t_throw_the_baby_out_wit...
  • dsego 5y ago
    I would recommend Code Complete 2 over Clean Code.
    • deleted 5y ago
      [deleted]
    • AnimalMuppet 5y ago
      Por que no los dos? Read them both. Take the good parts of each. Ignore the bad parts of each.
      • commandlinefan 5y ago
        That was my thought - neither one is SICP, you can finish reading both in a week.
        • occz 5y ago
          Perhaps I'm a slow reader, but is Code Complete 2 really a book you finish over a weekend? It's north of 850 pages long.
• AngeloAnolin 5y ago
  Pardon me for stating this but pundits of the Clean Code mantra I've worked with tend to be those consultants who bill enormous amount of money to ensure that they have lengthy contracts which is justified by wrapping codes in so much classes to abstract it and considered *CLEAN* and *TESTABLE*. They will preach the awesomeness of clean code in terms of maintainability, scalability and all those fancy enter-pricey terms that at the end of the day, brought not enough value to justify their cost.
• lisper 5y ago
  So many coding recommendations trip up when they fail to take into account Ron's First Law: all extreme positions are wrong. Functions that are too long are bad, but functions that are too short are equally bad. 2-4 lines? Good grief! That's not even enough for a single properly formatted if-then-else! IMHO it's only when you can't see the top and bottom of a function on the screen at the same time that you should start to worry.
• incrudible 5y ago
  My biggest gripe: Functions shouldn't be short, they should be of appropriate size. They should contain all the logic that isn't supposed to be exposed to the outside for someone else to call. If that means your function is 3000 lines long, so be it. Realize that your whole program is effectively one big function and you achieve nothing by scattering its guts out into individual sub-functions just to make the pieces smaller. If something is too convoluted and does too much, or has too much redundancy, you'll know, because it'll cause problems. It'll bother you. You shouldn't pre-empt this case by just writing small functions by default. That'll just cause its own problems.
  • cush 5y ago
    The problem is there's no way to adequately test a 3000 line function.
• brundolf 5y ago
  > This is done as part of an overall lesson in the virtue of inventing a new domain-specific testing language for your tests. I was left so confused by this suggestion. I would use exactly the same code to demonstrate exactly the opposite lesson. Don't do this! This example (code is in the article) was very telling of the book author's core philosophy. Best I can tell, the OOP movement of the 2000s (I wasn't a professional in 2008, though I was learning Java at the time) was at its heart rooted in the idea that abstractions are nearly always a win; the very idealistic perspective that anything you can possibly give a name to, should be given a name. That programmers down the line will thank you for handing them a named entity instead of perhaps even a single line of underlying code. This philosophy greatly over-estimates the value, and greatly under-estimates the cost, of idea-creation. I don't just write some code, I create an idea, and then I write a bit of code as implementation details for it. This is a very tantalizing vision of development: all messy details are hidden away, what we're left with is a beautiful constellation of ideas in their purest form. The problem is that when someone else has to try and make sense of your code, they first have to internalize all of your ideas, instead of just reading the code itself which may be calling out to something they already understand. It is the opposite of self-documenting code: it's code that requires its own glossary in addition to the usual documentation. "wayTooCold()" may read more naturally to the person who wrote it, but there's a fallacy where they assume that that also applies to other minds that come along and read it later. Establishing a whole new concept with its own terminology in your code is costly. It has to be done with great care and only when absolutely necessary, and then documented thoroughly. I think as an industry we have more awareness of this nowadays. We don't just make UML diagrams and kick them across the fence for all those mundane "implementation details" to be written.
  • cush 5y ago
    This thread is full of people saying what's wrong with the book without posing alternatives. I get that it's dogmatic, but do people seriously take it as gospel? I'd read it along with other things. Parts are great and others are not. It's not terrible.
• oneepic 5y ago
  I have the same complaint with Code Complete. I read bits in college and I'm not sure I follow most of its advice today (i.e. putting constants on the left side of a comparison). However, the book also presents the psych study about people not remembering more than 7 (+/- 2) things at a time (therefore you should simplify your code so readers don't have to keep track of too much stuff) and it stuck with me. I must be one of the people with only 5 available slots in their brain... (edited for clarity)
  • dsego 5y ago
    > putting constants on the left side of a comparison Yoda conditions? I hate those, they are difficult to read. Yes they are useful for languages which allow assignments in conditionals, but even then it's not really worth it. It's a very novice mistake to make. For me equality rarely appears in conditionals, it's either a numeric comparison or checking for existence.
  • tgv 5y ago
    > 7 (+/- 2) That study was done for specific stimuli (words, digits), and doesn't generalize to e.g. statements. There are studies that show that rate of presentation, complexity, and processing load have an effect. However, STM capacity is obviously limited, so it's good to keep that in mind when you're worried about readability. And I think it's also safe to assume that expert programmers can "chunk" more than novices, and have a lower processing load.
• tpoacher 5y ago
  Welcome to another episode of "X, as per my definition of X, is bad - Let's talk about Y, which is another definition of X, but not the one I disagree with".
• Communitivity 5y ago
  For me Clean Code is not about slavishly adhering to the rules therein, but about guidelines to help make your code better if you follow them, in most circumstances. On his blog Bob Martin himself says about livable code vs pristinely clean code: "Does this rule apply to code? It absolutely does! When I write code I fight very hard to keep it clean. But there are also little places where I break the rules specifically because those breakages create affordances for transient issues." I've found the Clean Code guidelines very useful. Your team's mileage may very. As always: Use what works, toss the rest, give back where you can. For more about this see: * Bob Martin's blog post 'Too Clean' - https://blog.cleancoder.com/uncle-bob/2018/08/13/TooClean.html https://blog.cleancoder.com/uncle-bob/2018/08/13/TooClean.ht... * Livable Code by Sarah Mei - https://www.youtube.com/watch?v=8_UoDmJi7U8 https://www.youtube.com/watch?v=8_UoDmJi7U8
• hyko 5y ago
  I don’t understand the amount of hate that Clean Code gets these days…it’s a relatively straightforward set of principles that can help you create a software system maintainable by humans for a very long time. Of course it’s not an engineering utopia, there’s no such thing. I get the impression that it’s about the messengers and not the messages, and that people have had horrible learning experiences that have calcified into resistance to do with anything clean. But valuable insights are being lost, and they will have to be re-learned in a new guise at a later date.
  • mywittyname 5y ago
    Development trends are cyclical and even the most sound principle has an exception. Even if something is good advice 99% of the time, it will eventually be criticized with that 1% of the time being used as a counter.
  • travisjungroth 5y ago
    TFA makes pretty good arguments.
• honkycat 5y ago
  Honestly Clean Code probably isn't worth recommending anymore. We've taken the good bits and absorbed it into best practice. I think it has been usurped by books like "Software Engineering at Google" and "Building Secure and Reliable Systems". I don't believe in being prescriptive to anyone about how they write their code, because I think people have different preferences and forcing someone to write small functions when they tend to write large functions well is a unique form of torture. Just leave people alone and let them do their job! I don't think it is the perfect solution, but a lot of people assert "we can't do better, no point in trying, just write whatever you feel like" and I think that is a degenerate attitude. We CAN find better ways to construct and organize our code, and I don't think we should stop trying because people don't want to update their pull requests.
  • randompwd 5y ago
    Software Engineering at Google (for Google, by Google, detailing issues which are issues mainly at Google) [You're not Google]
    • honkycat 5y ago
      I've heard this before, and I agree, but don't let the name put you off. I agree that designing and iterating for google scale is a bad idea, but there is a lot in that book that is applicable to all software teams.
• shmiga 5y ago
  I was skipping those ugly Java code examples while reading and the book made sense.
• SethMurphy 5y ago
  'Clean Code' is a style, not all practices are best. I feel that a good software team understands each other's styles, therefore making it easier to read others code within the context of a style. However, when people disagree on code style it has a way of creating cliques within teams, so sometimes it's just easier to pick a style that is well documented already and be done with mainly petty disagreements. Clean code fits the definition of well documented and is a lazy way of defining a team wide style.
• onehair 5y ago
  1. Clean Code is not a fixed destination to which you'll ever arrive. It's a way of life. 2. We might not use the same methods to write clean code. But when you see clean code, you know it is clean. 3. Some traits clean code can have - When you read the function name, you understand what the function does - When you read the content of a function, you can understand what it is about without reading line by line. - When you try to refactor clean code, you find yourself sometimes ending up only changing one cog in the whole system. 0. Real clean code does not exist.
• p0nce 5y ago
  Disagree. There are zillions of worse books than Clean Code to forget first.
• valbaca 5y ago
  Here's my rant on Code Complete and Clean Code: I find that these two books are in many recommended lists, but I found them entirely unforgettable, entirely too long, and without any "meat." So much of the advice given is trivial things you'll just figure out in the first few months of coding professionally. Code for more than a week and you'll figure out how to name classes, how to use variables, how scope works, etc. The code examples are only in C++, Java, and Visual Basic (ha!). Completely ignoring non-OO and dynamic languages. Some of the advice is just bad (like prefixing global variables with g_) or incredibly outdated (like, "avoid goto"? Thanks 1968!). Work on a single software project, or any problem ever, and you'll know that you need to define the problem first. It's not exactly sage advice. These are cherry-picked examples, but overall Code Complete manages to be too large, go into too specific detail in some areas, while giving vague advice in others. All books are written in a time and a few become timeless. Software books have an especially short half-life. I think Code Complete was a book Software Engineering needed in 2004, but has since dropped in value. I will say, that Code Complete does have utility as a way to prop up your monitor for increased ergonomics, which is something you should never ignore. I have similar issues with Clean Code. One is better off just googling "SOLID Principles" and then just programming using small interfaces more often and use fewer subclasses. A better alternative is (from above) The Pragmatic Programmer (2019), a good style guide, and/or get your code reviewed by literally anyone.
• pelario 5y ago
  I'm surprised by the amount of detractors. We know from history that any book with advice should not be taken too literal. Reading the comments here, it feels almost like I read a different book (about 10 years ago).
  • dsego 5y ago
    Read it again critically. Maybe you will see it differently, I know I did when I read it a second time after a few more years of experience.
• HelloNurse 5y ago
  There's a word, in other comments, that I expected to find: zealots. Zealots aren't sufficiently critical, and they don't want to think for themselves; a reasonable person should be able to, and a professional should be constantly itching to, step back, look at code, and decide whether some refactoring or rewriting is an improvement, taking a book like Clean Code as a source of general principles and good examples, not of rules. All the "bad" examples discussed in the article are rather context dependent, representing uninspired examples or extreme tastes in the book rather than bad or obsolete ideas. Shredding medium length meaningful operations into many very small and quite ad hoc functions can reduce redundancy at the expense of readability, which might or might not be an improvement; a little DSL that looks silly if used in a couple of test cases can be readable and efficient if more extensive usage makes it familiar; a function with boolean arguments can be an accretion of special cases, mature for refactoring or a respectable way to organize otherwise repetitive code.
• hackinthebochs 5y ago
  There's a lot of bad advice being tossed around in this thread. If you are worried about having to jump through multiple files to understand what some code is doing, you should consider that your naming conventions are the problem, not the fact that code is hidden behind functional boundaries. Coding at scale is about managing complexity. The best code is code you don't have to read because of well named functional boundaries. Without these functional boundaries, you have to understand how every line of a function works, and then mentally model the entire graph of interactions at once, because of the potential for interactions between lines within a functional boundary. The complexity (sum total of possible interactions) grows as the number of lines within a functional boundary grows. The cognitive load to understand code grows as the number of possible interactions grow. Keeping methods short and hiding behavior behind well named functional boundaries is how you manage complexity in code. The idea of code telling a story is that a unit of work should explain what it does through its use of well named variables, function/object names, and how data flows between function/objects. If you have to dig into the details of a function to understand what it does, you have failed to sufficiently explain what the function does through its naming and set of arguments.
  • jghn 5y ago
    I have found this to be one of those A or B developer personas that are hard for someone to change, and causes much disagreement. I personally agree 100%, but have known other people who couldn't disagree more, it is what it is. I've always felt it had a strong correlation to top-down vs bottom-up thinkers in terms of software design. The top-down folks tend to agree with your stance and the bottom-up group do not. If you're naturally going to want to understand all of the nitty gritty details you want to be able to wrap your head around those as quickly as possible. If you're willing to think in terms of the abstractions you want to remove as many of those details from sight as possible to reduce visual noise.
    • anm89 5y ago
      I never thought of things this way but it is a useful perspective.
    • 5y ago
• jammycakes 5y ago
  The big problem that I have with Clean Code -- and with its sequel, Clean Architecture -- is that for its most zealous proponents, it has ceased to be a means to an end and has instead become an end in itself. So they'll justify their approach by citing one or other of the SOLID principles, but they won't explain what benefit that particular SOLID principle is going to offer them in that particular case. The point that I make about patterns and practices in programming is that they need to justify their existence in terms of value that they provide to the end user, to the customer, or to the business. If they can't provide clear evidence that they actually provide those benefits, or if they only provide benefits that the business isn't asking for, then they're just wasting time and money. One example that Uncle Bob Martin hammers home a lot is separation of concerns. Separation of concerns can make your code a lot easier to read and maintain if it's done right -- unit testing is one good example here. But when it ceases to be a means to an end and becomes an end in itself, or when it tries to solve problems that the business isn't asking for, it degenerates into speculative generality. That's why you'll find project after project after project after project after project with cumbersome and obstructive data access layers just because you "might" want to swap out your database for some unknown mystery alternative some day.
  • cerved 5y ago
    I whole-heartedly agree with basically everything but feel compelled to point out that it's extremely hard to predict future needs. Nobody thinks their house is going to burn down until it does. Also, DALs are IMHO best practice for anything but the most rudimentary and not solely -- or even mainly -- for facilitating switching database.
  • cush 5y ago
    You should have data access layers if you're working on any decently sizable app.
• flipgimble 5y ago
  I never recommended Clean Code, but I've become a strong advocate against it on teams that I lead after reading opinions by Bob Martin such as this one: https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.... That whole article reads as someone who is stuck in their old ways and inflexible, then given their large soapbox tries to justify their discomfort and frustration. I consider Swift, Kotlin (and Rust) to be one of the most important language evolutions that dramatically improved software quality on the projects I've worked on. I've seen so many real world counter-examples to arguments made in that article and his other blog posts that I'm puzzled why this guy has such a large and devoted following.
  • wildermuthn 5y ago
    Actually, I found the post you linked to fairly logical. He’s saying that humans are inherently lazy, and that a language that gives us the option between being diligent (strong types) or being reckless (opt-out of strong types) will lead to the worst form of recklessness: opting out while not writing tests, giving the misimpression of safety. His point is that you can’t practically force programmers to be diligent through safety features of a language itself, since edge-cases require escape hatches from those safety features, and those safety hatches will be exploited by our natural tendency to avoid “punishment”. I’m not sure I agree with his point, but I don’t find it an unreasonable position. I’d be curious if Rust has escape hatches that are easily and often abused. My favorite example here, and a counterpoint to Bob, is Reacts’s dangerously-unsafe-html attribute. I haven’t seen it in years (to the point where I can’t recall the exact naming), and perhaps it was removed at some point. But it made the escape hatch really painful to use. And so the pain of using the escape hatch made it less painful to actually write React in the right manner. Coming from Angular, I think I struggled at first with thinking I had to write some dangerous html, but over time I forgot the choice of writing poor React code even existed. So I guess I disagree with Bob’s post here. It is possible to have safety features in languages that are less painful than the escape-hatches from those safety features. And no suite of tests will ever be as powerful as those built-in safety features.
    • flipgimble 5y ago
• markus_zhang 5y ago
  Maybe there is no such thing as clean code by following a set of rules. I know the author of the book never advocateshis book as a "bible" but it does give the reader such feeling. There is only years, decades of deep experience into certain domains (e.g. game rendering engine programming, or, Customer Relationship backends), extra hours reading proved high quality code, countless times of reflection on existing code (that also means extra hours reviewing existing code) based on the reading and a strong will to improve them, not based on some set of rules, but based on common sense on programming and many trials of re-writing the code into another form. I think ultimately it goes down to something similar to 10,000-hour rule: We need to put down a lot of time in X, and not only that, we also need to challenge ourselves for every step.
• grouphugs 5y ago
  it's probably time to stop recommending alt-right and fascist products, but you're all literally nazis, and you're going to die like ones
• aazaa 5y ago
  > First, the class name, SetupTeardownIncluder, is dreadful. It is, at least, a noun phrase, as all class names should be. But it's a nouned verb phrase, the strangled kind of class name you invariably get when you're working in strictly object-oriented code, where everything has to be a class, but sometimes the thing you really need is just one simple gosh-danged function. Moving from Java as my only language to JavaScript and Rust, this point was driven home in spades. A programming language can be dysfunctional, causing its users to implement harmful practices. SetupDeardownIncluder is a good example of the kind of code you get when there are no free-standing functions. It's also one path on the slippery slope to FactoryFactoryManager code. The main problem is that the intent of the code isn't even clear. Compare it with something you might write in Rust: fn render(page_data: &PageData) -> String { // render the page } If you saw that function at the top line of file, or if you saw render.rs in a directory listing, you'd have a pretty good idea of what's going on before you even dug into the code. Just randomly searching the Fitness repo, there's this: // Copyright (C) 2003,2004,2005 by Object Mentor, Inc. All rights reserved. // Released under the terms of the GNU General Public License version 2 or later. package fitnesse.html; public class HtmlPageFactory { public HtmlPage newPage() { return new HtmlPage(); } public String toString() { return getClass().getName(); } } https://github.com/unclebob/fitnesse/blob/3bec390e6f8e9e341149b7d060551a92b93d3154/src/fitnesse/html/HtmlPageFactory.java https://github.com/unclebob/fitnesse/blob/3bec390e6f8e9e3411... Really, how does this file even justify its existence? Its a subsidy courtesy of language design decisions made a long time ago.
• lamontcg 5y ago
  I recently read this cover to cover and left a negative review on Amazon. I'm happy to see I'm not the only one, and this goes into it in a whole lot more detail. The author seems like they took a set of rules that are good for breaking beginning programmers bad habits and then applied them into the extreme. There's a whole lot of rules which aren't bad up until you try to apply them like laws of gravity that must always be followed. Breaking up big clunky methods that do way too much is great for readability, right up until you're spraying one line helper methods all over your classes and making them harder to read because now you're inventing your own domain specific language everyone has to learn (often with the wrong abstractions which get extended through the years and wind up needing a massive refactoring down the road which would have been simpler with fewer methods and abstractions involved at the start). A whole lot of my job is taking classes, un-DRY'ing them completely so there's duplication all over the place, then extracting the right (or at least more correct) abstractions to make the whole thing simple and readable and tight.
• goto11 5y ago
  The problem is not really with this book IMHO. Most of its advice and guidelines are perfectly sensible, at least for its intended domain. The problem is people applying principles dogmatically without seeing the larger picture or considering the context purpose of the rules in the first place. This book or any book cannot be blamed for people applying the advice blindly. But it is a pervasive problem in the industry. It runs much deeper than any particular book. I suspect it has something to do with how CS education typically happen, but I'm not sure.
• asimpletune 5y ago
  I'd like to say that software engineering is a lot like playing jazz. It's really hard for the beginner to know where to start, and there're also endless sources for the "right" way to do things. In truth however, like playing jazz, the only thing that really matters is results, and even those can be subjective. You can learn and practice scales all day long, but that doesn't really tell you how to make music. I developed a style of software engineering that works really well for me. It's fast, accurate, and naturally extensible and easily refactorable. However, for various reasons, I've never been able to explain it junior (or even senior) engineers, when asked about why I code a certain way. At a certain point, it's not the material that matters, but the audience's ability to really get what's at the heart of the lesson. Technically, you could say something that's indisputable accurate, like, "there're only 12 notes in an (western) octave, and you just mix them until they sound good", but that's obviously true to a degree that's fundamentally unhelpful. At the same time, you could say "A good way to think about how to use a scale is to focus less on the notes that you play and more on the ones you don't". This is better advice but it may altogether be unhelpful, because it doesn't really yet strike at the true heart of what holds people back. So at a certain point, I don't really know if anyone can be taught something as fundamentally "artful" (I.e. a hard thing largely consisting of innumerable decisions that are larger matters of taste - which is a word that should not be confused with mere "opinion") as software engineering or jazz music. This is because teaching alone is just not enough. At a certain point people just have to learn for themselves, and obviously the material that's out there is helpful, but I'm not sure if anything can ever be explained so well as to remove the need for the student at a certain point to simply "feel" what sounding good sounds like, or what good software engineering feels like. I'll add one last thing. Going back to what I was saying about not being able to explain to "junior (or even senior)" engineers. Were the same "lesson" to happen with someone who is very, very advanced, like a seasoned principal engineer who's built and delivered many things, time and time again, across many different engineering organizations and different technologies - someone like a jazz music great for example. Anything I would have to say on my approach to such a software engineer would be treated as obvious and boring, and they'd probably much rather talk about something else. I don't say this because I mean to imply that whatever I would have to say is wrong or incorrect, but rather at a certain level of advancement, you forget everything that you know and don't remember what it took to get there. There are a few who have a specific passion for teaching, but that's orthogonal to the subject. I think it was Bill Evans who said something like "it takes years of study and practice to learn theory and technique, but it takes still a lifetime to forget it all". When you play like you've forgotten it all, that is when you achieve that certain sound in jazz music. Parenthetically, I'll add that doesn't mean you can't sound good being less advanced, but there's a certain sound that I'm trying to tie together with this metaphor that's parallel to great software engineering from knowledge, practice, and then the experience to forget it all and simply do. I think that's fundamentally what's at the heart of the matter, not that it takes anyone any closer to getting there. You just have to do it, because we don't really know how to teach how to do really hard things in a way that produces reproducible results.
• ptx 5y ago
  > Why are we using both int[] and ArrayList<Integer>? (Answer: because replacing the int[] with a second ArrayList<Integer> causes an out-of-bounds exception.) Isn't it because one is pre-allocated with a known size of n and the other is grown dynamically? > And what of thread safety? Indeed. If he had written the prime number class like the earlier example, with public static methods creating a new instance for each call and all the other methods being private instance methods, this wouldn't be an issue.
• slver 5y ago
  How about we throw Clean Architecture in this while we're at it. And also realize that the only rule in SOLID that isn't defined subjectively or partially is the "L".
• pixel_tracing 5y ago
  I worked at a large billion dollar company in the Bay Area (who is in the health space) and they religiously followed Clean Code. Their main architect was such a zealot for it. My problem is not with the book and author itself but the seniority that peddles this as some gospel to the more junior engineers. Clean code is not end all be all. Be your own person and develop WHAT IS RIGHT FOR YOUR ORG not peddle some book as gospel So glad I work at a company now where we actually THINK on the right abstractions now and not peddle some book
• auraham 5y ago
  I am interested in reading books about software development and best practices like Clean Code and The Pragmatic Programmer [0]. I have coded for about eight years, but I would like to do it better. I would like to know your opinion about [0], since Clean Code has been significantly criticized. [0] https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/ https://pragprog.com/titles/tpp20/the-pragmatic-programmer-2...
• Regic 5y ago
  I think the book is still useful with all it's flaws, mainly because "overengineering code" is like exercising too much: sure, it happens to some and can be a big issue, but for the vast majority of people it's the opposite that is the problem.
• phendrenad2 5y ago
  Sad to see the top comments are "Yes clean code leads to bad code" and not "TOO MUCH clean code leads to bad code". Excluded middle much?
• grammarnazzzi 5y ago
  TLDR: Author recommends "A Philosophy of Software Design" over "Clean Code"
• senderista 5y ago
  What well-regarded codebases has this author written, so you can see his principles in action? OTOH, if you’re wondering about the quality of John Ousterhout’s advice in _A Philosophy of Software Design_, you can just read the Tcl source.
  • roryokane 5y ago
    The article quotes a code sample from FitNesse – the author has apparently maintained that codebase since then. You can check out the code for the current version at https://github.com/unclebob/fitnesse https://github.com/unclebob/fitnesse, or browse the code in a Monaco editor using https://github1s.com/unclebob/fitnesse/blob/HEAD/src/ https://github1s.com/unclebob/fitnesse/blob/HEAD/src/. (I have no idea if that code is “well-regarded”, but as you wrote, you can read it for yourself.)
• asdff 5y ago
  Why is it that software engineering is so against comments? I know nothing of clean code. When I read the link, I assumed that clean code meant very simple and well commented code. I hit cmd+f # and nothing came up. Not one comment saying "this function is an example of this" or "note the use of this line here, it does this" etc, on a blog no less where you'd expect to see these things. The type of stuff I put in my own code, even the code that only I read, because in two weeks I'm going to forget everything unless I write full sentences to paragraph comments, and spend way more time trying to get back in the zone than the time it took me to write those super descriptive comments in the first place. I hate looking at other peoples scripts because, once again, they never write comments. Practically ever. What they do write is often entirely useless to the point where they shouldn't have even bothered writing those two words or whatever. Most people's code is just keyboard diarrhea of syntax and regex and patterns that you can't exactly google for, assuming whoever is looking at the code has the exact same knowledge base as you, and knows everything that you've put down into the script. Maybe it's a side effect of CS major training, where you don't write comments on your homework because the grader is going to know what is happening. Stop doing that with your code and actually make a write up to save others (and often yourself) mountains of time and effort.
  • Flex247A 5y ago
    The code in the website is written in Java, not Python ...
  • gary_0 5y ago
    > Why is it that software engineering is so against comments? Good question. Funny thing is, I worked for a company that mandated that every method be documented, which gets you a whole bunch of "The method GetThing(name) gets a Thing, and the argument 'name' is the name of the Thing". Plus 4 lines of Doxygen boilerplate. Oof. Of course, I've seen my share of uncommented, unreadable code. And also code with some scattered comments that have become so mangled over 10 years of careless maintenance and haphazard copy-pasting that their existence is detrimental. Many of the comments I come across that might be useful are incoherent ungrammatical ramblings. In large projects, often some of the engineers aren't native English speakers. My point being that writing consistently useful comments (and readable, properly organized code) is hard. Very, very hard. It requires written communication skills that only a small percentage of engineers (or even humans in general) are capable of. And the demand for software engineers is too high to filter out people who aren't great at writing. So I guess many people just try to work around the problem instead.
• deleted 5y ago
  [deleted]
• AtNightWeCode 5y ago
  I often hear that people should read Clean Code and that it is necessary in large projects. I would say that there is no direct correlation between how large and complex the business logic is and the difficulty of understanding and maintaining the code. I have seen small simple applications that are not maintainable because people have followed SOLID to the extreme.
• joaopbnogueira 5y ago
  Clean Code is not a blind religion, Uncle Bob is trying to make a point with the concepts behind the book and teaching you to consider/question if you're falling into bad code traps. This book was written to make developers think and consider their choices, not a script for good code.
• alea_iacta_est 5y ago
  It's probably time to stop recommending OOP completely at this point if you want to fix those issues.
• dreyfan 5y ago
  Can we also ditch the infatuation microservices while we’re at it? They primarily serve as a revenue generation scheme for cloud providers.
• bedobi 5y ago
  A lot of Robert C Martins pieces are just variations on his strong belief that ill-defined concepts like "craftsmanship" and "clean code" (which are basically just whatever his opinions are on any given day) is how to reduce defects and increase quality, not built-in safety and better tools, and if you think built-in safety and better tools are desirable, you're not a Real Programmer (tm). I'm not the only one who is skeptical of this toxic, holier-than-thou and dangerous attitude. Removing braces from if statements is a great example of another dangerous thing he advocates for no justifiable reason https://softwareengineering.stackexchange.com/questions/3202 https://softwareengineering.stackexchange.com/questions/3202... Which caused the big OSX/iOS SSL bug in 2014, see https://www.imperialviolet.org/2014/02/22/applebug.html https://www.imperialviolet.org/2014/02/22/applebug.html This link and thread on hackernews is good too https://news.ycombinator.com/item?id=15440848 https://news.ycombinator.com/item?id=15440848 >The current state of software safety discussion resembles the state of medical safety discussion 2, 3 decades ago (yeah, software is really really behind time). > >Back then, too, the thoughts on medical safety also were divided into 2 schools: the professionalism and the process oriented. The former school argues more or less what Uncle Bob argues: blame the damned and * who made the mistakes; be more careful, damn it. > >But of course, that stupidity fell out of favor. After all, when mistakes kill, people are serious about it. After a while, serious people realize that blaming and clamoring for care backfires big time. That's when they applied, you know, science and statistic to safety. > >So, tools are upgraded: better color coded medicine boxes, for example, or checklists in surgery. But it's more. They figured out what trainings and processes provide high impacts and do them rigorously. Nurses are taught (I am not kidding you) how to question doctors when weird things happen; identity verification (ever notice why nurses ask your birthday like a thousand times a day?) got extremely serious; etc. > >My take: give it a few more years, and software, too, probably will follow the same path. We needs more data, though.
  • CRConrad 5y ago
    Weird: > Page Not Found > This question was removed from Software Engineering Stack Exchange for reasons of moderation.
• sidlls 5y ago
  It's also probably time to stop recommending TDD, object-oriented programming, and a host of other anti-patterns in software development, and get serious about treating it like a real engineering profession instead of a circus of personality- and company-driven paradigms.
• chris_wot 5y ago
  One of the biggest issues I have found is that I can sometimes not easily create a test for code that I have modified because it is part of a larger class (I'm coding in C++). This normally happens when I cannot extract the function out of the class and it relies on internal state, and the class is not already being tested. Love to know if there is an easy way of doing this!
• DenverCode 5y ago
  I actually just purchased Clean Code this morning - this should be interesting.
• pentaphobe 5y ago
  Somewhat relatedly (covers some very similar concerns and IIRC even references "Clean Code"), Brian Wills has a few good videos https://www.youtube.com/watch?v=QM1iUe6IofM https://www.youtube.com/watch?v=QM1iUe6IofM https://www.youtube.com/watch?v=IRTfhkiAqPw https://www.youtube.com/watch?v=IRTfhkiAqPw
• jorgBaller 5y ago
  clean code is a c-level/exec/sales term. No one who actually writes code truly believes in clean code.
• iovrthoughtthis 5y ago
  totally agree with the author about the code examples and the disparity between them and the text. if it weren’t in a published book id have though i were being trolled.
• deleted 5y ago
  [deleted]
• deleted 5y ago
  [deleted]
• kodeninja 5y ago
  Related to the topic, would folks here recommend some OSS codebases that they've found be a pleasure to read/understand? For balance, perhaps in both statically and dynamically typed languages? Thank you!
• throwaway2037 5y ago
  I know that I'm late to this party, but what would Clean Coders think about algorithm heavy weight code like "TimSort.java"[1]? (This is the Java port of the famous Python stable sort.) Since Java doesn't have mutable references (pointers) or allow multiple return values, it gets very tricky to manage all the local variables across different functional scopes. I guess you could put all your locals into a struct/POJO, and then pass it around to endless tiny functions. (Honestly, the Java regex library basically does this... sucessfully.) Somehow, I feel it would be objectively worse if this algo code were split into endless 1/5/10 line functions! (Yes yes, that is an _opinion_... not a fact!) Come to think of it, is the original C code for Python's timsort equally non-Clean Code-ish?[2] Probably not! [1] https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/src/java.base/share/classes/java/util/TimSort.java https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/s... [2] https://github.com/python/cpython/blob/main/Objects/listobject.c https://github.com/python/cpython/blob/main/Objects/listobje...
• razorfen 5y ago
  I don't completely disagree, but his point about the irrelevance of SOLID, OO, and Java in this supposedly grand new age of FP programming ignores that OO is still the pre-eminent paradigm for most applications and Java is remains one of the largest and most utilized languages in the world. Also, I would say that excitement around FP has waned more than it has for Java.