22 ms·

There’s No Such Thing as Clean Code

• tester34 5y ago
  Good/Clean code is context dependent kernel's code is terrible mess by java/c# web app standards (dependency injection, interfaces, mockability, testability, etc) Even C#'s compiler code written in C# is below architect's dream web app code base full of DDD, various patterns, CQRS, Event Sourcing yada yada
• jtwebman 5y ago
  Wow the font and color of the text sucks to read on that blog. I think maybe he has been stuck in C# or Java land to long. I do agree with him though that we need to provide more details on what makes it clean to you if you are saying that.
  • agr1277 5y ago
    Black on white? The readability of this text is... totally unremarkable?
• raverbashing 5y ago
  > But these traits are in some ways at odds with each other. The most simple code is probably not the most testable. All those interfaces and injected dependencies make for convenient testing, but have a cost in terms of simplicity. Exactly The same code snippet might be good in one context and an annoyance in another context Here's where "generic rules" fail. Like python's avoidance of lambdas and favouring just having functions. Well, but, depending on the context, they make a lot of sense. "Oh but lambdas are less readable" not if you need 20 different short functions and you need to combine them. Too implicit and it's hard to read, too explicit it gets boring and also hard to read.
  • robertlagrant 5y ago
    20 short functions definitely sound as though they should be explicit. Named, documented, testable. 1 or 2 you could get away with being implicit. 20 requires a lot of understanding as to what's going on!
    • fdgsdfogijq 5y ago
      Wait until you work on a 100k line code base where someone enforced this kind of thing
      • DarylZero 5y ago
        point-free master race
      • robertlagrant 5y ago
        Fair enough - I haven't done that. I'd be surprised if having loads of anonymous, untested functions would make such a thing more manageable, though.
        • valenterry 5y ago
          Do you test every line of code you write separately? Probably not. You test a function that has 5 lines of code. Same for anonymous functions. You test the functions that use them and that's usually enough. If not, then that is a good indicator of separating them out into named functions.
          • robertlagrant 5y ago
            This is the wrong way to think about it, though. A function encapsulates some behaviour, regardless of how short or long it is. You don't test each line (directly); you test each function's mode of operation. So a function with one if statement in it potentially needs two (happy path) tests.
            • valenterry 5y ago
              I don't think we disagree. It's just that a lambda doesn't change this. If the lambda itself also contains a branch, then yeah, you should probably test the outer function with at least 2 inputs.
              • 5y ago
• antris 5y ago
  Coding is a highly subjective and creative endeavor. "Clean code" is akin to "well written" for writers. Sure, you can analyze and even be able to define some good practices, but because we are always creating something new that has never done before, and the field is infinitely complex, no rules can be set in stone and applied across everything. In my opinion there's nothing wrong with calling code clean, we don't have to analyze every line of code we write. There's just too many things to consider and viewpoints to take, we'd be trapped in analysis paralysis forever, as you can continue it to no end. There's never a point where the analysis will be "done". You just have to be able to recognize when the analysis reaches a point of diminishing returns, and when moving on is the better option. Sometimes just calling it "clean" is enough.
  • jerome-jh 5y ago
    Subjective terms like "clean", "ugly" really hurt our field. OTOH the following attributes are objective and verifiable: - the code complies with coding conventions in force - it is correct - it is not inefficient I would really love coworkers stick to these three criteria during reviews.
  • fendy3002 5y ago
    I'm not giving up on clean code, but at the last 5 years I pursuit separation of pure function and unpure function more than clean code. It makes easier to debug / unit tests.
    • danielvaughn 5y ago
      That sounds like clean code ;)
    • deleted 5y ago
      [deleted]
  • tikhonj 5y ago
    Writing is a great metaphor: there aren't any hard-and-fast rules and there's certainly a subjective quality to it... but also, some writing is clearly better and some writing is clearly worse. Maybe there is no such thing as "good" writing because writing can be "good" in different ways or because we can never fully define what "good" means, but that doesn't mean that all writing is equal or that "everything is a tradeoff"—and, like you said, it doesn't mean we need to deeply analyze every piece of writing to draw useful conclusions about it. My view is that while there is definitely a subjective aspect to quality—whether in code or in writing—a larger portion is objective, just hard to formalize or quantify. Just because we can't measure something directly or because we can't all agree about it in every instance doesn't mean it's subjective. There are a lot of things we can't know exactly but that are still objective, so why not writing or code quality as well?
• fdgsdfogijq 5y ago
  Theres definitely clean code, theres just no rule book for how to define it or course you can teach for how to write it. Some people are just better at the art of writing simple software. You definitely know it when you see it.
  • IshKebab 5y ago
    I agree. The article (well the little I read of its unreadably thin font) doesn't even really argue that there's no such thing as clean code, just that it's not very well defined. Well sure, but that's like saying "there's no such thing as beauty" or "there's no such thing as a well-written book". Clearly bullshit. They might be somewhat subjective and have no mathematical definition but they clearly exist.
    • CRConrad 5y ago
      > well the little I read of its unreadably thin font Try pressing F9.
  • pdinny 5y ago
    The author isn't arguing against the existence of "good" code or "clean" code but rather advocating for us to try to articulate what is good (or bad) about code because "clean" is vague and encompasses too many things. In response to: > You definitely know it when you see it. the author suggests: > It’s good to build that intuition, but we can’t just stop there. We need to dig deeper beyond those feelings to understand and articulate why we think the code is good.
• vnorilo 5y ago
  I like Blackwell's work on "developer experience" adjacent stuff [1]. Maintaining low viscosity (resistance to local change) is a super useful concept for me when thinking about clean code and good architecture. I think it's a pretty good signifier of elegance, decoupling, lack of spaghetti etc. 1: http://iihm.imag.fr/blanch/ens/2010-2011/M1/EIHM/cours/1998-Green-CognitiveDimensions.pdf http://iihm.imag.fr/blanch/ens/2010-2011/M1/EIHM/cours/1998-...
• MattGaiser 5y ago
  In my 5th role where I write code, and I have dealt with so many different approaches and definitions of "best practice" that at this point I just roll over to whatever the generally agreed approach is at my current org and mimic it as best as possible. In one organization, I have even had two seniors go back and forth telling me to remove what the other senior told me to put in. The entire process of defining "clean code" seems painfully arbitrary.
  • CRConrad 5y ago
    > In one organization, I have even had two seniors go back and forth telling me to remove what the other senior told me to put in. From: You To: Senior1, Senior2, Senior1s_Manager, Senior2s_Manager, Your_Manager Subject: Duke it out between yourselves Senior1, you told me to put in Feature1, Feature2, and Feature3. A while later, Senior2 told me to take them out. Senior2, you told me to put in Feature4, Feature5, and Feature6. A while later, Senior1 told me to take them out. My job is to implement worthwhile features, not to be an implement in your quarrel over which features are worthwhile to implement. Duke that out between yourselves, and only then give me the ones you can agree on to implement. Thank you. Your_Manager, I've looked over my job description. It says my job is to implement worthwhile features, not to be an implement in other people's quarrels. Yours says your job is to back me up in situations like this. Senior1s_Manager and Senior2s_Manager, maybe Senior1's and Senior2's job descriptions need to be clarified with regards to which features each of them is empowered to request or veto.
  • musingsole 5y ago
    Similarly, the existence of so many subjective and unarticulated views on "code correctness" has left me in a place where the only certainty is: there is no certainty. If your best practices are so great, make a sound business case for them. Uncle Bob did no such thing.
  • cardinalfang 5y ago
    That can probably be automated. clang-tidy has some opinionated linting rules that contradict each other, just enabled these and choose to auto-fix.
• brongondwana 5y ago
  There's also no such thing as a clean house, but there are certainly livable houses and painfully hard to live in houses...
• l0b0 5y ago
  Just because "clean" connects to a lot of concepts doesn't mean "clean" code is meaningless, any more than clean dishes. A plate smeared with tar is not clean, no matter if the tar is sterile, and a plate which has been sprayed with salmonella isn't clean, even if you can't see the contaminant. These are different dimensions of "clean", but still very much meaningful. I personally like "clean" as a term for code quality. We've all seen how focusing on easily measurable metrics (like code coverage) can help, but in the hands of the saboteur or the clueless it just becomes a meaningless number. "Clean", instead, focuses on the ultimately human judgement of how to make code which is fit for purpose.
• padolsey 5y ago
  It was never intended as a definitive _thing_. I don't think anyone believes it has an exact definition. Just like good writing. There is no canonical good. Shakespeare and Hemingway are both "good" but absurdly different. But still, "clean" is a useful abstract concept for us to aim for in each context we encounter. At the end of the day, we need some kind of way of talking about "desirable" or "good" code. And I feel like 'clean' is as good as any other word. The author lists a litany of traits that could be considered "good" things to aim for, but most of them are pretty granular, fuzzy, or superseded by others. The author says: Words like ‘encapsulated’, ‘testable’, ‘mockable’, ‘reusable’ have meanings that we can all agree on. When we use more specific words that describe the various code traits that affect our project then we can be sure that we’re all on the same page. Unfortunately, however, we're never really on the same page. Even these more precise terms are very context specific and amorphous. "Testable" may mean granularly accessible, modular, mockable, idempotent, or quick to spin-up for CI, or only a subset of these. Highly dependent on testing approach too (unit, TDD, BDD, E2E...) This is why I like thinking in terms of tenets: broad concepts that are applicable to everything but enable context-specific meaning. E.g. - Reliable - Efficient - Maintainable - Usable With these tenets, for example, we can then *contextualize* and find the "cleanest" code for whatever particular application we're working on. If we want to break these broad tenets down further then we can, and I hold the position that this _is_ very useful: - Reliability: Correctness, Stability, Resilience - Efficiency: Time, Space, Second-order effects (ecology etc.) - Maintainability: Adaptability, Familiarity - Usability: Storytelling, Intuitive, Accessible Most of these are independently VERY context-specific. Being time-efficient is about the available hardware, interfaces, UX, etc. Being accessible or usable is about WHO is going to use or access your abstractions and underlying implementation. To achieve these tenets, there are many principles and approaches to draw on to help us find the 'clean' solution each time: E.g. The Law of Demeter (LoD), SOLID, The abstraction principle, Functional programming, etc. These exist as tools to help us get closer and closer to the unreachable (yet desirable) goal of "clean". So, I suppose I agree with the author but only semantically. Cleanliness does not have a fixed definition, but it is still useful to talk about as a goal or absolute to aim for. A bit like all manner of other superlatives.
• bluetomcat 5y ago
  > Readable, Understandable, Simple, Performant, Safe; But these traits are in some ways at odds with each other. No, they are rarely at odds with each other. Readable code leads towards performance and safety naturally. Writing readable and simple code means that you understand the problem domain well, and the amount of abstraction needed for tackling the particular problem at hand. Readable code is also much easier to analyse for performance and safety.
• locallost 5y ago
  After suffering in the coding world for a bit now, the only clean code I need is the code I can easily change or use. Code formatting, style, naming, but even architecture and all forms of best practice cargo culting I do not care at all, if it does not make things easier. The company I worked for had a separate team, kind of a startup, and these guys were all in on discussions how to do things cleanly -- is it a code smell? -- but everything they did was overengineered and borderline useless. If the things you do to make code cleaner make it more difficult to change things, or even to use it, you are doing it wrong. And I've done things wrong plenty and mostly still do, but I want to improve and what developers usually emphasize does not make things easier.
• deleted 5y ago
  [deleted]
• tarcon 5y ago
  "What Is Clean Code? There are probably as many definitions as there are programmers." Robert C. Martin - Clean Code A Handbook of Agile Software Craftsmanship - p. 7
• tarcon 5y ago
  "What Is Clean Code? There are probably as many definitions as there are programmers." - p.7 - Clean Code - Robert C. Martin
• ahmaman 5y ago
  Clean code is code that does what you expect it to do without many surprises. It is simple, not clever. Effortless to follow. Each part handles one idea at a time, at the same abstraction level. Doesn't force you to mentally juggle many balls at the same time. The code often tells you a story, it communicates how the programmer (author) described the problem, the solutions and the trade-offs. Very similar to writing. Maybe it is a vague term. But it is not an excuse to write "bad" code. Perhaps every team need to have a "definition of clean code" for themselves.
  • brianmcc 5y ago
    >> It is simple, not clever. Effortless to follow. This is the crux of it for me. I want to read code not solve code. If I have to "figure out what's going on" then it's not great code.
    • RangerScience 5y ago
      YES. An older Rubyist once told me: "Code is programmers communicating with other programmers."
    • andruby 5y ago
      Exactly. “Write code for humans first”.
    • smaudet 5y ago
      An entirely subjective measure. I want to solve problems, not read code. I can read your code and understand it, but then still have to solve it to understand what problem you are solving.
  • theonething 5y ago
    In my work history, I've never come across code like this, especially "effortless to follow". All the codebases I've worked with have been head scratch causing balls of mud. Am I unlucky or is what you are describing the rare exception?
    • 5y ago
• oreally 5y ago
  In any case, developers should get out of their nerd bubbles a little more. YES there are metrics that exist outside our field, but no, we gotta follow these outdated gurus who havent coded in a while, fetish-size complexity, come from a background incomprehensible to you and still stuck in old ways. What are these metrics you ask? Here's a suggestion: The number of neurons in your brain that light up in response to dissecting a codebase. Because you get frustrated when everything seems important, (something that happens when you dissect hardcore DRY-ish code).
• awill88 5y ago
  Preach it. I feel like you took the words right out of my mouth. I left my last job because I couldn’t keep sitting and listening to the bullshit about how everything had to be built the same, citing “uncle Bob” every.single.day… coerced into long, drawn out PRs that oscillated between “I don’t like how much you’re changing, can you break it up?” to “what’s the reason for this change?” — lol you literally asked me to break it up. I dunno wish them the best, but god that place was a drag. I knew it was a red flag when I logged into the rabbitmq cluster and immediately notices there was no TLS and when I tried to talk about it I got waved off and asked what was assigned to me, 3 months later I open a 2 line PR and the shadow architect goes “wait, we’re not using TLS?” “Nope” “did you mention this before?” “Yep” SMH
• midjji 5y ago
  And yet, everyone will agree: void dothing1(Args..){...} //old version of dothing1 the programmer keeps around to copy code from later // which should never be used void dothing1_backup(Args..){...} is not clean. People often strive for explicit and complete inclusive definitions for concepts better defined by what they are not. The former is more powerful when it applies, but the latter case is much more common.
• jpswade 5y ago
  Language is often about being able to take shortcuts, to infer meaning, to talk about things in the abstract an everyone understand what you mean. Clean Code is just a concept, it’s up to you to define it within your culture or community. I think most developers will have a basic grasp of the difference between clean and ugly code, you just might need to discuss the finer details as you learn. Because it’s not well defined globally doesn’t mean there’s no such thing or it doesn’t exist.
• drawkbox 5y ago
  There is such a thing as simple code. The job of the engineer is to make complexity simple, even when your target market is other engineers. The complexifiers and verbose Vogons persist heavily today though, as well as project management processes that create an infested myriad of complexity from shallow code to legions of dependencies and asset flipping rather than an effort to be close to the actual standards that run things, abstraction overuse is a major problem. Simplicity takes a professional to achieve and maintain. Simplicity and simple parts lead to "clean" code.
  • mojuba 5y ago
    Absolutely, and I'd say: > make complexity simple, even when your target market is other engineers including and especially if the target market is other engineers. Simplicity though is achieved with additional effort. It almost always requires additional effort to make the implementation simpler while having the same outcome. It's why my personal motto is "Think more, write less". This, however, is not something that's encouraged in software companies. You are supposed to be sitting there and typing non-stop, that's what they call a "software engineering job". In fact I never call any code "clean" because the term is vague. All that matters is how simple it is and thus how maintainable and performant, though occasionally the two can contradict each other, but most of the time they don't. Say, a complex caching algorithm can improve performance, so that's an exception. But most of the time simple is a synonym of both maintainable and fast. Can't think of anything else that matters, has real practical consequences and is not just hand waving around "common practices".
• mattbillenstein 5y ago
  Beauty is in the eye of the beholder. But, I think there are cases where it's quite obvious that one solution is "cleaner" than the other. Sometimes a refactor is just strictly better in all ways. I once had a service that wrapped a core algorithm in our code, but the code for the server and the code for that algorithm were all jumbled together. It became hard to write tests for the algorithm because the server wanted sockets and a specific protocol and blah blah blah. So, I simply separated them - the server instantiated the algorithm and called simple functions in it. Tests could do the same - it was strictly better in every sense - it made each part easier to reason about, test, read, understand... And with no real performance difference. "Clean"
• bayesian_horse 5y ago
  The only clean code is the one that doesn't do anything. Apart from that you can only hope to avoid adding too much dirt.
• RangerScience 5y ago
  > There’s no such thing as clean code. > ‘Clean’ isn’t a measure of anything useful. Code can’t be clean simply because ‘clean’ doesn’t describe anything about code. Ehhhh. There is absolutely such a thing as clean code. But yes; what there isn't a way to measure code cleanliness (although there's lots of surrogate measures; see every linter) which means there's also no way to render it into a dogma... ...and to (perhaps) stick my foot in it, that's something that gets harder to grok the less important subjective human experience is to you. IMHO, this is part of why Ruby code has an easier time being cleaner (and can reach high levels of "clean") - subjective human experience is baked into the language. (note: yes, you can absolutely write dumpster fires in Ruby, arguably easier than you can in Java; and you can absolutely write very clean code on Java and any other language) > I’ve come to the conclusion that often when we describe code as ‘clean’ when we think it’s good but we’re not entirely sure why. It just feels like the right solution. Yes, absolutely. There's a lot of things in popular wisdom that are signposts for "there's more here if you pay attention". > absolve you from having to justify that with more concrete rationale. ...Why in the hell do you need absolution here in the first place?! What are you being absolved from? (shameless quote: justice only matters to the just) > you don’t really need clean code, you need _____ code No. That's the trap of Goodhart's Law. You need something outside of your metrics so that your metrics don't become your target.
  • coldtea 5y ago
    >Ehhhh. There is absolutely such a thing as clean code. But yes; what there isn't a way to measure code cleanliness Well, in several epistemologies the second admission means there's no such a thing (or that, it might as well not exist).
  • parminya 5y ago
    > No. That's the trap of Goodhart's Law. You need something outside of your metrics so that your metrics don't become your target. How can you make a metric out of "we aren't really sure what the direction of change for this feature is going to be, so it should be easy to refactor"? and why would that metric be any more likely to fall victim to Goodhart's Law than "the code should be clean"?
• usrbinbash 5y ago
  The fact that everyone can come up with his own definition of what "clean" is supposed to mean regarding code, tells us something very important about it: It has no intrinsic, defined meaning in the context of code. Saying code is "clean" is like saying food is "tasty"...its a personal opinion, not a defined term.
  • RangerScience 5y ago
    Strong disagree. It's defined meaning in the context of code is a subjective experience of the coder of "clean", which carries elements of "satisfying", among other things. Maybe: It has no intrinsic, defined meaning in the context of the computing machine.
    • usrbinbash 5y ago
      > is a subjective experience of the coder of "clean" My subjective experience of grapefruits is that they are yucky. That tells others that I don't like grapefruits, but it tells them nothing about the grapefruit. It tells them nothing about, what exactly in the interplay between the chemical composition of grapefruit juice, the genetic programming behind my tastebuds, and the personal experiences which shaped my individual perception of "tastyness vs. yuckyness", makes them "yucky" for me.
  • TameAntelope 5y ago
    But there is agreed-upon tasty food, so there is some kind of intrinsic, shared meaning of the word, which is also true of code. It's not objective, but there is a consensus among peers. Honestly, it is like art, but these analogies kind of fall flat since we're not all "artists" in the traditional sense, usually. The reality is, for a painter, there are things that come close to objectively "good" works, a lot more so than for the layperson, and an experienced painter can walk you through all the different "types" of "good" art, just like an experienced coder can walk you through all the different "types" of "good" code. Just because we can't write down in a few pithy words what "clean code" is doesn't mean it doesn't exist, it just further confirms something we've all known for a long time now; code is art.
  • 5y ago
• phkamp 5y ago
  There's a book called "Zen and the Art of Motorcycle Maintenance" that this guy need to read...
  • CRConrad 5y ago
    His post felt to me like he might have read it.
• einpoklum 5y ago
  From the list at the link, I would argue that the following are mostly orthogonal of, and certainly not requirements from, clean code: 1. Performant 2. Safe 3. Scaleable 4. Easy to delete --- Performant: I can write you a nice clean bubble sort implementation, which will obviously not be performant. Safe: You could write a nice clean server which reads input from a network socket and executes it via `system(...)`. This would not be safe. Scaleable: That's not even properly defined. How would you "scale" my device driver? Or my microcontroller logic? ... does that mean those can never be clean? Easy to delete: To delete and replace? To delete for building tests for other parts of the code? Didn't even get that.
• noduerme 5y ago
  I'm glad he brings up the much-maligned Singleton pattern as an object for debate - or beauty being in the eye of the beholder. "Clean" to me involves a range of classes and singletons (or better, all static code) in as close an approximation to use as they're a actually used in the final code. If something happens once only in your code, it's dumb to make it a class instance. If it happens twice but you know you will never need it again, same. If it happens repeatedly, refactor. Clean code can be repetitive or concise. Readability is important, but only part of cleanliness. When you look at bad or dirty code you can tell immediately, because the logic is loose; it seems to try to handle edge cases at the end of a logic block, or catch errors that lead you to wonder why should this code ever encounter that error if the other code it's referring to is stable? Clean code displays confidence in knowing that edge cases are managed before they get to user functions.
• onion2k 5y ago
  The Uncle Bob Martin definition of "clean code" from his book "Clean Code: A Handbook of Agile Software Craftsmanship" is a set of rules that absolutely are not at odds with one another. If you follow them you will end up with code that's really nice to read and easier to maintain, and, most importantly, that you can confidently change. There's a decent summary here - https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29 https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988c...
  • davedx 5y ago
    Yeah I agree with almost all of these. IMO the most important is “keep it simple”. That is always always my coding North Star and it’s served me well over the many years I’ve been programming.
    • omegalulw 5y ago
      +1 when I write code I always think about how my reviewers would perceive it before sending it over and I refactor based on that. You should aim to write code that's easy for others to follow.
  • raverbashing 5y ago
    > is a set of rules that absolutely are not at odds with one another Yes, if you take them as general guidelines, not dogmatic rules with variable interpretations The latter is exactly what his fans do > 2 .Keep it simple stupid > 2. Prefer polymorphism to if/else or switch/case. No, not at odds with one another...
    • mpweiher 5y ago
      Hmm...polymorphism is almost invariably simpler than if/else or switch/case, so not seeing the contradiction.
      • fortylove 5y ago
        Is that view not subjective though? Might someone think that if/else is simpler?
• larschdk 5y ago
  So many developers say "clean code" when they mean "familiar code" and "familiar coding patterns". One person's clean code is another's heap of spaghetti. Idioms (like Duff's device, assignments in conditionals, function chaining) can be clean code if you apply it appropriately and your developers recognize it. Strict class hierarchies can be dirty code if you need to move gigabits in real time with 10 µs latency. Kids don't like broccoli because they haven't tasted broccoli.
• xlii 5y ago
  I agree - "clean" or "good" are the same type of keywords like "professional" or "specialist". I worked in places where code was 100% conformant to the official style guides, but every single change was painfully slow and quite a lot of people complained about working environment. Code was handbook level beautiful though, even if not exactly bug free. I also worked in feature factory where management was crazy, code was unimaginably inconsistent (same module, multiple files, one file - tabs, other file - spaces, third one - MIXED), but people were mostly chill and happy about pacing and themselves. No one believed in code so it was quite common to double and triple check most of the changes. Environment was very stable due to this. Eternal dichotomy - code as an art or form of engineering - shows really good here. For some utility, infinite extensibility and minimal code even in exchange for implicitness is cleaner than expressiveness and strictness. Thus, no code is clean. I could guess Java code isn't clean for Rubyist and likewise. There's a reason we have so many languages available.
• ignoramous 5y ago
  > Hopefully I can convince you that you don’t really need clean code, you need _____ code. It’s up to you to fill in that blank with words that describe what your project requires. The answer to this lies in quality of the final product, which is roughly determined by two opposing forces: 1. How simple is it for a team to make changes and continually meet the quality spec. 2. The velocity at which the team can make those changes to meet the product spec. Anything apart from these, is down to someone's personal preferences (usually in search of trying to invent a DSL mimicking their favourite language).
• _hao 5y ago
  There's a good take on this by Casey Muratori - https://www.youtube.com/watch?v=7YpFGkG-u1w https://www.youtube.com/watch?v=7YpFGkG-u1w And I agree with him. Things like SOLID and "Clean Code" really are just buzzwords nowadays that don't mean anything.
  • rootlocus 5y ago
    Casey lives in a bubble of his own, where he's the sole developer of every project he starts and he gets to make all the rules for himself. He doesn't really have customers, stakeholders, deadlines, he doesn't work on distributed enterprise software, etc. He makes indie tools and games. I really appreciate his push for simple and efficient, but in reality, the industry has spawned hundred of thousand of software developers these last decades, and collectively we've simulated every possible way of building software. The simple reality is, teams who followed well established patterns and good practices have had more success.
    • _hao 5y ago
      > Casey lives in a bubble of his own, where he's the sole developer of every project he starts and he gets to make all the rules for himself. He doesn't really have customers, stakeholders, deadlines, he doesn't work on distributed enterprise software, etc. He makes indie tools and games. Perhaps. I don't agree with everything he says all the time, however, from my own experience on working on distributed enterprise software I can say that following patterns blindly is an actual problem that impedes a good working solution designed for the specific problem(s) a lot of the time. Devs are pushed by DM's and PO's to have a working product ASAP and what might be a good idea for MVP prototype ends up being a burden down the line because now the entire system is built on top of that decision made in a moment in time without serious thought. Then some time passes and the whole thing crashes down. Then a rewrite happens in the exact same way and the wheel keeps on spinning. My 0.02c are that I think we should build things more sustainably and expect software to work longer. We should hold ourselves to a higher standard.
• aryehof 5y ago
  Sadly there seems to be nothing so attractive to a new(ish) programmer than a shiny silver bullet wrapped neatly into some popular or fashionable term, or better yet a three letter acronym. Our industry features codebases that approach “big balls of mud” as complexity increases. Last week it was called “agile”, this week “clean code”. Perhaps “agile microserviced functionally hexagonal clean code” (AMFHCC™) next?
• ojintoad 5y ago
  Since others are reflecting on the merits of the article in ways I agree with, here's some articles I've collected from recent discussions on "clean code". Some even try to ditch the term or argue against it, others give context to the meaning. Would love to see others if anyone has any! https://bitfieldconsulting.com/golang/crisp-code https://bitfieldconsulting.com/golang/crisp-code https://overreacted.io/goodbye-clean-code/ https://overreacted.io/goodbye-clean-code/ https://www.cyclic.sh/posts/write-shitty-code https://www.cyclic.sh/posts/write-shitty-code https://qntm.org/clean https://qntm.org/clean
• NicoJuicy 5y ago
  I really like "Clean Code", it's because other people/programmers could easily navigate the code, while not knowing everything that happens in the code. But in some rare cases, that's not what you want. Some functionality may need to require to know exactly what it does, because everything affects each other. And then i create a "class of mud" that does everything since everything is connected, where the naming conventions of Clean Code still applies. In my case, it was proxying json request bodies from an api to a 3rd party internal secure network where I had 1 dedicated pc running, where it could fulfill the request over a message broker (Service Bus in this case, to the internet network), execute the request that should work in the internal network and then send the response back through the message broker and give a response in the original API. That class was shared (and exactly the same) for the server and client. Only one was implementing it as a subscriber and the other one as a listener. The class was also commented à la SQLite, but no other classes in that code needed any comments - clean code wise. ( fyi, it was an internal secure api, that needed a 3rd part y ( our clients ) network)
• rootlocus 5y ago
  Sure there is, because there's a metric for it: "WTF"s per minute. Or, more seriously, cyclomatic complexity. I'm sure there are others.
• cryptica 5y ago
  The title is click-bait but the conclusion makes sense. It's just unfortunate that most people have such different ideas about what 'clean code' means. I guess people will ascribe that label to any code which they produce. Everyone (regardless of actual competence) wants to think of themselves as a good developer who writes clean code. My own definition of 'clean code' means maintainable (anticipates some broad future requirements) and avoids inventing unnecessary abstractions or adding layers of indirection (which just adds complexity and gives other people more work to familiarize themselves with the code).
  • heurisko 5y ago
    It's very click-baity. "Clean code" primarily means to me descriptive function names and variables, with functions that do one thing, and are not overly long. It's stuff like not using "temp" as a variable name for "temperature" as it unnecessarily adds to the cognitive burden of understanding the code ("Does this mean temporary or temperature?") This what I took away from the Uncle Bob book. I expect some will latch onto the title, however, to keep with traditions, like that somehow variable names are supposed to be abbreviated.
• caporaltito 5y ago
  With such a title, I am not even reading this LinkedIn clickbait.
• tromp 5y ago
  Although any code in the Clean programming language [1] could be called just that:-) [1] https://en.wikipedia.org/wiki/Clean_(programming_language) https://en.wikipedia.org/wiki/Clean_(programming_language)
• jmchuster 5y ago
  Code needs to be able to do what you need it to do. So anything that makes that job harder, could be considered not "clean". That might include... - code that is inconsistent. This causes additional overhead and mental burden when thinking about code. Trying to find what's truly logically different is hard when there are additional differences that shouldn't be there in the first place. - incomplete code. This might be a concept that was done halfway and then stopped. So there's additional mental burden of, this is what is meant to be done, but it hasn't been done in these places yet, so understand the code is being pulled in two different directions, and also keep that original plan in mind so that you converge those past plans with your current line of work. - buggy code. Code that looks like it should work but then doesn't causes issues when you can't tell if an error is in something new you're developing or something that existed already. - code that is hard to accommodate the new change. This one finally gets a bit fuzzier, as the more infinitely flexible you make it, the worse it'll be at matching the task at hand. If you are better at predicting the future, you might be able to set yourself up so that it's slightly easier for anticipated future development, with minimal impact to what you currently need it to accomplish. So this might not be an issue of "unclean" code but just the reality of changing businesses. Of course, it is also possible to just make design decisions here that are objectively bad no matter what the future plans are. You'll kind of find what is considered "clean" depending on your work place, what your engineering culture is like, what tradeoffs and priorities you have as an org. Basically, what is it that makes my job harder? That's what you then need to "clean" up. e.g. some orgs might say that lack of unit tests makes their job harder, and others might say it makes little difference, so then lack of testing might or might be a "clean" point depending on your org.
  • MauranKilom 5y ago
    > Code needs to be able to do what you need it to do. So anything that makes that job harder, could be considered not "clean". That reinforces the author's point that "clean" is synonymous for "good", without any added precision. Try interchanging the two in your comment - it reads exactly the same.
    • jmchuster 5y ago
• mr90210 5y ago
  I suppose the author has never seen DIRTY CODE, like I have.
• galaxyLogic 5y ago
  "Clean code" means about the same as "well-written code". Both have meaning. But the issue is that of course everybody and their uncle can agree that "clean" is "good". The question is when somebody claims to have clean code, is it really? Why do you say it is clean? Does everybody agree it is "good code"? It's much the same with "agile". Of course agile is good. Everybody can agree on that. But are people who claim to be agile really agile? 88% of drivers believe they are "above average". My guess would be that the same is true of programmers. Most of them are better than the average. :-) https://www.adam-campbell.com/post/most-drivers-are-better-than-average/ https://www.adam-campbell.com/post/most-drivers-are-better-t...
• bborud 5y ago
  Actually, what people say about code, and how you interpret what they say, depends a lot on what you know about the person in question. I know lots of programmers who can list lots of precise reasons why they think a piece of code is "good" or "clean", but who still seem to lack "good instincts". Writing code isn't really about ticking boxes, it is about communicating ideas to other human beings. And in that sense, a lot of programmers are to code like some people on the autism spectrum are to social interaction. Lack of instinct pushes us to make up precise rules to try to make sense of things. Rules which do not always work because their application is highly context dependent. And when the rules break down and people still insist the rules are good, you get absurd situations. For instance is composability good? Well, it depends. On paper this might seem like a simple thing to answer. In a given context composability might mean you have to bolt together a lot of moving parts to get anything done. If 99% of the time you bolt the same parts together the same way, you shouldn't explicitly have to do that. Perhaps composability isn't as important as you think in that instance. Anyone remember early XML infrastructure in Java? You want to parse an XML file and instead you end up instantiating and plugging together what felt like an awful lot of moving parts you neither needed nor wanted to know about just to parse an XML file? Yes, composability can be good. But as in the XML example, people don't always understand when it ends up being crap. (Actually, you can have both composability and convenience, so I am not trying to construct a false dichotomy here, but the original XML infrastructure was so "socially awkward" that it didn't really offer much convenience) One may think this is mere nuance. One could also say that uttering a sentence and picking the facial expression and tone of voice to go with it is nuance, and that the words you utter are always what matters. We know this isn't so. What makes code good is hard to describe. So merely trying to express it more precisely isn't enough. Yes you can say "composability: good". But in a given context it can also mean the code becomes less useful for the purpose in the majority of contexts.
• rawoke083600 5y ago
  So True ! After 25+ years of coding, I know one thing. I STILL don't know how to "code correctly". And apart from a few gifted individuals (Rob Pike, Fabrice Bellard Bobby Bingham [ffMpeg team] etc) I'm HIGHLY suspicious of ppl and programmers who claim "they can program correctly" and that "this xyz is the correct way/stack/method/arch". Background:CS grad, start coding at around 13 (thank you dad !) I am well versed in C,C++,PHP,Go,TypeScript and to a lesser degree Java and a few bits and bobs in between F#,Haskell,LISP... The above is not to brag (not that it's brag worthy after 25 years you bound to pick up a few tools) just to put it in perspective. On Code quality: I've noticed it's easy to agree/identify the "extreme cases" the VERY VERY BAD CODING and the very very GOOD CODING. But most of the coders and codebases falls somewhere in between where the code-quality-water quickly gets murky. PS2. Oh and on 'code reviews': It would be cool if code-reviews were done "anonymously" i.e I should not know until the very end WHO wrote the code. Helps to keep any personal biases at bay - my 2cents. The best thus far advise I've seen on code-quality guidelines is from a comment on HN: >I try to optimize my code around reducing state, coupling, complexity and code, in that order. I'm willing to add increased coupling if it makes my code more stateless. I'm willing to make it more complex if it reduces coupling. And I'm willing to duplicate code if it makes the code less complex. Only if it doesn't increase state, coupling or complexity do I dedup code. Source: https://news.ycombinator.com/item?id=11042400 https://news.ycombinator.com/item?id=11042400 Sure I might just be a dumb idiot or completely not gifted in the "art or science" of coding. :)
  • stavros 5y ago
    Does e.g. Fabrice Bellard code "correctly"? Getting shit done isn't the same as "coding correctly" (sometimes it's very close to the opposite).
    • rawoke083600 5y ago
      True - who can say ? Hard to argue with a WHOLE career that got "shit done" and WIDELY used by the world ? Maybe THAT is the metric to focus on. The value of the code versus the quality ? I honestly don't know the answer ? But I know how much of my "time and energy (as you get older you released the limiting step is your cognitive-energy not so much your actual wallclock-time) " I spent on "trying" todo code correctly which many times it means, the code doesn't get done and I end up frustrated by not shipping anything. Working for a boss, the above used to upset me a bit. Now working for myself this REALLY upsets me and my 'income' :) In these cases, I would DEF liked to have "Fabrice" getting shit-done-coding ability ? Again just my humble opinion :) Maybe coding is like a marriage... a) "You can be right or you can be happy :)" Squinting hard enough: b) "You can do things correctly or you can ship code in time that makes a difference ?" I guess the "better" you are the closer the extremes are from "b". i.e IF you are the theoretical-best-coder-that-ever-lived there is should be no "distance/friction" between "coding correctly AND shipping on time code that has an impact" ??
• tarkin2 5y ago
  "Clean code" is just a buzzword that people use in interviews, on blogposts aimed at employers, and to make programmers believe they are good programmers, since they already bought the koolaid. If you break it down to its principles, and then explain its advantages and disadvantages for the problem at hand, then it's respectable; but used as a buzzword it should ring alarm bells.
• codeptualize 5y ago
  Wow! Great article, and I love to see so many people agreeing with it. I think most clean code stuff is snake oil and fortune telling. So much time gets wasted in pointless discussions and tweaks that will make no difference whatsoever. The funny thing to me is that the bigger picture; actual logic and bugs, often gets missed while all the attention is focussed on stupid "clean" little pet peeve topics. It does seem there is shift, more and more articles and opinions like this and I'm here for it!
• edwnj 5y ago
  Na this is just semantics. There is clearly ugly code and clean code.. And generally speaking, ugly code is structured in a non obvious manner that can range from the specific implementation to naming.. Its a spectrum and after a certain point what is ugly/clean is very subjective but this is where semantics kicks in. Other than the occasional heated arguments, most teams can agree on what is ugly vs what is acceptable/subjective.
  • skohan 5y ago
    Disagree. I feel like I have seen this play out a number of times in my career: - New engineer joins a team with a mature codebase - New engineer complains about code quality, convinces management on a total rewrite to improve code quality - New codebase starts out simple and elegant - Eventually the codebase gets just as bulky and convoluted as the old one, because the ugliness was just a reflection of the complexity of the problem space A lot of times "ugly" is just a stand-in for "not written by me"
    • edwnj 5y ago
      I think your mistaking technical debt for code quality. I've seen the same thing play out and more often than not, its a helix like cycle of projects starting simple and as time goes on trade offs are made and you get a lot technical debt then you rewrite and the cycle begins again. I partly agree with you about "ugly=not written by me", I just think that only happens at the edges aka semantics.. Nowadays its pretty easy for teams to come to a consensus on whats clean/ugly vs acceptable/subjective.
      • skohan 5y ago
        I partially agree that there is a cyclical aspect to code rewrites and cruft accumulation. I still think a lot of time the perception that code is poorly written gets applied to complexity which is not yet understood rather than objectively poorly written code.
• jillesvangurp 5y ago
  This is a classic mistake that relatively junior people make. There's a body of research out there that goes back more than half a century that gives you plenty of heuristics, metrics, and other ways to classify code as good at bad in all sorts of interesting ways. Most engineers have barely any awareness of this and instead absorb vague notions of "good" and "bad" things from others over time. Junior frontend engineers coming fresh out of college are typically very ignorant on this front. Ignorant as in they have yet to rediscover this wealth of information through reading books, articles, etc. As well as by messing up a few code bases or by absorbing it from their more senior peers through e.g. code reviews or venting on blogs, twitter, and whatnot. That is because this stuff just isn't taught in a lot of places. Or if it is taught at all, it isn't taught very well typically by people who don't do a lot of coding. I know, because I used to be such a person before I switched to doing some actual software engineering 20+ years ago. Combined with the arrogance of youth and the tendency to label everyone above 27 as a senior, unclean code is rather common. And even acknowledging it is bad is a problem when you lack the intellectual tools to reason about code quality. It's not a matter of taste to consider high coupling and low cohesiveness a bad thing. It's easy to see when that is out of wack (long list of imports, 4000 line source files, etc.). It's easy to measure as well if you care too but typically redundant to do so. Likewise, having a high level of indirection would be a violation of e.g. Demeter's law. Likewise deep inheritance hierarchies aren't great (just don't). And that is equally easy to observe. Finally having a large function with insane nesting of loops, ifs, and what not produces a high complexity that you can measure or just look at it an go "gee, this looks rather complicated". It's not that hard to spot bad code if you know what to look for. It's also not that hard to improve such code once you understand why it is bad. Every bad code base you've ever seen probably has a lot of things that you can objectively point at and say this just isn't very clean because X. It stops being a matter of esthetics when you phrase it like that. And the broken windows theory combined with a level of ignorance/indifference usually leads to more bad code making it into the code base. There are plenty of studies that will suggest that having a lot of hard to read code does not help maintainability, extensibility, and a few other -ilities. Those are called quality attributes. And yes, you trade them off sometimes. There are yet more studies that point to maintenance as a dominant thing in overall software cost. There are also several standards that have lots of things to say about quality attributes. People developing e.g. embedded software for cars or medical devices tend to take that stuff rather seriously. But understanding that high cost is bad is relatively uncontroversial. Producing code that isn't very clean leads to higher cost. It's not about the esthetics but about cost. Both current and future. Sometimes you can trade that cost off. E.g. if you are going to throw away your UI code in 6 months, it's OK to put a few cheap fresh out of college people on that project. It's going to be a dumpster fire in terms of code quality but it might be useful as an MVP and you'll replace it anyway before it gets out of hand. I make tradeoffs like that all the time. And I also use such projects as an opportunity to train up young people quickly. Let them make a few mistakes and then show them how to fix it.
• jzer0cool 5y ago
  There is a purist version of clean code. One not written. Anyone witness seeing code for the sake of writing code? Playing also on the word "clean" here. I also feel it is just as important to take out the trash and clean out undesired code.
• koz_ 5y ago
  I don't know, is it more precise to say words like "encapsulated", "testable", "mockable" and "reusable"? Aren't these all essentially the same thing? Suppose you have a class that is technically testable, because you can control all of its inputs, but it has ten thousand methods. Is it really testable if it's so poorly encapsulated? I feel like good code is just decoupled code that lends itself to composition. Most writing about code is just about how to achieve that quality, not about identifying all these different and conflicting qualities and finding balance between them. > “I like solution X. It decouples the error message presentation from the core logic. It’s easier to understand, because you don’t have to consider both at the same time. This separation also unlocks some testability, as we can mock either object whilst testing the other. It does come at the expense of requiring the parent object to inject the dependencies, but that’s a worthwhile tradeoff for the testability.” Take this passage - is it saying anything other than "I identified two independently meaningful components here where you have one". What else can you do to clean up code other than separate things that don't have to go together?
• marsven_422 5y ago
• deleted 5y ago
  [deleted]
• cleancoder0 5y ago
  I like to measure things. Like token count, line count, variable count, method parameter count, indentation level and grokking time. Clean code minimizes these measurements. To minimize variable count I can use ternary expressions. To minimize indentation level I think carefully about early returns or extracting blocks of code to functions that do nothing if condition is true (early return). To minimize grokking time, I revisit old code I've written and measure the time it takes me to understand it. It turns out it correlates quite a lot with line, variable, and token count, indentation level :D Clean code as commonly defined is far away from any measurable metrics. That's why one might say that it does not exist.
  • christophilus 5y ago
    Sometimes, (maybe the majority of times) a five liner is clearer than a one liner. I think line count is a terrible metric to use. Agree about indentation. Grokking time, and time to make a correct, meaningful change are good metrics. It’d be interesting to take some of the examples from Clean Code, and rewrite them procedurally, then functionally, etc, and then test which takes the least amount of time for an average developer to understand and modify.
• azangru 5y ago
  > Clean’ isn’t a measure of anything useful. Code can’t be clean simply because ‘clean’ doesn’t describe anything about code. "Clean", famously, is measured in WTFs/minute. The fewer WTFs, the cleaner the code; and having a low-WTF code is useful for a programmer to read and modify and be happy.
• deleted 5y ago
  [deleted]
• ChrisMarshallNY 5y ago
  > If you’re hacking away on your own then you can do what you want I have a different point of view. I am the person that most often maintains the code that I write. It’s really important that I be able to understand it. Not just at a “tactical” level (This function does this), but at a strategic level (The architecture is designed as a functional abstraction of the model). My code tends to be quite well-structured, highly documented, and a bitch to understand. I will often employ fairly byzantine architectures, pursuant to testability, usability, and localizability. Works well, though, and ages nicely. I’ve written APIs that have lasted for 25 years.
• stack_framer 5y ago
  I once joined a new company and got stuck in the middle of a PR from hell. What should have been a quick bug fix (maybe 10 lines of code), turned into weeks and weeks of being told to rename, reorganize, and restructure aspects of the fix and surrounding code in order to adhere to a variety of undocumented conventions. Despite following patterns used elsewhere in the very same files, my code was deemed brittle, confusing, and poorly tested (we don't do this, we're trying not to do that). I patiently addressed each item of feedback, but of the dozens and dozens of PR comments, not one was ever about the accuracy of the logic that fixed the bug. Welcome aboard!
• _benj 5y ago
  The post showed me why my code is praised an understandable but I have the absolute worst time when it comes to testing it! The interfaces and abstractions needed to make a code testable is something I actively avoid in order to write code that others (including me in a few months) can glance and quickly-ish figure out what is happening and if there’s a big, where could it be. Now I can intentionally know that is a compromise I’m taking instead of feeling like a failure because my code doesn’t lend itself to testing…
  • cjfd 5y ago
    Well, not lending itself to testing really is a big problem. But one does not need to sacrifice much in terms of understandability to make code testable. For instance, one does not always need an interface. You could also just inherit from the thing that you want to mock. Another problem that might be going on here is that you might be trying to test on a level that is too low. I think it is in many cases not a good idea to test individual classes and methods. Often it is better to test some small number of classes working together. The problem with testing one single class or method is that you are likely testing implementation details that are very much subject to change and also that at some point one is testing trivial things like 'is the standard library of my language still capable of adding items to a container'. When testing at a bit of a higher level one can write tests that are about properties of the software that are actually valued by the customer. These are much more likely to be stable. If one tests at a level that is a bit higher, one also needs to mock fewer things so the interface thing is also less likely to be much of a problem.
    • _benj 5y ago
      That makes sense a lot of sense. I guess the thing is that golang and their are stdlib testing lends itself to unit testing and not so much to integration testing. Our system also talks to a bunch of hardware via multiple protocols, for which we’d need to write simulators (so I’ve written but mostly for development and not for testing) And apart from that, it being an async user facing gui app… well, automated testing is kind of a challenge :) But you are right, I can think of a few things that can be tested, bigger than methods but smaller than end-to-end testing
• raxxorrax 5y ago
  I think clean means the most simple solution that works. Maintainability is not exactly correlated with code size, but being less verbose helps. Otherwise if you want clean code you should wipe your monitor.
• svilen_dobrev 5y ago
  Good code should give me "warm fuzzies". well, you know, "Warm fuzzies aren't in the spec." :) https://www.original.moq.org/forum/michaelmeier/MeetingtheSpecandOtherSoftwareFables.html https://www.original.moq.org/forum/michaelmeier/MeetingtheSp...
• pards 5y ago
  I found the light grey font on white background to be almost unreadable. I persisted in reading it only because the subject matter is compelling but authors should be aware that such typesetting errors can turn people away.
• websitescenes 5y ago
  Wow, this post has triggered some emotion from me. I find it incredibly traumatic working with “engineers” that have this point of view. The pain individuals like this inflict on others is real! What they are really saying is that they don’t care about their fellow developers, their productivity nor happiness. This view will lead to “good enough” code that always appears to “work” but fails easily and creates more work for everyone else. God forbid you actually care about a project and get stuck working with someone like this on it. You’re going to have some sleepless nights.
  • jjdfmme1233 5y ago
    yes, these contentless articles are just well receieved because they validate the laziness of some while invoking emotion from others. @author - "clean code" means improvement relative to some starting point. there, problem solved.
  • cm2012 5y ago
    I don't see how you can read the article and come away with this opinion. The author's not saying that you shouldn't make quality code, he's saying that no one agrees on the definition of clean so you should use more descriptive language.
    • websitescenes 5y ago
      Agreed, read more carefully and makes me feel like this comment is misplaced.
  • marcosdumay 5y ago
    Hum... Your take from the idea that quality is multi-dimensional is that the author does not care about quality?
  • MarcelOlsz 5y ago
    God actually forbade me to care after 5pm.
  • musingsole 5y ago
• jspaetzel 5y ago
• lincpa 5y ago
• wirthjason 5y ago
  This reminds me when learning to write papers in college my professor would help proof my paper. I Had clarity in my thoughts but it didn’t translate to paper. We would evaluate the paper line by like. I would often use the phrase “X is better than Y”. He would stop me and ask, “why is X better?”, and I would give a more precise meaning. I like how the author applies the same idea to “clean”. Rather than just blankety apply clean he suggested expounding on the reason why it’s cleaner.
• tacitusarc 5y ago
  I think many of the qualities mentioned have nothing to do with “clean” code (like performance). My metric for cleanliness has become simpler over the years: Mean Time To Comprehension. The less time it takes for someone else (or future me) to understand how and why my code does what it does, the cleaner that code is. This is surprisingly accurate and actually useful.
• jerf 5y ago
  I've taken to looking at the first derivative of code quality rather than the zeroth. I don't necessarily sit and worry about the absolute, current quality of my code; rather, I strive to ensure that every time I do something, I'm generally improving the quality of the code rather than degrading it. If this sounds trivial, you may be underestimating the extent to which your fellow developers, and, perhaps even you, casually "spend" code quality to attain something in the short term. It's even little things, like adding the 7th parameter to a function that has become what really ought to be three distinct functions in one (very common problem). Adding that seventh parameter is degrading the quality of the code yet further. Working out what you need to do to extract the three separate functions out correctly, and propagating that back to all callers, is improving the quality of the code. We like to look at the sweeping refactorings, but a lot of times, it's very little things, as small as "Hey, I understand this variable better now that I've been in the function for the third time this month and it ought to have a better name, let me go ahead and use the IDE rename feature now". The quality of your code is much more determined by the sum total of all those little decisions than the big refactorings. You also don't have to "maximize" your positive impact at any given point and do all the possible improvements. That's paralyzing. Just make sure every interaction is just a bit positive, and the cumulative impact is huge.
• deepsun 5y ago
  It also depends a lot on application, e.g. UI code will always look different from ETL code. ETL code is much easier to test, than, say, embedded code.
• lindwhi 5y ago
  I agree with this one but there's such thing as a readable code.
• karmakaze 5y ago
  There is clean code, but I wouldn't say so generally. Each team should decide form themselves what constitutes clean code as a set of guidelines with documented motivations. Every now and then or as deemed necessary update and evolve the guide. As the codebase matures (in good and bad ways) so should the guiding principles change in weights.
• deleted 5y ago
  [deleted]
• redleader9345 5y ago
  The quote from this article that really hit home for me, was this: "Coding is generally a team sport. If you’re hacking away on your own then you can do what you want, but when we’re working with a team then we’ve got to discuss our ideas." My current job has this quasi-team, where we all work from the same backlog, with very little coordination, collaboration, or communication. Everyone just pulls a ticket and runs with it in whatever direction they desire. I can't stand it. When I raise the issue with my manager, it's just not registering. The turnover and retention is poor, so there are a bunch of new team members, and few people with tenure (like a single dev). The prevailing attitude is that if you reach out to collaborate with someone on your ticket, you're not only wasting the other person's time, but you yourself are incompetent. Because, why can't you just crush tickets all day every day without bothering anyone? It's silly.
• he0001 5y ago
  I loathe the “clean code” discussions. It’s highly subjective and unmeasurable. I want along and wrote some code which was highly test driven, because why not, and at code review this guy said that it wasn’t readable, eg clean enough, and not testable. I explained that the code was derived with TDD and he couldn’t believe it. Another colleague saw it and agreed with me. But the point here is that all of these reviews and clean code debates are just tiresome and silly.
• smaudet 5y ago
  There is no such thing as "clean code", I think its a verb, not a noun. Same problem as being virtuous, there is no such state. But you can attempt to do things well, make moral choices, etc. Specifically, when we first bang out that initial solution, the code is "dirty". As we refine that approach (better algorithms, adjusting terminology to better accommodate underpaid colleagues), we "clean" it, but the truth is the new code isn't in a "cleaner" state. The little bubble of local opinion might reflect better against said code, but that's hardly an objective measure.