Forgot your password?
typodupeerror
Image

Book Review: The Clean Coder 196

Posted by samzenpus
from the read-all-about-it dept.
CoryFoy writes "As someone who has been closely involved in both the 'agile software' movement as well as the 'Software Craftsmanship' movement, I have been following the work of Robert Martin for some time. So I was quite interested when I got my copy of his latest book Clean Coder where he 'introduces the disciplines, techniques, tools and practices of true software craftsmanship.' Would his book live up to being a guide for the next generation of developers, or would it go on my shelf as another interesting book that I had read, once?" Read below for the rest of Cory's review.
The Clean Coder: A Code of Conduct for Professional Programmers
author Robert C. Martin
pages 256
publisher Prentice Hall
rating 5 Nebulous Rating Units
reviewer Cory Foy
ISBN 978-0137081073
summary A good overview of the current agile practices for software developers
Before even getting into the book, it is good to know the style of Robert Martin, affectionately known as "Uncle Bob" to many people. Bob is a former preacher who comes at life — and topics he teaches — with a no-holds-bar approach. So when he approaches topics such as "Professionalism" and the software industry, I come expecting passionate discussion and serious assertions. The Clean Coder is no exception.

The book starts off with an overview of the Challenger space shuttle disaster. As a native Floridian who could see shuttle launches from my house (and, in fact, saw the Challenger explode just as it crested the trees from where we lived) this really resonated with me. The accident was a result of engineers saying no, but management overriding the decision. With this introduction, Bob makes it quite clear that when we choose not to stand up for that which we believe, it can have dire consequences.

We then dive right in, starting with the topic of Professionalism. The assertion is made that the key to professionalism is responsibility — "You can't take pride and honor is something you can't be held accountable for". But how do we take and achieve responsibility? Chapter one lays out two ways. To start, it looks at the Hippocratic Oath, specifically the rule of "First, Do No Harm". The book maps this to software by saying to do no harm to function or structure, ensure that QA doesn't find anything, know that your software works, and have automated QA. In fact, when I work with teams, I teach them that if your testing "phase" finds bugs, it's a problem with your process that needs to be addressed immediately, so the concept of ensuing that QA doesn't find anything is a great concept to bring out.

Then we move on to Work Ethic — specifically around knowing your field. This means continuous learning, practice (through things like Katas and Dojos), collaboration, mentoring, identifying with your employer/customer, and practicing humility. To help with that, Chapters 2 and 3 talk specifically about saying "No" and "Yes". When we say no, and when we want to say no, we should mean it. Saying, "We'll try" means that you, or your team, isn't already giving it their best, and that through some extraordinary effort you'll pull it off. Say no and stick to it. But, when you say Yes, mean it. People are counting on you to be truthful with them.

Chapters 4, 5, and 6 begin to talk about the specific practices of coding. Chapter 4 talks about the coding process itself. One of the hardest statements the book makes here is to stay out of "the zone" when coding. Bob asserts that you lose parts of the big picture when you go down to that level. While I may struggle with that assertion, I do agree with his next statement that debugging time is expensive, so you should avoid having to do debugger-driven development whenever possible. He finishes the chapter with examples of pacing yourself (walking away, taking a shower) and how to deal with being late on your projects (remembering that hope is not a plan, and being clear about the impact of overtime) along with a reminder that it is good to both give and receive help, whether it be small questions or mentoring others.

Chapters 5 and 6 cover Test-Driven Development and Practicing. The long and short is that TDD is becoming a wide-spread adopted practice, in that you don't get as many funny looks from people when you mention TDD as you once did. And that coding at work doesn't equal practicing your tools and techniques — instead you should set aside specific time to become better through coding exercises, reading and researching other areas (languages, tools, approaches), and attending events and conferences.

Chapters 7 and 8 cover testing practices. In Chapter 7 the book looks at Acceptance Tests and the cycle of writing them — specifically at what point the customer is involved (hint: continuously) and how to ensure they stay involved. Chapter 8 goes to more of the unit testing level, and defines some strategies and models for looking at unit testing, including an interesting "Test Automation Pyramid"

Now that we've covered the developer herself, coding and testing, the book moves on to discussing time. Chapter 9 covers Time Management strategies — staying out of "bogs" and "blind alleys", using techniques like the "Pomodoro" technique to create focus, and the law of two-feet — if you are in a meeting and aren't getting value out of it, you should feel free to (respectively) leave, or otherwise modify the meeting to get value from it.

Chapter 10 covers several different methods of estimation. In the teams I work with, estimation is perhaps one of the hardest things — not because estimating can be hard (which it can be) but because either they are held so tightly to the estimates that they are afraid to make them, or, worse, they are told what the estimates are going to be. The book really only skims the surface here, covering several techniques from Planning Poker, to PERT, to "Flying Fingers", but gives a decent overview of how to do those techniques.

Rounding out the discussions of time comes Chapter 11 and talking about Pressure. The key of this chapter is that because you have committed to your principles, practices and disciplines, you should be able to stay calm under pressure. I can certainly say from experience that the worst experiences in my career are when people weren't able to stay calm, and the way the book is laid out, if you are following the practices outlines so far, you should be able to be the voice of reason and calmness.

The last three chapters cover teams and collaboration. Chapter 12 talks about important practices such as shared code ownership, pairing, and respect for other team members. Chapter 13 covers teams and the importance of having teams that gel together. The book finishes with Chapter 14 and discussions of the importance of apprenticeship, mentorship and craftsmanship.

As I mentioned earlier, I've been involved in the "agile" movement for quite some time, and have spoken with Bob on many occasions, so many of the practices in the book weren't new. I did quite appreciate the stories he had to tell about his experiences. However, I think that some people may be turned off by the hard line around "professionalism". Sometimes you do need to say no, and I think it is good to have encouragement from a book to do that. But sometimes things are more complex, and I think that you would have a harder time looking to this particular book for help with the edge cases.

In conclusion, I think this is a book which provides worthwhile information and an interesting look at how people are looking at software development as a profession. If you read between some of the hard lines made, there are some great nuggets to be gleaned from the book for software developers of any level.

You can purchase The Clean Coder: A Code of Conduct for Professional Programmers from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

*

This discussion has been archived. No new comments can be posted.

Book Review: The Clean Coder

Comments Filter:
  • by Sonny Yatsen (603655) * on Monday June 13, 2011 @02:37PM (#36427324) Journal

    Back when I was getting my CS degree, I've always noticed that the cleanest coders are also the guys who didn't shower for days at a time and always wore the same clothes.

    • Re:Clean Coders (Score:5, Interesting)

      by chemicaldave (1776600) on Monday June 13, 2011 @02:48PM (#36427450)
      I can think of many colleagues in contrast to your example. I have found the opposite. In general, people who cannot keep themselves clean and their lives organized will produce sloppy code (that includes working code with unhelpful comments and obfuscated code).
      • by Kenja (541830)
        I dont know... I'm not the most organized person and I often forget to do dishes. But I write clean code and copious documentation because I work on a lot of projects on a lot of platforms in a lot of languages and frankly I would have a hard time coming back to an old project for updates if I didn't because I often have no recollection as to what I wrote at three in the morning in Flex for Salesforce five months ago when I've been writing Java servlets for Lotus Domino for the past two weeks.
        • Re: (Score:2, Funny)

          by StikyPad (445176)

          If that run-on explanation was an example of your "copious documentation," then I believe you just proved the GPs point.

      • by Kjella (173770)

        Luckily I've not run into many like that, but I think they divide into two groups. The naturally sloppy - which will write sloppy code too, and those that have just given up on real world human social life. I mean, the computer doesn't mind if you wear food-stained, ragged clothes and stink to high heaven. Your WoW-buddies will never see it. Cats and dogs don't seem to care and if they pee inside that'll really top off your smell. The last ones aren't sloppy, they "optimized" it away in the sense that why s

        • Upon further reflection I think sloppy code can be attributed to laziness. Laziness manifests itself in differently with different people. Some don't have good hygiene, others haven't vacuumed in months.
          • by c0lo (1497653)

            Upon further reflection I think sloppy code can be attributed to laziness.

            Laziness to think but, unfortunately, not too lazy to write code.

      • Stands to reason: character traits (of which tidyness is just one) are usually reflected in everything a person does. So yes, I believe strongly that you can judge people's approach to work ethics by observing other areas of their lives. I get my best observations during game nights: are they prone to cheat, do they use sneaky tactics, how competitive are they and how well do they cope with losing, how serious do they take the game, what's the general vibe they give off while playing, ...

        OTOH, I seem to con

    • by w0mprat (1317953)

      Back when I was getting my CS degree, I've always noticed that the cleanest coders are also the guys who didn't shower for days at a time and always wore the same clothes.

      I'll come right out and say it, the cleanest coders were the walking bacterial colonies, the fact that human fingers were pressing the keys was a mere detail.

  • Let me summarize (Score:5, Insightful)

    by elrous0 (869638) * on Monday June 13, 2011 @02:41PM (#36427360)

    Programming--You're doing it all wrong!

    • Programming--You're doing it all wrong!

      I know you're going for +5 funny...
      But what I read is "Here's some things that might be useful."
      The review was well written and I appreciated the reviewer's comments on what they found interesting.

      Sure, tech-skills are important.
      But what a lot of programmers miss is that the other topics (estimates, integrity, responsibility) are important.
      Maybe if you work on solo projects your entire life, then it doesn't matter so much.
      But social interactions really are big deal in software, just like they are wit

  • If management would reward clean code, they would get it.

    Instead they reward doing many simple tasks quickly until they realize you are getting in the way of people doing real work, and then they promote you to management.

    NO I'M NOT BITTER WHY DO YOU ASK?!?!

    • Re: (Score:3, Interesting)

      Being a manager, I am learning to hate the phrase "clean code". It seems to be a preoccupation with how code looks whilst being a distraction from what it does.

      • by immakiku (777365)

        Maintaining standards of aesthetics in your code is the cheapest and easiest way to ensure it does what it's supposed to do. Simple logic: if I have a hard time reading your code, I might misunderstand its intention and modify it the wrong way.

      • by kikito (971480)

        I have another phrase for you then: "spaghetti code". I hope you like pasta.

  • Bump this [youtube.com] while yo checkin' yo braces and semicolons...

  • In fact, when I work with teams, I teach them that if your testing "phase" finds bugs, it's a problem with your process that needs to be addressed immediately, so the concept of ensuing[sic] that QA doesn't find anything is a great concept to bring out.

    Given the number of mistakes in this sentence, along with the pompous notion that process can somehow prevent logical errors, makes me very glad I don't work with, much less for, you.

    (If you code for NASA, perhaps you have the luxury of a process that does prevent logic errors. Somewhere around 99.9999999999% of us do not.)

    • by CoryFoy (2254778)
      I think you misconstrued my point. Let's say you find a logic error during code review. That means your process is working well. Let's say another bug slips out to production. That means there is something in your process that didn't catch that. Perhaps it's more automated testing. Perhaps it's more code reviews. Perhaps it's more communication. Perhaps it's closer oversight of junior developers. The point being that when you find a bug in your QA or Production cycles, go back and look at your development p
    • by Fubari (196373)

      ... the pompous notion that process can somehow prevent logical errors

      Pompous?
      Preventing logical errors is the key idea here: Introduction to Test Driven Design (TDD) [agiledata.org].
      excerpt: If it's worth building, it's worth testing. If it's not worth testing, why are you wasting your time working on it?

      So... what's your strategy for preventing logical errors?

      • by mcmonkey (96054)

        ... the pompous notion that process can somehow prevent logical errors

        Pompous?

        Preventing logical errors is the key idea here: Introduction to Test Driven Design (TDD) [agiledata.org].

        excerpt: If it's worth building, it's worth testing. If it's not worth testing, why are you wasting your time working on it?

        So... what's your strategy for preventing logical errors?

        Yes, pompous. There are no valid blanket statements on the meaning of bugs found during testing. That would depend on the bug found. Could be a systematic issue with the development process. Could just be that people aren't always perfect.

        A bug found in testing could be due to an issue in development, an issue with the requirements, an issue with the test.

        In fact, when I work with teams, I teach them that if your testing "phase" finds bugs, it's a problem with your process that needs to be addressed immediately, so the concept of ensuing[sic] that QA doesn't find anything is a great concept to bring out.

        So if my testing finds a bug, all other work needs to stop so the problem with my process can be addressed immediately. (Even if the problem with my

      • by IICV (652597)

        Test driven design does not prevent or catch logical errors. It only helps prevent errors that come about from code not adhering to spec. If the specification itself is logically incorrect, then there is no way to write a test suite that will catch that.

        For instance, if the spec says "When A and B are both true, do essential function C" but in reality A implies ~B, it doesn't matter how awesome your test suite is, or how much coverage it has - your code will pass whatever tests you want to throw at it, but

        • by c0lo (1497653)

          For instance, if the spec says "When A and B are both true, do essential function C" but in reality A implies ~B, it doesn't matter how awesome your test suite is, or how much coverage it has - your code will pass whatever tests you want to throw at it, but in practice C will never be executed.

          Then your test suite is shit. Any test case should start with verifying the preconditions (and not actually execute the test code unless preconditions are not met). If A implies not B, a test case well constructed will always be "in error" (not failing the product to be tested, but the test environ execution).

      • by EatAtJoes (102729)

        I love unit tests as much as the next refactoring junkie, but there are very significant areas in quality assurance that TDD should not and cannot address, for instance software with emergent behavior.

        I've been the unlucky maintainer of monstrous "unit tests" that were instead huge fixtures that create an alternate universe to production. Devs would write code, then spend as much time or more getting the "unit tests" to work, then have QA find brand-new bugs.

        The TDD response is decomposition, but some solut

    • by skids (119237)

      Besides, it it plainly clear that he is behind the times. Modern industry has solved the problem of QA "finding something" by laying off the entire QA department (and treating customers as BETA testers.)

  • by DarthVain (724186) on Monday June 13, 2011 @03:06PM (#36427624)

    The problem is the inability of consumers or managers to understand the 3 part rule. Speed, Quality, Cost, pick two.

    I think the best analogy for this is furniture.

    Mennonites make great furniture. It takes a long time, and is very expensive. It is a craft, and they are craftsmen.

    IKEA makes some pretty shitty furniture but is good enough for many applications. It is cheap, and fast.

    What most consumers and managers want, is the quality and hand craftsmanship of the Mennonites, at the speed and cost of IKEA.

    Problem is, that is impossible for the most part, particularly when you start looking at very large scale applications. So when managers hire people they want the IKEA drones, and expect them to produce Mennonite quality very quickly. Bottom line is short cuts are taken, managers "risk manage", and in the end you get buggy code that is not clean at all. Particularly when you have a work force that is treated like replaceable parts, in many cases you are dealing with someone else's mess, why should you try and code cleaner?

    Anyway, none of this is new, and I am sure on small applications were individuals have more control, cleaner code is possible, however in the corporate world, given the outlook by most, I can see it being problematic.

    • by bfwebster (90513)

      "...pick two."

      If you're lucky or very good. In lots of projects, you get to pick just one. ..bruce..

      • by DarthVain (724186)

        LOL too true!

        Usually that one is "Cost" in my experience.

      • by c0lo (1497653)

        "...pick two."

        If you're lucky or very good. In lots of projects, you get to pick just one. ..bruce..

        More often than I like, you finish in picking none.

    • It's always Speed and Cost where I am. I wish it was ever quality.

    • by swordgeek (112599)

      This is true. But companies (and by extension, the hiring managers) need to understand where they're making their money.
      The Mennonites could (theoretically) give up and start making second-rate crap for the same price, and make a big short-term profit. Suddenly they could product five times as much and sell it for the same price! Until their cost-cutting caught up to them, and people quit buying their furniture at a premium.

      A company which has programming as a *primary function* needs to spend money on seri

      • by DarthVain (724186)

        While I agree with you about primary businesses, most software isn't developed for the software industry. For example, where I work might not have the primary business of programming, however they still do it in house and to a larger extent outsource it. The outsource WILL have their primary business as programming, however they will be subject to the unreasonable demands of the corporation. Which usually means features fall off the table at the sake of cost, etc... So by extension, being at the behest of t

    • by jeffmeden (135043)

      The problem is the inability of consumers or managers to understand the 3 part rule. Speed, Quality, Cost, pick two.

      I think the best analogy for this is furniture.

      Mennonites make great furniture. It takes a long time, and is very expensive. It is a craft, and they are craftsmen.

      Example fail. If Mennenites abided by your "pick two" rule and they were slow but produced high quality, they would be cheap. Instead they are expensive to boot, and are apparently working under the "Pick 1" rule.

    • Well said, sir.

    • Most of the time, cost and speed are the main drivers in software development. What some of these methods aim to do is improve quality while keeping cost and speed more or less the same. Same as in furniture: mass produced furniture used to be rather crappy but it is getting better all the time, while prices remain the same. Just compare some of the Ikea furniture of 10 years ago with what's on offer today.

      The problem with software development in large corporations is not that managers demand Mennonit
    • The problem is the inability of consumers or managers to understand the 3 part rule. Speed, Quality, Cost, pick two.

      Who will win in the market? Whoever can get Angry Birds out in two months, even though it crashes now and then, or those who take six months to deliver the same functionality with fewer (but never no) crashes? You know the answer to that as well as I do. As far as insight goes, I tend to value Dick Gabriel's "Worse is Better" paper over anything that "Uncle Bob" has written.

      The fact that Uncl

      • by Beetle B. (516615)

        Who will win in the market? Whoever can get Angry Birds out in two months, even though it crashes now and then, or those who take six months to deliver the same functionality with fewer (but never no) crashes? You know the answer to that as well as I do. As far as insight goes, I tend to value Dick Gabriel's "Worse is Better" paper over anything that "Uncle Bob" has written.

        Not sure if you're criticizing your parent, because you just made his point. Making Angry Bird with bugs quicker means the manager didn't pick all three.

    • by wrook (134116)

      I will tell you how to break this rule. Most people order 30 chairs and sit on 2 of them. They have all sorts of reasons why they need those 30 chairs: People might come over, some might break, somebody might break in a steal some of them. But in the end, they really only use 2 of them. So we spent 15 times more than we needed in both time and cost. And in the bargain, because we couldn't afford 30 *good* chairs, we made crappy ones. The crappy ones break over time and we have the added cost of dealin

  • The last thing 'coders' need is another book telling them exactly what practices they should be following. As with most things, the focus should always be on creating a working product first. After you've built something, then you can refine it and clean it up. Too often when the focus is on how it is to be completed instead of actually completing it, the latter never happens. Re-factoring is a much easier task when you already have it working, already know exactly what it should do and when, and have e
    • by timeOday (582209)
      I agree that some degree of "hack first, refactor later" is good, AFTER you have a reasonably solid foundation to build on. The problem is if you hack first and then lose the motivation or the funding to do the refactoring. Then you are stuck living with your first draft forever, and even trying to build on top of it.
    • by ChronoFish (948067) on Monday June 13, 2011 @04:00PM (#36428320) Journal
      I've been programming for about 17 years..... and I've found you can't clean code "later". Once it's working it's off to testing and then shipped/delivered. No manager wants you to refactor code unless there is a damn good reason to do it (i.e. there is a bug or enhancement). If you refactor at that time now your next project is actually two projects (a refactor project followed by an enhancement project).

      The very idea of refactoring code killed Netscape. They rewrote their underlying rendering engine- a triumph of the developers - with no (little) noticeable enhancement for the end user. Users who were developers "got it" - but the mass market did not.

      -CF
      • by wrook (134116)

        There is an important distinction between refactoring and rewriting. Refactoring is the task of changing small parts of the code so that it operates exactly the same way that it did before. Your outward facing interfaces aren't going to change much in each refactoring (although after successive refactorings it might change dramatically). Your unit tests should still run (possibly with some updating) after you have refactored the code.

        Rewriting is the task of taking a large piece of code and rewriting it

    • by Lord Grey (463613)

      While I utterly agree with your statements (and I've been programming for almost 35 years) the reality is that management usually gives coders virtually no time to clean things up. There is constant pressure to move on to the next task or project, with little thought to hardening or refactoring something that already seems to "work."

      Then, you wind up with the code you see around you and someone decides to write a book about how to "fix it."

    • by gutnor (872759)
      It depend how you define 'working'. Nowadays working should mean clean, with automated tests, little/no dead feature, little/no overengineering, no 'entreprisification', made with the right too for the job if possible, and finally coded with care (meaning coded to be read easily by fellow developer, no by tools or manager )

      If that's what you have in mind by working, that is what Robert Martin generally advocate (see the other book called Clean Code): get the stuff working in a way you don't have to worry

    • This book has no code in it. It's not about code at all. It's about coders, and the attitude they need to survive in a corporate environment. It's about being professional. About saying what you mean, and meaning what you say. It's about how to answer a manager who want's the impossible. It's about finding a way to write effective code just after you've had a big fight with your spouse. It's about all the non-coding things that programmers face every day.
    • But that is EXACTLY why 'agile' development methods place a high degree of emphasis on working code. Iteration 1 should WORK, every iteration from 1 to N should work. The early iterations of larger projects may not do anything exceptionally useful, but they have to run and pass acceptance tests. Thus you're always squarely centered on extending a working application and 'cleaning it up' (continuous integration). You never spend time working on anything that isn't part of some actual working functional part

    • The last thing 'coders' need is another book telling them exactly what practices they should be following. As with most things, the focus should always be on creating a working product first. After you've built something, then you can refine it and clean it up. Too often when the focus is on how it is to be completed instead of actually completing it, the latter never happens. Re-factoring is a much easier task when you already have it working, already know exactly what it should do and when, and have experience using it which helps break it down more intelligently.

      The problem, as your 20 years of programming experience should tell you, is that often management will never allow the "clean-it-up" so you get saddled with how you did it the first time, even if you only meant it to be a prototype. So, doing your best to get it as close to right the first time - through discipline and good practices to start with, will help you all the more in the long run.

      While I haven't RTFB, I will have to agree that more information on this topic is very, very necessary. Often, prog

  • Saying, "We'll try" means that you, or your team, isn't already giving it their best, and that through some extraordinary effort you'll pull it off.

    I say this a lot. Usually it coincides with a feeling that we have been given a task, usually using some new or otherwise unproven technology or techniques, with hazy specifications on a fixed and frankly uncomfortable timeline. Generally the first answer is no, but it becomes apparent that we don't really have a choice in the matter, our job is to do this thing. We say it just to placate ourselves and make it sound like there is no expectation of success.

    "We'll try", to me, has always translated to, "We're

    • by mcmonkey (96054)

      Saying, "We'll try" means that you, or your team, isn't already giving it their best, and that through some extraordinary effort you'll pull it off.

      I say this a lot. Usually it coincides with a feeling that we have been given a task, usually using some new or otherwise unproven technology or techniques, with hazy specifications on a fixed and frankly uncomfortable timeline. Generally the first answer is no, but it becomes apparent that we don't really have a choice in the matter, our job is to do this thing. We say it just to placate ourselves and make it sound like there is no expectation of success.

      "We'll try", to me, has always translated to, "We're doing this against our better judgement."

      I'm sort of interested in reading this book and finding out if there's more to this situation that the review detailed.

      Sounds like you're just the guy this book is for, saying you'll try when you should be saying no.

      When I say, 'I'll try,' I mean, I'll try. It means, I don't know if the request is possible given the available resources, or I have check for conflicts with existing requirements, or I'm not sure if the request is technically possible.

      "Saying, "We'll try" means that you, or your team, isn't already giving it their best". WTF is that crap? "Uncle Bob" sounds like a pompous d-bag.

      Perhaps "I'll try" means I'm o

  • by Anonymous Coward on Monday June 13, 2011 @03:38PM (#36428052)

    I've worked at 3 different companies of all sizes in the past 8 years. Every one claimed to be Agile, every one one of them produced undocumented spaghetti code that collapsed under the slightlest change request.

    "Agile" unfortunately has become an excuse for no plans, no docs and no discipline.

    Therefore, having never been employed in a real Agile environment, what about Agile lends itself to be abused this way?

    • by swb (14022)

      Agile is like "flexible" -- it's just another word thrown around that enables enough ambiguity to allow people to have it both ways.

    • by wrook (134116)

      "Agile" is a virtually meaningless phrase: People over Processes, etc, etc. What *exactly* does that mean? I've worked on some extremely good "Agile" teams. All of them have had well documented processes and extremely disciplined practitioners.

      The number of groups who prefer ad hoc development far and away outnumber the number of groups who prefer disciplined development. Ad hoc isn't even necessarily "bad". It's just "as you go". If you've got a team composed of great people, it can work. But, this

  • by ADRA (37398)

    read the book, but ANY text that enforces a mandatory set of principles to program probably has a healthy amount of:
    1.overly dogmatic approaches to solving a problem. The zealots will eat it up and constantly espouse the belief to all within ear shot, but unless institutionally mandated will probably be ignored for a variety of perfectly viable solutions. Eg. Web Session Persistence: Thou shalt never store state within a web session context and you will perform all backend processing with either cookie or D

  • To start, it looks at the Hippocratic Oath, specifically the rule of "First, Do No Harm".

    Hopefully the book is better researched than the summary suggests -- "First, do no harm" is not a part of the Hippocratic Oath.

    http://en.wikipedia.org/wiki/Hippocratic_Oath#Modern_version [wikipedia.org]
    http://en.wikipedia.org/wiki/Primum_non_nocere#Origin [wikipedia.org]

    • To start, it looks at the Hippocratic Oath, specifically the rule of "First, Do No Harm".

      I just wish that "Uncle Bob" would take the same care with the software engineering profession.

  • Question for the reviewer: is the book based on actual scientific research or is it anecdotal evidence?

    Not that there is necessarily anything wrong with anecdotes and good advice, you can learn a lot from the success of others. It's just that there's a lot of advice flying around in this trade, and not all of it has as firm a base as it sounds like, ahem, Extreme Programming, ahem. The note about staying out of the zone sounds more in the anecdotal than the scientific category to me.

    • by mcmonkey (96054)

      Question for the reviewer: is the book based on actual scientific research or is it anecdotal evidence?

      Neither.

    • by unclebobmartin (2262780) on Monday June 13, 2011 @05:40PM (#36429432) Homepage

      Question for the reviewer: is the book based on actual scientific research or is it anecdotal evidence?

      As the author, I feel able to respond. This book is a book about how to behave as a professional programmer. It is not a book about how to write code. As such it is not, and could not be based on any kind of scientific research. Rather it is based on my 40+ years of experience as a programmer, and on the mistakes I have made over that time. This book contains all the things I wish I had known when I was in my thirties.

  • "Obfuscated coding" is another way of saying "Job Security". I can remember working for a Fortune 500 company in the early 90s where they had to pay a small fortune to get retired Cobol programs to recode for Y2K. I also remember buying someone else's code sight-unseen thinking that the guy was talented only to discover that the guy had the sloppiest code I'd ever seen.

  • They are of course

    1. Never comment anything

    2. Never document ever

    3. Don't produce error messages and if you do be sure to use a number and not a human readable string

    Unfortunately it seems that way to many software engineers write their code according to those 3 laws.

  • by dugeen (1224138)
    Like all theoretical programming styles and religions, clean coding has one or two points to commend it but it would be impractical to follow it in every detail in real life. You'd end up with an unmaintainable mess of XYZArgument objects.

"Turn on, tune up, rock out." -- Billy Gibbons

Working...