It may not be possible for us to ever reach empirical definitions of "good code" or "clean code", which means that any one person's opinion about another person's opinions about "clean code" are necessarily highly subjective. I cannot review Robert C. Martin's 2008 book Clean Cod...
  • Ephera
    5•4 years ago

    I’m probably preaching to the choir on here when I bring Rust into this, but yeah, reading this kind of article makes me appreciate Rust’s explicitness even more.
    Rather than everyone having to keep to best practices, to not modify arguments, the language simply requires you to specify, if you want to modify an argument and your caller also has to opt into that.

    When I started out with Rust, I was worried that this would be too much detail work, but given that it’s usually a bad practice to modify arguments anyways, yeah, this actually works out really well.

  • Maya
    5•4 years ago

    ugh yes. I’ve seen so much painful code at work because of overDRYing and people trying to extract things just because of length (at the expense of coherent readability) and… it just doesn’t have to be this way.

    (same way with design patterns: maybe they should start out being introduced with “if you see awkward looking code that looks like this, then consider this pattern” rather than the overly abstract “this pattern can be applied to this situation”… so many singularly implemented interfaces 😤)

    • @apple_juice
      1•4 years ago

      overDRYing

      This is a never ending nightmare in my job as well. How, having to ctrl + left click function after function all over a file to figure out what one particular function is doing increases readability or understandablity is beyond me. When I brought all this up I got this book as a reply…

    • @robinOP
      3•4 years ago

      I think that the issue is OOP itself. Having 1-3 lines in a functionnal language (or anything that can use functional idioms) is both idiomatic, more readable and maitainable.

  • @robinOP
    1•4 years ago

    When I read clean code (about 2 years ago), I read it with the point of view of a C++ programmer. I read the advices and skept the code (since java didn’t interest me that much) and I filtered the advices that I though didn’t applied to C++. For this very reason, I found the book relatively good (since I focused only on the good part).

    I found this article absolutely on point. I also finally understand why I really don’t like uncle bob’s conferences since I don’t skim or filter them partially but watch the whole content.

    Nonetheless, I don’t regret that I read clean code, mostly because it forced me to articulate my thoughts on what I liked/disliked about it. I wouldn’t recommend it though.