Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My takeaways from "Clean Code"

medium.com

Post reply on HN
Print view View original

11–20 of 60 posts

Re: My takeaways from "Clean Code"

#11

Post by jmcdonald-ut »

halostatue wrote: post #10
jmcdonald-ut wrote: post #6

> 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…

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 s…

As someone who is just diving into Ruby, I'm curious what specifically you think is bad advice for Ruby?

Re: My takeaways from "Clean Code"

#12

Post by jcampbell1 »

> 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.

Re: My takeaways from "Clean Code"

#13

Post by jacques_chester »

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

Re: My takeaways from "Clean Code"

#14

Post by wonderzombie »

mion wrote: post #3

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 shoul…

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.

Re: My takeaways from "Clean Code"

#15

Post by jacques_chester »

jcampbell1 wrote: post #12

> 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.

1. They're not orthogonal rules.

2. Some functions are queries that don't require an arguments. Eg. getVariable().

Re: My takeaways from "Clean Code"

#16

Post by rluhar »

halostatue wrote: post #9
mion wrote: post #3

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 shoul…

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…

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".

Re: My takeaways from "Clean Code"

#17

Post by paragraft »

halostatue wrote: post #9
mion wrote: post #3

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 shoul…

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…

I came here to say something similar, but you took the words out of my mouth. My experience reading through it was it was a mix of good advice with some questionable advice, some advice that was really only good for Java, and some advice that was terrible. The problem is it's pitched at an audience that may not be able to discern the differences between the above. The multiple authors (on a per-chapter basis) doesn't help.

Generally speaking, the earlier chapters were better, but my advice would echo yours: give it a miss, especially if you're not working in Java.

Re: My takeaways from "Clean Code"

#18

Post by mion »

bguthrie wrote: post #7
mion wrote: post #5

Earlier quoted context omitted.

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.

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.

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.

Re: My takeaways from "Clean Code"

#19

Post by dack »

jcampbell1 wrote: post #12

> 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.

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.

Re: My takeaways from "Clean Code"

#20

Post by gizmo686 »

jcampbell1 wrote: post #12

> 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.

I think it is all suggestions, not hard rules. Also, given that the quote allows you to use up to 1 argument, it is actually trivial to do (assuming you are fine with the no side effects part). The trick is that instead of taking 2 parameters, you take 1 parameter, than generate and return a function that takes 1 parameter. Probably not what the author has in mind.

Anyway, in the context of the rest of the post, it looks like object oriented programming is being discussed, in which case I think the implicit 'self' does not count as a parameter.

Post reply on HN