jaredpar's WebLog : Rant

Questions not to hinge a C++ interview on

Jared Parsons — Tue, 21 Apr 2009 15:00:00 GMT

People love to chat about how to conduct a C++ interview on newsgroups. Eventually these topics will shift into a discussion about what questions a candidate must know in order for them to get a hire from a particular interview. Unfortunately these questions tend to be items like the following.

What happens when you delete NULL?
Explain how exceptions affect constructor initialization.
Which constructors are called for the following: SomeType a = SomeType(b);

Sure these questions are valid parts of the language and knowing them is a plus and demonstrates a deal of mastery over the language. But not knowing them should by no means by a deal breaker. The goal of an interview is to spot good developers who will become a contributing member of the team. Good developers are motivated and passionate problem solvers. These questions are testing little more than memorization. It’s easy to memorize rules after the fact. It’s much more difficult to teach problem solving skills.

The problem with questions like the above is that a developer could be both passionate and competent in C++ and never have come across these rules. C++ is an unbelievably huge language and can operate in many different ways where these type of situations simply don’t come up. For instance, I’ve known several very good C++ developers that spent the majority of their time working with COM. COM prefers HRESULTs to Exceptions and hence they never used exceptions in C++. Once we introduced exceptions into the code base, it took about 30 minutes to explain the rules and we were done.

C++ interviews should focus on the qualities that make a good developer: problem solving and passion. Of course a language based interview should certainly focus on the foundations of C/C+. Items like pointers, stack vs. heap and the basics of memory management. But don’t hinge the deal on little items that can be quickly taught. Otherwise you’ll end up turning away good developers.

Learching: Definition to live search

Jared Parsons — Wed, 01 Oct 2008 15:00:01 GMT

Unfortunately when creating Live Search, the live team did not use a term which could easily be converted to a verb (i.e. google and google-ing). The term "live searching" doesn't really flow well in a hallway conversation nearly as well as google-ing.

I live searched that movie John was talking about ...

I considered for awhile just using the "googling" term for both using live search and google. But this wouldn't allow me to quickly correlate the goods and bads of each search engine. I needed a new term.

Thus learching was born: It's short for "Live sEARCHing". When pronouncing it should rhyme with "searching."

Anyone else with a better term?

Where does the * go?

Jared Parsons — Thu, 04 Sep 2008 15:00:04 GMT

This is a more amusing than functional debate I enter into from time to time. On a line where you declare a pointer type in C++, where should the * go?

Next to the type (i.e. Type* p1;)
Next to the variable name (i.e. Type *p1;)
Who cares

For the moment lets ignore #3 (after all they don't care). I'm a firm believer in #1. After all * is a part of the type of the variable, not the name and therefore should be closer to the type.

#2 believers disagree with this notion. They believe the * is a part of the individual variable's type and not the actual type. This is technically correct and can be demonstrated with the following code

  Type* p1, p2;

The type of p2 is of course Type and not Type*. Therefore they argue, #2 is the superior way

This is true but I'm also a firm believer in don't declare multiple variables in a single declaration statement while coding in C++ unless the type has a user defined constructor. Namely to avoid situations just like this.

Comments

Jared Parsons — Tue, 26 Aug 2008 15:00:43 GMT

If only people spent as much time writing comments as they did speaking to the evils of comments. Everything from useless, inaccurate, to many comments make code unreadable, you should code better ... etc.

I haven't ever looked at a piece of code and thought "wow, way too many comments" or "that code would be beautiful if it weren't for the comments."

Do the next guy a favor, comment your code.

To name a tuple value: A or Item0?

Jared Parsons — Mon, 23 Jun 2008 15:00:17 GMT

One of the parts of a Tuple implementation for RantPack I struggled the most with was naming. I tend to struggle with names quite a bit and there's really no reason for it. It's a combination of pickiness and ... well there's really no good reason. Pieces which can bother me range from

Don't like the way it types. If I can't type something easily it drives me nuts and I secretly desire to change it to a word that is easier to type. I have sadly spent a large amount of time on www.thesaurus.com looking for better words to type.
Looks funny. No real solid criteria here, just what I don't like. Words sometimes look good the first time you type them but over time lose their appeal
Doesn't match conventions. Ah, now we're onto solid reasons. Names should match conventions.
Name is ambiguous. If the name doesn't give a clear intention of the operation I do my best to change it.
FxCop violation. This bothers me less than others but if FxCop doesn't like it I think a bit harder about naming it.

Now comes Tuples. Many implementations of tuples don't even have names but instead rely on language constructs such as pattern matching to access the values. That's not really the DotNet way of doing things though so I chose to give Tuple values names.

Originally I chose A for item 0, B for item 1, etc ... This made sense at the time because it kept the syntax short. However I've grown to dislike this naming convention. Primarily because it violates #3 and #4 above. While A-E is perfectly clear for me I've talked with others who this confuses.

In addition, to keep the nameless syntax option I provided an indexer property. So values are available with a 0 based index. Since several languages expose this with the name "Item", there are now really two names for a value. For example the first value is both tuple.A and tuple.Item[0].

After some thought I decided to name the values Item0->Item4 depending on the size of the tuple.

Code is not self documenting

Jared Parsons — Mon, 09 Jun 2008 15:00:27 GMT

Nothing revolutionary about that statement. Yet I keep reading the opposite on various comment threads and message boards so I thought it a good idea to explore it again.

Code is not self documenting.

The "code is self document" argument often comes up when commenting conventions, patterns and overall usage is discussed. People who are typically against writing more than the existing set of comments will throw out the argument "if we need a comment then the code should be written to be self documenting."

To at extent I agree with this. Code should not be obfuscated and the usage should be clear. I personally strive to make my implementations as clear as possible and enforce that belief on anyone who asks me for a code review.

Yet while you can write code so that an individual algorithm or function is close to self documenting you cannot write it in such a way that it will explain it's greater purpose in a program. Only comments can do that. Self describing code can only describe itself, not it's purpose in the bigger picture.

Comments serve to both 1) explain the algorithm and 2) explain the greater purpose of the algorithm in the program.

Yet people still cling to the code is self documenting mantra. In my experience there are several reasons for this belief. The first is that people have only worked on projects small enough that for most purposes they can be kept entirely in their mind [*]. Until you work on a big enough program #2 is not even a factory because you intimately understand how every function fits into the big picture.

Another is that they have never worked on a project with people they weren't very familiar with. People you don't know well or have worked with before will likely have different ways and practices of approaching a problem which you have not encountered before. What is obvious to them won't be obvious to you. The bridge between these approaches are comments.

I've seen DRY (don't repeat yourself) brought up as well [**]. The code clearly says what it does so adding a comment is just repeating yourself. I find that to be patently untrue. If we're even having the conversation then the code is clearly not self documenting. Also in the cases when an individual function is documenting you will still run into #2.

Commenting your code benefits both people who are reading your code and yourself. You will eventually come to a point where you've forgotten what a particular piece of code did or how it fit into your bigger program. Your comments will save you.

[*] The temptation to say "kept in memory" here was huge but I avoided it.
[**] In general I think that DRY is a great approach to programming but I feel it's being taken to far here

Outdated Comments are better than no Comments

Jared Parsons — Tue, 20 May 2008 15:00:26 GMT

While investigating our locking infrastructure a few days ago I ran across an odd comment. I was looking at a particular usage of a lock and the comment said that "Using lock type X because we must pump messages here." Contrarily the lock type being used most definitely did not allow message pumping.

After a quick history search on the code base I was able to track down the developer responsible for the discrepancy. He merely forgot to update the comment when making the change. However he was able to explain the history behind the comment and the switching of the locking type.

I've heard people argue in the past that they didn't comment code because comments get out of date and lead developers in the wrong direction. They might do it correctly but they didn't trust the next guy. Then the comment would be wrong and useless for the next developer.

I think this is a example of why that mentality is wrong.

Even though it was currently wrong it was historically accurate
The commented add good insight into the choice of locking mechanism
It added a bit of detail into the historical architecture of the code base.
It was a heck of a lot better than staring at a comment-less field that appeared to exist for no reason.

I'm not arguing that comments which are flat out wrong at the time they are authored are a valuable resource. Yet not commenting because you don't "trust" the next guy is equally wrong.

Reserved words: Good for your sanity

Jared Parsons — Tue, 13 May 2008 15:00:05 GMT

Paul Vick posted a recent entry exploring the necessity, or lack there of, for having reserved words in a programming language. It's an interesting mental exercise to go through. At the end you'll realize that many reserved keywords aren't needed from the perspective of the compiler. This is part of the reason C# and VB are defaulting more to contextual keywords in recent releases. What the blog post didn't really talk about though was the programmer. From the programmer's perspective there is one great reason for reserved words.

Sanity.

Going through legacy code is hard enough already. Reserved words at least allow you to mentally structure the code you are looking at. If there was open season on the use of keywords you know someone will take advantage and flat out abuse the system. Can you imagine digging through some legacy C++ and seeing the following [1]

class int : public new { public: new private; }
new void() {
  int int = new new;
  int.private = int;
  return int;
}

Reading that makes my head hurt.

Having reserved words is a language adds a modicum of structure. Language structure allows developers to more quickly grasp the meaning and intent of a piece of code. Can you imagine trying to grasp a more complex example? Now imagine the programmer had several thousand lines of undocumented code with this pattern. Not fun.

[1] Yes I realize that making new/int non-reserved words may not be possible in C++. But this is just a hypothetical example.

What's the purpose of this blog?

Jared Parsons — Thu, 17 Apr 2008 15:00:06 GMT

I've had a couple people ask me this question about my blog. The simple answer is: to explore my adventures in code, coding, patterns and pretty much anything else related to programming.

I realize from a readers perspective my topics may appear somewhat random. After all I post in C#,VB,C++ and Powershell with varying degrees of frequency. I jump from patterns to specialized templates to threading to random gotchas to API Design. The reason for the jumping is I post topics close to the projects I'm working on and I work on a lot of projects :). At any given time I'm working on one of the following items.

My job as developer on the VB Debugger and IDE
My personal managed utility libraries (non-UI and UI) [1]
The PInvoke Interop Assistant
Several internal tools
My scripting environment
Customer reported issues in forums
This blog
Whatever happens to capture my interest at the time.

Whenever I discover anything interesting, find a bug or see yet another pattern/design I like or dislike I try to blog about it. I do this for two reasons.

My own personal sanity. I've found through years of programming that it's very unlikely you will hit an error only once. Instead you're likely to see it time and time again. Blogging about it both helps firm the issue into memory and gives me a great reference to fall back onto the next time I see that bug. It's really simple to lookup a blog post by tag and read it or point a coworker to it.
Everyone else's sanity. The more people who write about issues, the more likely someone else will find an answer when they enter a problem into a search engine.

In short, I love to write and talk about code and this is a great forum.

[1] Hopefully on it's way to http://code.msdn.com so I don't have to keep posting little snippets and making users paste snippets from various blog entries to get a simple working example.

Part of being a good programmer is learning not to trust yourself

Jared Parsons — Mon, 24 Mar 2008 19:28:10 GMT

... and to actively guard against yourself.

Over the years I've found that I can be my own worst enemy when I code. Part of the problem stems from paranoia

Early in my college days, a professor of mine, Jim Greenlee, instilled in me the virtue of paranoid programming. He taught an introduction to C class on a Linux/Unix environment. Our code had to compile with no warnings or errors on Linux and Unix, pass lint, and withstand all manner of evil input the TA's could throw at it. Catching a mistake and printing out an error was bad, but acceptable. Crashing was an immediate 0. Towards the end of the semester, I usually wrote two programs for the each assignment: 1) the assignment and 2) a Perl script designed to automate and generally speaking cat /dev/random into the program.

Over time, this process led to a healthy suspicion of any code that I used (not so much my code, but code I didn't own or didn't actively work in). As a result, I now rarely make assumptions about how other people's code works. I probe, search, test and investigate any assumption about resource management, lifetime, etc . When I'm working on my code, however, I tend to assume I got it right and followed such patterns as RAII. And therein lies the problem: no one is perfect, and I should be as paranoid about the quality of my code as anyone else's.

I find this problem happens most often on the border of my code and the rest of the program. I think this is true for most programmers. You understand your model and the manner in which you expect it to behave. On the fringes of your program, you expect other code to behave properly or your code to account for various conditions. In reality, it's doubtful that both you and the programmer owning the other end of the code had exactly the same thought pattern. Also it's doubtful you understand all the variations in behavior in the other programmers code.

To further complicate matters, you are not the same programmer you were yesterday. Hopefully you're better. As a programmer you constantly learn new patterns, better methods and discipline. So when you program against code you've written, you're approaching it with a different mindset and hence you take different paths. In short, you're programming against someone else's code and assumptions.

For instance there was a time where I didn't actively use RAII in my code. Now I base all my C++ classes around this pattern and use it everywhere. These days I tend to assume my classes implement this pattern. I've been bitten a few times when using older code that pre-dated my use of RAII.

The best way to avoid making bad assumptions is to actively question them at all times. Guarding against your assumptions can occur at several levels. Over time, I've found the following methods to be the most effective:

1) Don't trust yourself

Be as paranoid about yourself as others.

2) Turn Assumptions into Compiler Errors

This is most effective when coding in C++. Occasionally I run into a situation where we find certain classes are invalid inputs to a template, function, etc ... The best way to prevent using the type in the wrong context is to turn it into a compiler error. Typically this is accomplished with a combination of macros and templates. It's not pretty, but catching an error at compile time is the cheapest way. You can't ship a bug that doesn't compile.

3) Unit Testing

I once heard an engineer say that "1 test is worth 1000 expert opinions." It doesn't matter how good you are or how simple the code is; given enough time, you will make mistakes. The most effective and lasting way to ensure that you don't make mistakes is to test your code relentlessly.

The other great aspect is it allows you to freeze an assumption in time. The point at which you write the code is the best time to catalog the intended behaviors of your code. Adding a unit test will preserve and enforce it for the perceivable future.

4) Retail Contracts

Retail contracts are similar to debug asserts. The difference is that they run in retail as well as debug builds. Generally speaking in retail it will cause a crash and Watson dump.

I've debated the merits of such an approach many times. But the principal that wins for me is "if it's wrong at debug time, it's wrong at retail time". It's much easier to catch a problem sooner rather that later. This is especially true for C++ where problems can behave unpredictably and result in "random" failures. Crashing on a line which says Contract.ThrowIfNull() leaves little doubt to where the failure came from. It doesn't necessarily make finding the underlying cause easier but it's a start.

I've heard the argument that checks are non-performant and shouldn't be done in retail code. Most retail checks resort down to "if(!ptr) throw". Yes, if you put many,many of these checks into a hot path of your code base it can cause a performance problem. In my experience it's very unlikely that this will happen. And if it does show up on a profile, it's a simple matter to switch them to a debug assert, or move the retail assert further down in the stack and out of the hot path.

5) Debug Asserts

I find debug asserts are nice for verification that is to expensive to run in retail. I don't mean this to include simple NULL checks but more deep verification of various data sets.

*) Code Reviews

I didn't put this into any specific order because this is highly dependent upon the person reviewing your code. I feel the other listed points add a consistent level of quality to your code. Bad code reviewers offer little help in guarding against yourself and hence do little for quality. Good code reviewers offer good protection but it's a one time shot so I still would put it between unit testing and retail contracts.

There are the few people who have an amazing talent for code reviews. They will make even the most experience programmer come out feeling like an incompetent novice. They are invaluable and even though they are able to shame me at times I insist upon code reviews from them when writing a feature.