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

31–40 of 60 posts

Re: My takeaways from "Clean Code"

#31

Post by derefr »

rluhar wrote: post #16
halostatue wrote: post #9

Earlier quoted context omitted.

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

> those who work in dynamic or functional programming languages ... are not the intended audience

I don't understand how a book that professes to be top-down advice about software craftsmanship as a discipline can be intended only for a specific subset of programmers. Shouldn't choosing a language be as much a part of software craftsmanship as how you use that language?

It's like writing a book entitled "Good Woodworking" which implicitly assumes you'll be using only double-clawed hammers[1]. Wouldn't you expect a book called "Good Woodworking" to start with a chapter on good tools?

[1] http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

Re: My takeaways from "Clean Code"

#32

Post by gruseom »

jasonlotito wrote: post #21
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.

Having no side effects doesn't mean it can't do something. Only that it shouldn't do anything unexpected. storeItem.makeAvailable(); That should only make the store item available. It shouldn't re-enable a sale that was on the storeItem when it was made unavailable.

That's a zero-argument method but not a zero-argument function. That is, if you view makeAvailable as a function, storeItem is an implicit argument to it. In fact, storeItem is probably an object with several fields, so there are arguably several implicit arguments. To my eye, the name "makeAvailable" suggests a side-effect too.

In any case, it's fine for two rules such as "avoid side effects" and "prefer zero- or single-argument functions" to be in tension with one another. I don't buy that zero-or-one idea, though. A function should have as many arguments as it makes sense for it to have.

Re: My takeaways from "Clean Code"

#33

Post by colomon »

jasonlotito wrote: post #21
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.

Having no side effects doesn't mean it can't do something. Only that it shouldn't do anything unexpected. storeItem.makeAvailable(); That should only make the store item available. It shouldn't re-enable a sale that was on the storeItem when it was made unavailable.

Isn't that a side effect?

Re: My takeaways from "Clean Code"

#34

Post by ruficornis »

colomon wrote: post #33
jasonlotito wrote: post #21

Earlier quoted context omitted.

Having no side effects doesn't mean it can't do something. Only that it shouldn't do anything unexpected. storeItem.makeAvailable(); That should only make the store item available. It shouldn't re-enable a sale that was on the storeItem when it was made unavailable.

Isn't that a side effect?

That is more of an effect, not a side effect, no? Something still happens, but nothing very unexcpected. If a doctor gives you medicine for an ailment, you don't want it to have many side effects, but it intended effect is still desired (theoretically). Prehaps it should effect only what it needs to in order to give you or the next step it's output, not changing some finite machine state (unless...)

Re: My takeaways from "Clean Code"

#35

Post by blazespin »

colomon wrote: post #33
jasonlotito wrote: post #21

Earlier quoted context omitted.

Having no side effects doesn't mean it can't do something. Only that it shouldn't do anything unexpected. storeItem.makeAvailable(); That should only make the store item available. It shouldn't re-enable a sale that was on the storeItem when it was made unavailable.

Isn't that a side effect?

Yeah, pretty much. I generally agree with this definition: http://en.wikipedia.org/wiki/Side_effect_(computer_science)

I think instead of "side effect" the author should have used the more traditional term of cohesion:

http://en.wikipedia.org/wiki/Cohesion_(computer_science)

Re: My takeaways from "Clean Code"

#36

Post by colomon »

ruficornis wrote: post #34
colomon wrote: post #33

Earlier quoted context omitted.

Isn't that a side effect?

That is more of an effect, not a side effect, no? Something still happens, but nothing very unexcpected. If a doctor gives you medicine for an ailment, you don't want it to have many side effects, but it intended effect is still desired (theoretically). Prehaps it should effect only what it needs to in order to give you or the next step it's output, not changing some finite machine state (unless...)

That's not how I've usually seen the term side effect used in CS: http://en.wikipedia.org/wiki/Side_effect_(computer_science)

In jasonlotito's example, he's definitely modifying state.

(Mind you, I don't think side effects should be banned outright or anything like that. But minimizing them is frequently a nice idea.)

Re: My takeaways from "Clean Code"

#37

Post by raylu »

dack wrote: post #19
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…

And what is it doing with that calculation?

Re: My takeaways from "Clean Code"

#38

Post by gfunk911 »

raylu wrote: post #37
dack wrote: post #19

Earlier quoted context omitted.

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…

And what is it doing with that calculation?

Returning it.

Re: My takeaways from "Clean Code"

#40

Post by ruficornis »

colomon wrote: post #36
ruficornis wrote: post #34

Earlier quoted context omitted.

That is more of an effect, not a side effect, no? Something still happens, but nothing very unexcpected. If a doctor gives you medicine for an ailment, you don't want it to have many side effects, but it intended effect is still desired (theoretically). Prehaps it should effect only what it needs to in order to give you or the next step it's output, not changing some finite machine state (unless...)

That's not how I've usually seen the term side effect used in CS: http://en.wikipedia.org/wiki/Side_effect_(computer_science) In jasonlotito's example, he's definitely modifying state. (Mind you, I don't think side effects should be banned outright or anything like that. But minimizing them is frequently a nice idea.)

Sorry, I was wrong. I did not read the comment closely nor was I familiar with the CS definition. Thank you for the information.
Post reply on HN