21 votes

Topic deleted by author

8 comments

  1. [2]
    Omnicrola
    Link
    A few others in this post have mentioned they haven't read the book, and seem to be under the impression that Clean Code prescribes a set of rules that should be followed like gospel. Which is not...

    A few others in this post have mentioned they haven't read the book, and seem to be under the impression that Clean Code prescribes a set of rules that should be followed like gospel. Which is not how I view this book at all.

    I have actually read Clean Code several times. First time was in 2011-ish. I've recommended it to many programmers of many skill levels. Anytime I hear any kind of comment along the lines of how they enjoyed a refactor I did that tidy'd up some code or they lament about how they wish they could writer nicer looking code, I pull it up on Amazon for them.

    It's not a perfect book. It's not going to make anyone into a fantastic programmer. It's a guidebook. It presents some ideals about how functions should be super tiny, functions should always be pure, and rainbows always appear after rain. I recommend this book to everyone not because I think it's gospel and that everyone should relentlessly strive to make their code match what the book says, I recommend it because it's an excellent starting place that establishes a set of starting ideals that a team can strive for.

    When you teach someone something new, especially something that is complex and has nuance, you don't start by teaching them all the nuance. You teach them the basics, and you get them to practice it until they're sick of it, until it's burned into their muscle memory. Then you start teaching them exceptions, nuance, and an understanding of when not to do the standard thing. Clean Code is like a kata. Learn it, understand it, practice it, and then learn why not to use it. As @crius said :

    things like clean code are more like guidelines and, most importantly, are a group decision and effort.

    I think of Clean Code as a conversation facilitator. A starting point for that group decision. If someone is using Clean Code (or any coding book really) as stone tablets, then that someone hasn't learn nuance and needs to be taught some lessons about how zealotry is not productive or helpful when collaborating.

    7 votes
    1. crius
      Link Parent
      Totally right. It's like at school when you are a kid. You learn the basics and, if you think about it, sometimes you learn also things that are "wrong" because you need that knowledge to...

      Totally right. It's like at school when you are a kid. You learn the basics and, if you think about it, sometimes you learn also things that are "wrong" because you need that knowledge to understand, at a later time, WHY those things were wrong and that there is a better way.

      I'll definitely keep that book in mind next time I'm choosing something to read :)

      1 vote
  2. [3]
    crius
    Link
    tl;dr: Clean code has never been a set of rule written in stone. That's what junior developers think because it help them feel less insecure about their work. And there is nothing wrong with it....

    tl;dr: Clean code has never been a set of rule written in stone. That's what junior developers think because it help them feel less insecure about their work. And there is nothing wrong with it. When you get enough experience, you learn that things like clean code are more like guidelines and, most importantly, are a group decision and effort. If you do it any other way (I do it this way, screw what the others do) you are doing it wrong.


    Never read that book as well but if there is a thing that you learn when you become more experienced than "junior" is that there is no such thing a "clean code" or "official worldwide guidelines" but instead there is a department/company guidelines on how code should be written.

    There are things like "we follow functiona programming paradigm" that works like an import from another set of guidelines and that's good. It's good that there are some specific dedicated guidelines but the guidelines of a group of developers should be a group effort.

    Personally I often find an already set of rules when I join a company and believes it's my duty as a professional to challenge those rules if they can lead to problems. In the current company I'm working, there were some bad "guidelines" that I indeed challenged and convinced the colleagues that they were dangerous, no matter that it was what they "always did that way". But, again, it took an honest and open discussion and even after that, it took time because legacy projects are a thing that exists and you can expect the entire world to stop spinning in a direction because you have the new enlightened way of doing things.

    5 votes
    1. [2]
      skybrian
      (edited )
      Link Parent
      This gets more complicated with larger companies. For each language it uses, Google has automatic code formatters, linters where new warnings are often being added, detailed style guides for each...

      This gets more complicated with larger companies. For each language it uses, Google has automatic code formatters, linters where new warnings are often being added, detailed style guides for each language, mandatory code review (in the main codebase), and readability reviews to make sure that people getting started with a new language learn the rules regardless of which team they're on. I helped out doing Dart readability reviews when I worked there and even for a smaller language it's a lot of work.

      This does make the codebase quite a bit more uniform, but the overhead has downsides. It's not enough to convince your teammates to change something; you have to discuss it with the readability people for that language and convince them that a rule should be changed, and then sometimes the tools need to be adjusted, and you have to have some kind of policy about when older code should be adapted to the new rules, if at all.

      There was an epic debate eventually leading to the decision to increase the maximum number of columns for Java code from 80 to 100 characters. Newer languages did things differently. The Go people said nope, they're not going to enforce any column width and just asked people to be reasonable. For Dart, you can read Bob Nystrom's post about his epic adventures writing a code formatter..

      He also wrote "long names are long" about identifier naming. The Java folks write the longest names, sometimes to the point of self-parody. The Go folks controversially prefer single letters and abbreviations for locals, and Dart is somewhere in the middle.

      I guess learning multiple languages is broadening in that you do learn that there's more than one way to do it.

      Also, to keep the rules manageable, the style guides are necessarily shallow. If a team adopts a framework with unfortunate design patterns there's not a whole lot the readability folks can do about that. So in the end it only goes so far, but at least you can complain about deeper problems rather than shallow ones.

      5 votes
      1. crius
        Link Parent
        Really interesting insight. I spoke from my experience of course. I tend to join young companies and shape them to be on a "good trajectory" technically speaking or mid-life that have gone wrong,...

        Really interesting insight.

        I spoke from my experience of course. I tend to join young companies and shape them to be on a "good trajectory" technically speaking or mid-life that have gone wrong, fix their stuff and leave them with some golden rules to follow. Goes without saying, the latter end up calling me back more often than not :-/

        Anyway, you can imagine that due to my kind of roles I deal with small to medium tech departments, either tech companies with very few employees or non-tech (or better saying, companies that still believes in 2020 you an be a non-tech company) that have an undersized tech department.

        In these cases it's easier to have a shift in rules, habits and mentality but I can totally see your point when you reach a certain size.

        1 vote
  3. joplin
    Link
    I had the unfortunate experience of watching the Clean Code videos at work. I'll just say they're highly unprofessional and if it hadn't been my manager's manager who suggested them to us, I would...

    I had the unfortunate experience of watching the Clean Code videos at work. I'll just say they're highly unprofessional and if it hadn't been my manager's manager who suggested them to us, I would have been embarrassed for my superiors to know we were watching them. They also all start out with a completely irrelevant (but usually interesting) 5 minute astronomy lesson. I don't know whether it's ever explained why because we didn't end up finishing them. He never says anything about the astronomy intro during each lesson and he never goes back to them. They don't seem in any way related to the programming content. It was utterly bizarre.

    That said, my experience matches what the article says. There is some really good, timeless advice, mixed in with some really terrible advice. I, too, would hesitate to recommend it to beginners because they won't be able to tell which is which.

    I see Clean Code idolatry mostly on places like StackOverflow. You get the same thing with Design Patterns. There's some helpful advice in both, but there's more to programming than either of those.

    4 votes
  4. vord
    Link
    The function breakdown reminds me of a thing I deal with at work. Employer migrated from a mainframe to a sql-based ERP system. None of the employees really wanted to do this, so they took the...

    The function breakdown reminds me of a thing I deal with at work.

    Employer migrated from a mainframe to a sql-based ERP system. None of the employees really wanted to do this, so they took the bare minimum training to use SQL instead of mainframe code.

    The result is what our DBA team calls 'PL/COBOL'. It's technically PL/SQL, but it's structured like and reads like COBOL.

    My favorite is one developer who abstracted one small program into many dozens of tiny functions, most only a line or two (as described in Clean Code).

    The source code was 1500 lines long. It took 1 hour to run. I replaced that code with a 100 line SQL query with a couple CASE statements that returned in about 5 minutes.

    Abstraction works well for some code. For SQL that often isn't the case, especially when working with custom bolt-ons to vendor databases.

    My personal (and very amateurish outside of SQL) stance is that many things shouldn't be abstracted into functions until you find that you're repeating yourself.

    2 votes
  5. post_below
    Link
    While I've never read Clean Code, I feel confident saying: No one person's perspective on an ultimate set of rules for what to do and not do in coding is universally applicable (or useful). There...

    While I've never read Clean Code, I feel confident saying: No one person's perspective on an ultimate set of rules for what to do and not do in coding is universally applicable (or useful).

    There are lots of useful best practices but even the most straightforward are rarely absolute and often cause more problems than they solve if treated as gospel.