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).
My takeaways from "Clean Code"
41–50 of 60 posts
Re: My takeaways from "Clean Code"
#42This 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.
Re: My takeaways from "Clean Code"
#43Flag 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') ?
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).
Re: My takeaways from "Clean Code"
#44Don’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…
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_).
Re: My takeaways from "Clean Code"
#45Nice 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…
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.
I tend to comment working around bugs in third party code.
Re: My takeaways from "Clean Code"
#46Earlier quoted context omitted.
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.
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).
Re: My takeaways from "Clean Code"
#47I 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 th…
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.
Re: My takeaways from "Clean Code"
#48Earlier quoted context omitted.
As someone who is just diving into Ruby, I'm curious what specifically you think is bad advice for Ruby?
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 iso…
As someone who has had to deal with huge methods in PHP - high-level dynamic languages are not immune from incompetent programmers. "Prefer smaller methods" is usually good advice (or as I prefer to think about it, methods with smaller logic). Especially when you feel tempted to put comments inside your bigger method - it's a sign that it's getting too big.
Re: My takeaways from "Clean Code"
#49Don’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…
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.
Re: My takeaways from "Clean Code"
#50As 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 h…
Agreed. Illustrating a point with the results of an experiment is more instructive than "you should do this, because it works for me".