My initial reaction was 'Why did you buy it?'. I have strong recollection of the entire book being published in the public domain, but can't find any reference of it. If not this title then something else Norvig contributed too.

Any ideas what the title could be?

Speaking of books. I just found out new work has access to safari books online for us

Ugh, this guy on Programmers.SE is having a pissing match with me. I'm done with it at this point, but it is impressive to see his inability to look at something from a different perspective.

The question is about the fact that How to Learn Python the Hard Way say ever if should have an else.
The whole things has gone like this:
Him: This is stupid and pointless.
Me: I agree, but given the context, I can see why the author is saying it.
Repeat.

The internet is full of people who become inflexible bastards on stupid little points that don't mean anything in the long run. You can't win an argument with them because they aren't arguing, they are just being nits. Sometimes they are fun to troll because usually their heads blowed up real good, but the only way to win is to make your point, stop engaging and hope their kookiness isn't catching.

He's wrong, but you could do a better job of explaining why he is wrong. His example, for instance:

if result>10000: salary+=bonus else /*sorry no bonus*/

is better written as

if result>10000: total_comp = salary + bonus else total_comp = salary

Now, in real life, an experienced developer doesn't need to be forced to do this for a trivial piece of code, but you see how he never realized that he put up a piece of problematic code that is improved by following the rule he ridicules? This sort of proves Zed Shaw's point that being forced to use else forces you to understand.

In a lot of languages where mutability isn't available or guaranteed to be available or considered a necessary eye-sore (Haskell, ML, Scala, Clojure, etc), you would actually write code this way.

The funny thing is that I have a feeling some money will be wasted to counter this potential thread (yes I think IP crusaders are that dumb)...vaporware-warfare...one step ahead of the curve

I always prefer real books for stuff I might work on for a longish time (or in maniac sprees). It's also sort of a classic so not bad to have around. I don't like ebooks for most IT related stuff because I can't browse it as well as I'd like (maybe there's some tools/tricks I should learn, I use my kindle in a very non-poweruser way). I also get distracted too much working with PDFs or internet resources. With a book I can sit down and "study" while being in some sort of zone. ADS+ebooks is horrible haha.

---snip---
Maybe I'm not a testing guru but I tried to TDD prototype a little game because I wanted to test Ruby+Gosu and I have a draw method that kind of looks like this:
I want to have a test along the line of
Kind of hard to say what I want but how do I actually test that the stuff I want is drawn? I guess I should compare the surface before and after the draw somehow and see they are not equal? Other ideas? Basically I want to say "make sure that inside the draw method X,Y,Z is drawn (i.e. some other methods that do this are called)" and then also "check that said methods draw stuff correctly"
I guess I could also check that a certain region has a certain color after the draw takes place or something.

On a related note it kind of sucks to have a ton of stuff public but I kind of need attr_accessor for variables just so I can access them from tests.

Well said. They are unwittingly working out emotional problems while believing they are arguing some point, or rectifying some wrong. In some cases, it would not be overly melodramatic to say they have a kind of disease which drives them to infect others through nitpicking and fighting. The only way to avoid infection is to keep your distance.

Meh, I basically agree with the ammo guy and didn't find him that difficult (only two posts in your answer's thread - in internet world that's like a pleasant chat over afternoon tea).

Anyone care to help me figure out why I can't ever seem to get overrides for my classes in visual studio mfc.

Example - Created a dialog.
Added buttons and statics
Right clicked and added the class for the ctrl.

I can now instantiate the class and do
ClassName jeff
jeff.DoModal();

That works fine.

Then I want to make the dialog green so I go to override OnCtlColor()
Go to class view, get the properties of the form I just created.

Click overrides. All empty.

I also can never seem to create handlers on buttons etc,
Any ideas?

I can do it by hand but spending a day to design 3 screens seems insane.

He's basically saying "since once you learn how to do this you'll never do something like this there is never, ever, ever, any reason to do this while you're learning it." Which is just wrong and assumes everyone learns like he does or he's forgotten what it's like to be a newb.

I'm a little worried responding.

I think he was actually attacking this particular rule even for beginners. I tend to agree that even though there are some good benefits for beginners following this rule - overall its a bad thing even for students to do.

Hi jjshabado,

I think you may have missed my post on the issue, but I'd argue the exact opposite - even experienced coders could improve their code quality by being forced the follow the rule. See my example above!

i guess you're suggesting that keeping the salary and bonus variables separate is worthwhile. why?

First, I'm not saying there are no places where it makes sense to add the else. There are probably lots of good examples. I'm saying that overall it seems to me that as a rule it will do more harm than good (even for beginners).

Second, I disagree with your actual example that this is better than the first thing you wrote:

You're repeating yourself. If you add something else (like overtime) you now need to add it in two places. You're mixing up logic for overall compensation with specific bonus logic (comparing salary to 10,000). On top of that you're making the code longer which I don't like (without a reason).

Now, don't get me wrong - this whole rule is definitely a minor issue.

This is definitely wrong - in his code, variable "salary" has a different meaning in two places, before the if statement and after the if-statement. Before the statement, it means salary, afterwards it means compensation including bonus. Because the programmer was too lazy to introduce a separate variable for a different concept. Not that this is unacceptable as a matter of course, but it obscures meaning. Should he ever need to use salary for any other purpose and if he programs in that manner going forward, he needs to go back and look at every place that touched salary to see what it may mean at that point. Why even give a variable a meaningful name, if we're going to use it for a different purpose than what's indicated by the name?

The trend in computing is to minimize side-effect causing statements except where state is explicitly necessary towards more declarative and functional programming. This aids optimization, reduces errors and clarifies meaning, especially in the context of parallel computing.

http://en.wikipedia.org/wiki/Side_ef...mputer_science)
http://en.wikipedia.org/wiki/Static_...ssignment_form

Not any more than is the case already.

The same reason that you named "salary" salary instead of a1 in the first place - it keeps the name meaningful and logic clear to the reader.

Again, in the trivial example, depending on what's being computed, it may not be important, but it does in larger systems with more complex logic.

I haven't touched this in years so I just did a quick test project:

• Create new MFC app, mostly defaults.
• Right click on project in solution explorer, choose class wizard.
• Add class / MFC class
  • class name foo
  • base class CDialogEx
  • otherwise defaults
• Open resource file.
• Open dialog IDD_FOO
• Drop a button from toolbox on dialog.
• Double click the button, a new handler appears in foo.cpp
• Go back to class wizard
• Select messages tab
• in Search messages, start typing WM_CTLCOLOR
• Double click WM_CTLCOLOR. A new handler appears in foo.cpp

I used VS2010. Got the features you mentioned right quick.

Basically MFC Class Wizard does the magic.

candybar et al,

i didn't read the SO question closely but fwiw my preferred answer for this specific example is:

...unless i'm trolling, in which case my answer is:

clown,

i'm far from a guru but i'll share some stuff that occurs to me:

- in general, only test code that you're writing. if you're using some 3rdparty code that actually puts pixels on the screen then you're not in a good position to test that code and it's not your job anyway. when you write code that tests the list.append() method, do you write tests for that? no, you assume it works as advertised.

- what i do want to test is that my code does the things i expect it to. your supplied example is a little weird since, in a sense, it only has side effects. more frequently, your methods will be changing some state in an object or updating data or something -- an action with a concrete, measurable outcome. that's the stuff i'm verifying with my tests.

- if you really do want to test that the pixels are getting drawn correctly, here are a few things you might try:

-- mock the canvas/window/whatver is displaying the pixels. a mock framework will give you stuff like "make sure this method was called with parameters foo and bar".

-- design your draw method such that the test can provide its own thing to draw. by default you draw the background and the inventory and everything else, but the test says "just draw this square". then you can check that the corners of the square are drawn correctly (by directly inspecting the screen/canvas/window/etc.).

-- as a last resort, dump the screen to a file and compare it with a known master or look for specific features or whatever. we do something like this at my soon-to-be-former job as a big end-to-end test. it's very powerful but also a huge pain in the ass to maintain.

- btw all this advice applies to the general problem of automated gui testing, which is why i have so much to say on this topic (i quickly tire of qa dudes who use "it's too hard" as a justification for doing ****ty manual testing for the rest of their sad little lives).

hth!

god those commercials are annoying.

IT FEEEELS LIKE IM TOO CLOSE TO LOOVEEEE YOUUUUU

yeah okay, please just die.

maybe you're too close to the television to love it?

Your logic means you believe people should only ever declare immutable variables. It's not practical or reasonable.

Assuming this is all in a function called get_salary (or similar) this isn't a side effect. It's performing a calculation with intermediate values.

It's a line longer.

There's really no better way to do this.

booyah.

argggg. Totally spaced on this today and now it looks like they're sold out already

I guess I'll stick with Linode for now, or maybe give prgrmr a try. Anyone used them?