10 ms·

My takeaways from "Clean Code"

45 points by webpro 13y ago

skatenerd 13y ago
output arguments are a special case of side effects?
- mc-lovin 13y ago
  The best thing about functions with no side effects and no output arguments, is they often get optimized out by the compiler.
mion 13y ago
Nice article! But I have to disagree with these: - Minimize the number of arguments - Avoid output arguments Basically, you're arguing against some principles of functional programming, advocating the use of state. There's no good or wrong with state, I think, there's only a trade-off. Heavy use of state = easier/faster to code, harder to debug/read. IMHO these kinds of generalizations are pretty dangerous. We should always try to understand the problems lying underneath in order to correctly assess the trade-offs. A quote from Elon Musk that goes something like "don't rely on analogies, try to understand the problem" popped up on HN some other day, but I'm too lazy to go look for it now. :-)
- mion 13y ago
  And also this: - Comments are fails Sometimes you rewrite code for performance, making it fast but awful to understand. Comments are very useful in this case.
  - bguthrie 13y ago
    Unless your performance optimizations specifically avoid method invocation, you can always extract the nasty bits to a well-named method. This is what is meant by comment avoidance: it is better to isolate the dirty stuff and pick good, specific names for what they do than to write an explanatory comment wherever possible.
    - mion 13y ago
      Hmm, true. But a lot of performance optimizations (and the example I had in mind) avoid method invocation. Inside a critical loop, for instance, stacking function calls can make a big difference on a dynamic language. Macros could solve this problem though.
      - mercurial 13y ago
        It's good practice to comment when necessary. Sometimes, even a "well named" method will not be expressive enough. Other times, you need to do something non-obvious (eg, work around a bug in another system). Comment when necessary. I've also found that comment tend to be both easier to maintain (due to the smaller amount of code) and more necessary (due to the higher density of information) when using more powerful languages (eg, Haskell).
  - spc476 13y ago
    I tend to comment working around bugs in third party code.
    - joshka 13y ago
      Another way would be to instead wrap the third party code (and hence isolate yourself against such bugs) and use the language of choice to highlight the design decision.
      - spc476 13y ago
        But you still need to comment about why you wrapped the code in the first place.
- miloshadzic 13y ago
  This was my reflex as well but then I remembered that Clean Code serves mostly as advice to OO programmers. In OO programming you can consider an object's attributes to be implicit parameters to a function.
- halostatue 13y ago
  This won’t win me any friends, but I personally think that Clean Code is one of the most dangerous programming books to be released in the last decade. There’s a lot of good advice in the book, but it is written by and for Java programmers, and it comes with its share of risks if you take its advice. If you’re developing in a dynamically typed OO language like Ruby, it’s almost always bad advice to follow Clean Code. There are performance considerations even with Java to following some of the advice given. With Objective C, the suggestions are just silly. With languages that emphasize some level of functional programming (including Ruby and even C# to a degree), the suggestions are counter-productive and produce code that is unnecessarily obfuscatory. Yes, it’s good to have short, readable, meaningful methods. Reducing method size too much, though, can result in code that you have to follow through many objects in order to understand the logic. If you follow Martin’s advice enough, you will end up with lots of very short methods on lots of very small objects—and have a hard time understanding just how your program fits together. If Martin were a better writer, or had expanded his horizons beyond Java when he had written this book, he may have written something profound—still dangerous, but profound. Instead, he wrote Clean Java and either he or his publisher thought it would sell more as Clean Code. My advice is to ignore the book—unless Martin comes out with a second edition that takes what he has learned in the last few years since leaving behind Java and applies it to really make a book that describes clean code.
  - rluhar 13y ago
    I agree with your premise that Clean Code is not a suitable book for all programmers / and or all languages. But a good amount of "enterprise" software is written in Java. And, in "enterprise land" (where I currently live), there are lots of mediocre, inexperienced or untrained programmers for whom the advice in Clean Code is useful. I have had to try and clean up functions that were two thousand lines long (in Java), had lots of side effects, and took in seven parameters. Oh boy did I wish the developer had read Clean Code. I agree with your premise that the book is not relevant to those who work in dynamic or functional programming languages. Frankly, I don't think they are not the intended audience. I think it is a little hyperbolic to call it the "one of the most dangerous programming books released in the last decade".
- wonderzombie 13y ago
  Basically, you're arguing against some principles of functional programming, advocating the use of state. Is that true? "Minimize the number of arguments" nudges you towards datatypes or maps instead of lists of implicitly related variables. No state there, just keeping functions relatively simple in terms of their inputs. In the latter case, "avoid output arguments" is absolutely a principle of functional programming; it says use arguments for input and return values for output. You can't do this in Haskell. I don't think you can do it in Clojure, either, or if you can, it's not really idiomatic b/c immutable. I can't speak to other Lisps with any certainty, but I've never seen it as an idiom.
  - mion 13y ago
    No state there, just keeping functions relatively simple in terms of their inputs. Yes, yes! I definitely agree but what I meant is "principles of functional programming outside functional languages". When you understand the trade-offs that these principles bring to the table, you can apply them in OO languages -- in some cases. But here he's banning it for good with that statement!
    - wonderzombie 13y ago
      With which statement? There is one which explicitly encourages side effects -- the one which says "write bar.doFoo() instead of doFoo(bar)" -- but I think it's orthogonal; you can keep your inputs and outputs simple without rewriting your code to have a lot of state.
- retrogradeorbit 13y ago
  I agree. Especially with the 'always' part: "Anyway, it is always a good programming advice to minimize the number of arguments. Zero or one argument is easiest to understand and maintain." How is one to minimize the number or arguments in a purely functional language with immutable state? How can I do tail recursion without any arguments?
rluhar 13y ago
I think the OP is spot-on on his takeaways from Clean Code. I work with a number of people who do not have a CS or Software Engineering background but are assigned to the team as "programmers". They can hack together something that will work, but often end up with a convoluted design and an almost guaranteed maintenance nightmare. Robert ("Uncle Bob") Martin's book has been really useful for us. We have been going through the book section by section and comparing the ideas in "Clean Code" to our implementations. It has been a most effective way of getting the team up to speed. I would recommend anyone who is getting started on their first software engineering job to go through the book. It is excellent study material for an inexperienced team.
- jrydberg 13y ago
  I would argue that computer scientists (academia) is the biggest offenders when it comes to writing "non-clean" code. They normally don't have any incentive to create reusable and maintainable code.
jmcdonald-ut 13y ago
> Comments are fails As the article mentions, I agree that it's good to make sure that you're naming conventions and code itself is expressive. Furthermore, if you approach coding with this philosophy you will most likely write much better code the first time around. Still some comments, written in plain (INSERT YOUR NATIVE LANGUAGE HERE), which give an executive summary of the class or method can be useful. > Avoid output arguments / Have No Side Effects This can be difficult to do in a language like C. It is convention to pass pointers to arrays, structs, etc and allow the method to change it or operate on it. Also it is normal for a method to adjust a pointer's position. With all the grief this caused me though, I do think that this is great advice for a language like Java, Ruby, etc.
- halostatue 13y ago
  It’s horrendous advice for Ruby. As I said in a different comment, this book wouldn’t annoy me if it had been called Clean Code. There’s a Ruby shop in Toronto that I interviewed with a couple of years back. As soon as I learned that they considered Clean Code a good book to be learned from, I knew that I didn’t want anything to do with their software development process (and I write very good, clean, and readable software, thank you very much).
  - jmcdonald-ut 13y ago
    As someone who is just diving into Ruby, I'm curious what specifically you think is bad advice for Ruby?
    - halostatue 13y ago
      I’m going to have to go from memory here—I borrowed someone’s copy to read a few years ago, realized that it was not a very good book, and didn’t bother buying a copy for myself (and I’m not going to “borrow” an electronic copy, either). If I don’t have some of the specifics correct, please forgive me. One of the things that stands out in my mind is a few related pieces of advice, most of which are fairly good in isolation: - prefer composition to inheritance - prefer more smaller methods (as I said elsewhere, I believe that there’s even a point where it’s suggested that a one-line method is “ideal”) - prefer smaller objects In isolation, each of these things is fairly good—but when combined, you change from a codebase of large, unreadable functions, to an unreadable codebase of lots of little, tightly-coupled, smaller objects with smaller methods all composed into doing something that would be simpler to understand as a few medium-size objects and medium-size methods. In Ruby, all of this is…fungible is the best word I can think of for this. Because of Ruby’s duck-typing, mixins, and most importantly, lambdas and blocks, the best place for your logic to reside is as close as possible to where it’s being used. This doesn’t mean write large methods—it means that all of the advice that’s given for Java written before late 2008 (when lambdas were barely a twinkle in the JSR process and Sun still mattered) doesn’t apply when you have anonymous blocks of code that you can apply immediately and functionally. The best description I’ve got for this ultimately is related to many of the things said about Gamma, et al.’s Design Patterns: in other languages, design patterns are just features that the language gives you, rather than something you have to implement. Iterators? Built into Ruby, and better because of blocks. In Ruby, you don’t need to learn the lessons given to Java programmers in 2008, because the language gives you more power and expressiveness already. Add a little bit of metaprogramming (in the same way that attr_reader/attr_writer/attr_accessor is implemented, for example) and you’ve got programs that express your intent clearly, but are nearly impossible to apply Clean Code to because you’re doing something smarter (not clever, but smart). To address the three points that I mentioned a couple of paragraphs ago: - prefer composition to inheritance: good advice, but composition in Ruby also means considering how blocks and mixins can help you understand your code better. - prefer more smaller methods: I’m not as sold on this; the more methods you have, even if they’re private, the harder it is to understand just how your code works because you now have a larger API to understand. (And, like someone else in this conversation, I’ve had to deal with 2+kloc functions in other languages; I just haven’t had that happen in Ruby, where the largest functions that I’ve dealt with are in the low hundreds—and those are very rare but focussed functions (e.g., a lot of error handling where you don’t necessarily want to introduce state that lives outside of the function). - prefer smaller objects: As with smaller methods, I’m not as sold on this. The more objects you have, the more interface you have to remember, the harder it is to remember how to compose everything back into the logic you’re trying to implement. By all means, extract code—DHH’s advice on what they’re calling “concerns” in Rails is very good (I’ve already done that with more than a small bit of our current Rails application; I’ve also done it with other code over time).
jcampbell1 13y ago
> Zero or one argument is easiest to understand and maintain. > Have No Side Effects Can someone explain how you use zero argument functions that doesn't have side effects? I am trying to wrap my head around these two statements.
- jacques_chester 13y ago
  1. They're not orthogonal rules. 2. Some functions are queries that don't require an arguments. Eg. getVariable().
  - jcampbell1 13y ago
    I just find that minimizing parameters makes a mess with tons of side effects. When I see nothing but 0 and 1 parameter functions, the code is typically doing the logical equivalent of refactoring `add(a,b);` into `push(a);push(b);add();` which makes a mess when there is more than the trivial case. jQuery.ajax is a 33 parameter function. No one complains, and it is nice that it doesn't have side effects.
    - jacques_chester 13y ago
      Sure. Usually when you find a strict rule, it's a rule to be considered ceteris paribus -- when all other things are fixed in place. So while thinking about parameters, I think about minimising them and ignore other considerations. When thinking about side-effects, I think about minimising them and ignore other considerations. It's when the rules conflict that mere rule-following ends and professional judgement begins. Basically, as noted legal scholar Captain Barbossa observed, they're less like laws and more like guidelines.
- dack 13y ago
  You could have a method on a class that uses it's own fields to do some calculation. So, although it does have access to the fields on the class, it takes no arguments and has no side effects. You could certainly argue that a class's fields are a form of input arguments to a method, and I would agree - which is why another good rule of thumb is to not have too many of those either! Obviously, it's a balance, so none of the rules can be taken without context to the situation - they are all just smells that you should "back away from" if you're finding yourself breaking any given rule too much.
jacques_chester 13y ago
As an uncontroversial remark, I preferred Code Complete (I have both editions). McConnell has a gift for distilling research[1] into chatty, easy-to-read material. It's been nearly 10 years since the 2nd edition, which sat uncomfortably athwart the tectonic shift to agile practices. If I had a magic wand there'd be a 3rd edition based on what's been learned since 2004 (and a 2nd edition of Rapid Development, which he is at least considering[2]). [1] Yes, I know most software engineering research sucks. But a lot of it is better than stuff found in The Journal of Gross Oversimplifications Conveyed in 140 Characters or Less. [2] http://www.stevemcconnell.com/projects-newbooks.htm http://www.stevemcconnell.com/projects-newbooks.htm
- mercurial 13y ago
  Agreed. Illustrating a point with the results of an experiment is more instructive than "you should do this, because it works for me".
xkcdfanboy 13y ago
Don’t Pass Null? This is idiotic if you want performant code and don't want to have to use static empty object constants littered throughout your code. Null is perfectly fine in place of an object. The author mentions this saves you debugging time. No, it will cause you pain later because you won't see errors that should happen. Instead they are masked by operating on some dummy object that you don't give a rats ass about.
- spc476 13y ago
  Don't pass NULL (but do collect $200). For modules I write in C, I only have one function that can return NULL---the function that creates a new structure. All other functions that work with that structure assume (backed by an assert()) that the passed in pointer will not be NULL. For the code I write, there is no reason for functions to accept a NULL pointer. And it's less painful that it sounds. I got the idea from _Writing Solid Code_, one of only two books that fundamentally changed how I write code (the other being _Thinking Forth_).
- mercurial 13y ago
  I'm sold on "don't pass null" for collections. Return empty collections instead of null, this saves you from a world of pain, and it reduces the code size. The right way to work around null for scalar variables is to use Maybe/Option, preferably in a language with pattern matching, as opposed to using "magic values" like 0 or the empty string. This means removing null pointer errors by construction.
programminggeek 13y ago
I haven't read "Clean Code", but I grokked through a bunch of Uncle Bob's stuff in creating Obvious Architecture and I have to say that I think that many programmers don't/won't get what Uncle Bob is going on about because many programmers want to take the parts they agree with and throw away the rest in the name of "pragmatism". In reality, Uncle Bob's stuff is actually better when taken holistically and when applied together, but it's hard to do and when taken to their logical conclusion, it is so outside the norms of OOP, that people freak out about it not being "proper OOP" as they were taught in university and in mainstream things.
tdonaghe 13y ago
No other book has had as large an impact on HOW I write code than Clean Code. My code today looks radically different from how it looked 3 years ago.
cocoflunchy 13y ago
Flag arguments are ugly Perhaps the only exception is for specific setters that directly set the value of an object property (flag?) itself. But I have to agree that flags implicitly mean that the method is probably doing too much (e.g. there is no Command Query Separation). Can someone elaborate on this (I'm not sure what he means by 'flag argument') ?
- spc476 13y ago
  Take the Unix system call open(). It accepts multiple flags, to open the file read-only, write-only, read-write, append (only meaningful if writing), truncate (only meaningful on a write-only open), create (again, only really meaningful on a write-only open) along with about half a dozen other flags that can be looked up. The sheer number of flags can lead to weird issues (what does it mean to open a file for read-only and truncate it? The man page I'm reading leads me to believe it does something other than return an error) and hard to test (I count fifteen flags, which gives 32,768 paths through the code).
losethos 13y ago
This is retarded. People talk about programming instead of doing it. Best advice is to do it and do it more. You learn. I hate all the gurus. They want to explain how to take a shit. Why don't you tell your boss to make the problem simpler so you can use one or two arguments. ---- God says... 2:25 The children of Kirjatharim, Chephirah, and Beeroth, seven hundred and forty and three. 2:26 The children of Ramah and Gaba, six hundred twenty and one. 2:27 The men of Michmas, an hundred twenty and two. 2:28 The men of Bethel and Ai, two hundred twenty and three. 2:29 The children of Nebo, fifty and two. 2:30 The children of Magbish, an hundred fifty and six. 2:31 The children of the other Elam, a thousand two hundred fifty and four.

45 points by webpro 13y ago

skatenerd 13y ago

output arguments are a special case of side effects?

mc-lovin 13y ago
The best thing about functions with no side effects and no output arguments, is they often get optimized out by the compiler.

mion 13y ago

Nice article! But I have to disagree with these: - Minimize the number of arguments - Avoid output arguments Basically, you're arguing against some principles of functional programming, advocating the use of state. There's no good or wrong with state, I think, there's only a trade-off. Heavy use of state = easier/faster to code, harder to debug/read. IMHO these kinds of generalizations are pretty dangerous. We should always try to understand the problems lying underneath in order to correctly assess the trade-offs. A quote from Elon Musk that goes something like "don't rely on analogies, try to understand the problem" popped up on HN some other day, but I'm too lazy to go look for it now. :-)

mion 13y ago
And also this: - Comments are fails Sometimes you rewrite code for performance, making it fast but awful to understand. Comments are very useful in this case.
- bguthrie 13y ago
  Unless your performance optimizations specifically avoid method invocation, you can always extract the nasty bits to a well-named method. This is what is meant by comment avoidance: it is better to isolate the dirty stuff and pick good, specific names for what they do than to write an explanatory comment wherever possible.
  - mion 13y ago
    Hmm, true. But a lot of performance optimizations (and the example I had in mind) avoid method invocation. Inside a critical loop, for instance, stacking function calls can make a big difference on a dynamic language. Macros could solve this problem though.
    - mercurial 13y ago
      It's good practice to comment when necessary. Sometimes, even a "well named" method will not be expressive enough. Other times, you need to do something non-obvious (eg, work around a bug in another system). Comment when necessary. I've also found that comment tend to be both easier to maintain (due to the smaller amount of code) and more necessary (due to the higher density of information) when using more powerful languages (eg, Haskell).
- spc476 13y ago
  I tend to comment working around bugs in third party code.
  - joshka 13y ago
    Another way would be to instead wrap the third party code (and hence isolate yourself against such bugs) and use the language of choice to highlight the design decision.
    - spc476 13y ago
      But you still need to comment about why you wrapped the code in the first place.
miloshadzic 13y ago
This was my reflex as well but then I remembered that Clean Code serves mostly as advice to OO programmers. In OO programming you can consider an object's attributes to be implicit parameters to a function.
halostatue 13y ago
This won’t win me any friends, but I personally think that Clean Code is one of the most dangerous programming books to be released in the last decade. There’s a lot of good advice in the book, but it is written by and for Java programmers, and it comes with its share of risks if you take its advice. If you’re developing in a dynamically typed OO language like Ruby, it’s almost always bad advice to follow Clean Code. There are performance considerations even with Java to following some of the advice given. With Objective C, the suggestions are just silly. With languages that emphasize some level of functional programming (including Ruby and even C# to a degree), the suggestions are counter-productive and produce code that is unnecessarily obfuscatory. Yes, it’s good to have short, readable, meaningful methods. Reducing method size too much, though, can result in code that you have to follow through many objects in order to understand the logic. If you follow Martin’s advice enough, you will end up with lots of very short methods on lots of very small objects—and have a hard time understanding just how your program fits together. If Martin were a better writer, or had expanded his horizons beyond Java when he had written this book, he may have written something profound—still dangerous, but profound. Instead, he wrote Clean Java and either he or his publisher thought it would sell more as Clean Code. My advice is to ignore the book—unless Martin comes out with a second edition that takes what he has learned in the last few years since leaving behind Java and applies it to really make a book that describes clean code.
- rluhar 13y ago
  I agree with your premise that Clean Code is not a suitable book for all programmers / and or all languages. But a good amount of "enterprise" software is written in Java. And, in "enterprise land" (where I currently live), there are lots of mediocre, inexperienced or untrained programmers for whom the advice in Clean Code is useful. I have had to try and clean up functions that were two thousand lines long (in Java), had lots of side effects, and took in seven parameters. Oh boy did I wish the developer had read Clean Code. I agree with your premise that the book is not relevant to those who work in dynamic or functional programming languages. Frankly, I don't think they are not the intended audience. I think it is a little hyperbolic to call it the "one of the most dangerous programming books released in the last decade".
wonderzombie 13y ago
Basically, you're arguing against some principles of functional programming, advocating the use of state. Is that true? "Minimize the number of arguments" nudges you towards datatypes or maps instead of lists of implicitly related variables. No state there, just keeping functions relatively simple in terms of their inputs. In the latter case, "avoid output arguments" is absolutely a principle of functional programming; it says use arguments for input and return values for output. You can't do this in Haskell. I don't think you can do it in Clojure, either, or if you can, it's not really idiomatic b/c immutable. I can't speak to other Lisps with any certainty, but I've never seen it as an idiom.
- mion 13y ago
  No state there, just keeping functions relatively simple in terms of their inputs. Yes, yes! I definitely agree but what I meant is "principles of functional programming outside functional languages". When you understand the trade-offs that these principles bring to the table, you can apply them in OO languages -- in some cases. But here he's banning it for good with that statement!
  - wonderzombie 13y ago
    With which statement? There is one which explicitly encourages side effects -- the one which says "write bar.doFoo() instead of doFoo(bar)" -- but I think it's orthogonal; you can keep your inputs and outputs simple without rewriting your code to have a lot of state.
retrogradeorbit 13y ago
I agree. Especially with the 'always' part: "Anyway, it is always a good programming advice to minimize the number of arguments. Zero or one argument is easiest to understand and maintain." How is one to minimize the number or arguments in a purely functional language with immutable state? How can I do tail recursion without any arguments?

rluhar 13y ago

I think the OP is spot-on on his takeaways from Clean Code. I work with a number of people who do not have a CS or Software Engineering background but are assigned to the team as "programmers". They can hack together something that will work, but often end up with a convoluted design and an almost guaranteed maintenance nightmare. Robert ("Uncle Bob") Martin's book has been really useful for us. We have been going through the book section by section and comparing the ideas in "Clean Code" to our implementations. It has been a most effective way of getting the team up to speed. I would recommend anyone who is getting started on their first software engineering job to go through the book. It is excellent study material for an inexperienced team.

jrydberg 13y ago
I would argue that computer scientists (academia) is the biggest offenders when it comes to writing "non-clean" code. They normally don't have any incentive to create reusable and maintainable code.

jmcdonald-ut 13y ago

> Comments are fails As the article mentions, I agree that it's good to make sure that you're naming conventions and code itself is expressive. Furthermore, if you approach coding with this philosophy you will most likely write much better code the first time around. Still some comments, written in plain (INSERT YOUR NATIVE LANGUAGE HERE), which give an executive summary of the class or method can be useful. > Avoid output arguments / Have No Side Effects This can be difficult to do in a language like C. It is convention to pass pointers to arrays, structs, etc and allow the method to change it or operate on it. Also it is normal for a method to adjust a pointer's position. With all the grief this caused me though, I do think that this is great advice for a language like Java, Ruby, etc.

halostatue 13y ago
It’s horrendous advice for Ruby. As I said in a different comment, this book wouldn’t annoy me if it had been called Clean Code. There’s a Ruby shop in Toronto that I interviewed with a couple of years back. As soon as I learned that they considered Clean Code a good book to be learned from, I knew that I didn’t want anything to do with their software development process (and I write very good, clean, and readable software, thank you very much).
- jmcdonald-ut 13y ago
  As someone who is just diving into Ruby, I'm curious what specifically you think is bad advice for Ruby?
  - halostatue 13y ago
    I’m going to have to go from memory here—I borrowed someone’s copy to read a few years ago, realized that it was not a very good book, and didn’t bother buying a copy for myself (and I’m not going to “borrow” an electronic copy, either). If I don’t have some of the specifics correct, please forgive me. One of the things that stands out in my mind is a few related pieces of advice, most of which are fairly good in isolation: - prefer composition to inheritance - prefer more smaller methods (as I said elsewhere, I believe that there’s even a point where it’s suggested that a one-line method is “ideal”) - prefer smaller objects In isolation, each of these things is fairly good—but when combined, you change from a codebase of large, unreadable functions, to an unreadable codebase of lots of little, tightly-coupled, smaller objects with smaller methods all composed into doing something that would be simpler to understand as a few medium-size objects and medium-size methods. In Ruby, all of this is…fungible is the best word I can think of for this. Because of Ruby’s duck-typing, mixins, and most importantly, lambdas and blocks, the best place for your logic to reside is as close as possible to where it’s being used. This doesn’t mean write large methods—it means that all of the advice that’s given for Java written before late 2008 (when lambdas were barely a twinkle in the JSR process and Sun still mattered) doesn’t apply when you have anonymous blocks of code that you can apply immediately and functionally. The best description I’ve got for this ultimately is related to many of the things said about Gamma, et al.’s Design Patterns: in other languages, design patterns are just features that the language gives you, rather than something you have to implement. Iterators? Built into Ruby, and better because of blocks. In Ruby, you don’t need to learn the lessons given to Java programmers in 2008, because the language gives you more power and expressiveness already. Add a little bit of metaprogramming (in the same way that attr_reader/attr_writer/attr_accessor is implemented, for example) and you’ve got programs that express your intent clearly, but are nearly impossible to apply Clean Code to because you’re doing something smarter (not clever, but smart). To address the three points that I mentioned a couple of paragraphs ago: - prefer composition to inheritance: good advice, but composition in Ruby also means considering how blocks and mixins can help you understand your code better. - prefer more smaller methods: I’m not as sold on this; the more methods you have, even if they’re private, the harder it is to understand just how your code works because you now have a larger API to understand. (And, like someone else in this conversation, I’ve had to deal with 2+kloc functions in other languages; I just haven’t had that happen in Ruby, where the largest functions that I’ve dealt with are in the low hundreds—and those are very rare but focussed functions (e.g., a lot of error handling where you don’t necessarily want to introduce state that lives outside of the function). - prefer smaller objects: As with smaller methods, I’m not as sold on this. The more objects you have, the more interface you have to remember, the harder it is to remember how to compose everything back into the logic you’re trying to implement. By all means, extract code—DHH’s advice on what they’re calling “concerns” in Rails is very good (I’ve already done that with more than a small bit of our current Rails application; I’ve also done it with other code over time).

jcampbell1 13y ago

> Zero or one argument is easiest to understand and maintain. > Have No Side Effects Can someone explain how you use zero argument functions that doesn't have side effects? I am trying to wrap my head around these two statements.

jacques_chester 13y ago
1. They're not orthogonal rules. 2. Some functions are queries that don't require an arguments. Eg. getVariable().
- jcampbell1 13y ago
  I just find that minimizing parameters makes a mess with tons of side effects. When I see nothing but 0 and 1 parameter functions, the code is typically doing the logical equivalent of refactoring `add(a,b);` into `push(a);push(b);add();` which makes a mess when there is more than the trivial case. jQuery.ajax is a 33 parameter function. No one complains, and it is nice that it doesn't have side effects.
  - jacques_chester 13y ago
    Sure. Usually when you find a strict rule, it's a rule to be considered ceteris paribus -- when all other things are fixed in place. So while thinking about parameters, I think about minimising them and ignore other considerations. When thinking about side-effects, I think about minimising them and ignore other considerations. It's when the rules conflict that mere rule-following ends and professional judgement begins. Basically, as noted legal scholar Captain Barbossa observed, they're less like laws and more like guidelines.
dack 13y ago
You could have a method on a class that uses it's own fields to do some calculation. So, although it does have access to the fields on the class, it takes no arguments and has no side effects. You could certainly argue that a class's fields are a form of input arguments to a method, and I would agree - which is why another good rule of thumb is to not have too many of those either! Obviously, it's a balance, so none of the rules can be taken without context to the situation - they are all just smells that you should "back away from" if you're finding yourself breaking any given rule too much.

jacques_chester 13y ago

As an uncontroversial remark, I preferred Code Complete (I have both editions). McConnell has a gift for distilling research[1] into chatty, easy-to-read material. It's been nearly 10 years since the 2nd edition, which sat uncomfortably athwart the tectonic shift to agile practices. If I had a magic wand there'd be a 3rd edition based on what's been learned since 2004 (and a 2nd edition of Rapid Development, which he is at least considering[2]). [1] Yes, I know most software engineering research sucks. But a lot of it is better than stuff found in The Journal of Gross Oversimplifications Conveyed in 140 Characters or Less. [2] http://www.stevemcconnell.com/projects-newbooks.htm http://www.stevemcconnell.com/projects-newbooks.htm

mercurial 13y ago
Agreed. Illustrating a point with the results of an experiment is more instructive than "you should do this, because it works for me".

xkcdfanboy 13y ago

Don’t Pass Null? This is idiotic if you want performant code and don't want to have to use static empty object constants littered throughout your code. Null is perfectly fine in place of an object. The author mentions this saves you debugging time. No, it will cause you pain later because you won't see errors that should happen. Instead they are masked by operating on some dummy object that you don't give a rats ass about.

spc476 13y ago
Don't pass NULL (but do collect $200). For modules I write in C, I only have one function that can return NULL---the function that creates a new structure. All other functions that work with that structure assume (backed by an assert()) that the passed in pointer will not be NULL. For the code I write, there is no reason for functions to accept a NULL pointer. And it's less painful that it sounds. I got the idea from _Writing Solid Code_, one of only two books that fundamentally changed how I write code (the other being _Thinking Forth_).
mercurial 13y ago
I'm sold on "don't pass null" for collections. Return empty collections instead of null, this saves you from a world of pain, and it reduces the code size. The right way to work around null for scalar variables is to use Maybe/Option, preferably in a language with pattern matching, as opposed to using "magic values" like 0 or the empty string. This means removing null pointer errors by construction.

programminggeek 13y ago

I haven't read "Clean Code", but I grokked through a bunch of Uncle Bob's stuff in creating Obvious Architecture and I have to say that I think that many programmers don't/won't get what Uncle Bob is going on about because many programmers want to take the parts they agree with and throw away the rest in the name of "pragmatism". In reality, Uncle Bob's stuff is actually better when taken holistically and when applied together, but it's hard to do and when taken to their logical conclusion, it is so outside the norms of OOP, that people freak out about it not being "proper OOP" as they were taught in university and in mainstream things.

tdonaghe 13y ago

No other book has had as large an impact on HOW I write code than Clean Code. My code today looks radically different from how it looked 3 years ago.

cocoflunchy 13y ago

Flag arguments are ugly Perhaps the only exception is for specific setters that directly set the value of an object property (flag?) itself. But I have to agree that flags implicitly mean that the method is probably doing too much (e.g. there is no Command Query Separation). Can someone elaborate on this (I'm not sure what he means by 'flag argument') ?

spc476 13y ago
Take the Unix system call open(). It accepts multiple flags, to open the file read-only, write-only, read-write, append (only meaningful if writing), truncate (only meaningful on a write-only open), create (again, only really meaningful on a write-only open) along with about half a dozen other flags that can be looked up. The sheer number of flags can lead to weird issues (what does it mean to open a file for read-only and truncate it? The man page I'm reading leads me to believe it does something other than return an error) and hard to test (I count fifteen flags, which gives 32,768 paths through the code).

losethos 13y ago

This is retarded. People talk about programming instead of doing it. Best advice is to do it and do it more. You learn. I hate all the gurus. They want to explain how to take a shit. Why don't you tell your boss to make the problem simpler so you can use one or two arguments. ---- God says... 2:25 The children of Kirjatharim, Chephirah, and Beeroth, seven hundred and forty and three. 2:26 The children of Ramah and Gaba, six hundred twenty and one. 2:27 The men of Michmas, an hundred twenty and two. 2:28 The men of Bethel and Ai, two hundred twenty and three. 2:29 The children of Nebo, fifty and two. 2:30 The children of Magbish, an hundred fifty and six. 2:31 The children of the other Elam, a thousand two hundred fifty and four.