[Programming] lessons

[stereotype441]

I've started a text file on my computer called "programming_lessons.txt". I'm thinking I'll write down insights I have about programming throughout the day, and go back and reread it now and then to remind myself of what I've learned

Comments

[oniugnip]

These are all really good, thank you! :) If you keep posting 'em, I'll keep reading.

Writing these down seems really healthy -- I'm feeling inspired to try to be more self-monitoring with my programming habits. I feel like I'm often not very conscious about how I go about working. I'm getting better about thinking about what I'm doing, but maybe not how I'm doing it. Yet.

[lindseykuper]

I have this lofty goal of writing about programming in a way that will be palatable to all readers, whether or not they're programmers. I have a couple of reasons for wanting to do that. First, it seems to me that dividing the world into programmers and non-programmers in the first place is damn near impossible, and perhaps just wrong. Second, I aspire to be a good writer, and good writing can make just about any topic interesting and accessible to a broad audience. But because that kind of writing is hard to do, I end up stewing forever and never actually finishing. This is what's happening right now with my ICFP contest story. I want to write it in a way that my mom will enjoy it, and in a way that you, Paul, will enjoy it, and I want to believe that those goals are not contradictory.

[jes5199]

can you give a rationale for #1 ? I have a contraindication like "if any operation mostly concerns a single object, it should be a method on that object"

also, 4 and 5, I say: don't treat unit tests like code!
I'm suspicious of moving a test into a function.

[stereotype441]

Hmm, let me tell you what I was working on when I came up with #1. I was working on a class that represented the contents of a large and multifaceted configuration file. There were a number of operations you could perform on it, some simple ones that operated on the class's private data structures, and some complex ones that were implemented in terms of the simple ones. I wanted to write a unit test for one of the complex operations, call it x, which was implemented in terms of simple operations a, b, and c. It was a huge pain because the test required me to build a half dozen complete bogus configuration files, even though operation x only interacted with a tiny portion of each file. Halfway through, I realized that if I pulled the complex operation out of the class, then my test could use a dummy object that implemented stub versions of operations a, b, and c. Suddenly the test was easy to write. Also, now that operation x is outside the class, I feel like I can make changes to the internal representation of the class more

[pixelherder]

Something like #1 has been a recommendation for C++ programmers for a while. Sutter and Alexandrescu's "C++ Coding Standards" (2005) suggests "Prefer writing nonmember nonfriend functions." Their rationale:
Nonmember nonfriend functions improve capsulation by minimizing dependencies: The body of the function cannot come to depend on the nonpublic members of the class. They also break apart monolithic classes to liberate separable functionality, further reducing coupling. They improve genericity, because it's hard to write templates that don't know whether or not an operation is a member for a given type.

Granted, it does help that by convention in C++, free functions in the same namespace as a class that they operate on are normally considered part of that class's interface due to argument dependent name lookup.

[boojum]

I've gotten a lot of value out of utility functions for tests. For instance, there's often a string of tests of the form:

• do [thing]
• assert that object has/lacks validity/completeness/whatever

. Creating AssertHasWhatever() and AssertLacksWhatever() is a win in those cases.