Xp Challenge Cee Plus Plus

Formerly ExtremeProgrammingChallengeSeven

As described in AllPanaceasBecomePoison, C++ has become not an easy language to work in. Nevertheless there are a great many C++ programmers and developments out there - more than for Smalltalk, Java, Lisp and Perl combined. Many of these developments suffer beneath a very heavy MethodologyBurden and would be very interested in lightening it.

Can XP be adapted for C++ development? What XP practices would change? What extra practices might be required?

Can XP be adapted for C++ development?

Sure, why not? Do they not need Simplicity? Is Communication right out? Can they write reliable code without Testing? Doesn't using C++ make just everyone feel Aggressive? When you prick them, do they not bleed?

What XP practices would change?

I've programmed in C++ (and most every other language) and offhand I can think of no XP practice that isn't applicable. Do you have any candidates for things that wouldn't work? -- RonJeffries

I see environment specifics. I see some practices like LetSmalltalkTellYou?, DoItInAnInspector?/Workspace, DontThinkJustSetTheHalt? and ENVYDiscipline that need to be translated or generalized. I wonder whether XP++ (for want of a better acronym :-) needs practices to deal with C++ specific concerns like template closure, library combination, stdlib style, and so on (I feel a sudden need for Marshall Cline's FAQ book, regrettably not handy right now). -- PeterMerel

On the Internet, everything is handy. There's a subset of his C++ FAQ book online at http://www.cerfnet.com/~mpcline/On-Line-C++-FAQs/

C++ seems a good deal less handy when it comes to refactoring. Static types tend to mean that information on the location, arguments, etc. of a given function are exposed in a wide variety of places. A browser to help in refactoring with C++ would be a huge asset here. Even highly 'decoupled' implementations seem to suffer from this.

Or is that just my imagination? Who has really used XP in a C++ environment? War stories here would be great.

I have. See TestDrivenProgramming for a brief glimpse. I'll write more about this asap. -- AamodSane

I've been doing it a bit as well. I've made a C++ port of KentBeck and ErichGamma's JUnit. It is called CppUnit.

Regarding style, I am coming to believe more and more that that adopting some Smalltalk-isms helps C++ refactoring. The ones I'm thinking of are:

make all member functions virtual unless there is some compelling need not to, and
think long and hard before making a member function non-public.
Keep things simple.
Avoid any restrictions or noisy syntax that you think that you may have to revisit later, things like const on member functions, etc.
Adopt uniform conventions on the use of references and pointers, etc.

The general idea is not to do things that will cause you silly work if you end up having to change things later. C++ has many temptations. Avoid them. Whenever you are ready to so something tricky, remember YouArentGonnaNeedIt. The simpler the code is, the easier it is to change things.

-- MichaelFeathers

I've just put an example of (an attempt at) XP in C++ on my home page. -- MartijnMeijering

Hmmm. Per (2) above, I would think that YouArentGoingToNeedIt would argue in C++-style languages (my experience is more in Java) for making member functions *private* unless there was a good reason otherwise. If you make it private, it can easily be refactored away at a later date without having to chase down any callers. But if you've made it public, well, it's public, and who knows who might be using it. Even worse, if the class is part of a public API (i.e. one exposed to customers) then you can *never* get rid of a public method. But a private method can always be made public later on if it turns out you *do* need it to be. I gather that this kind of desire to lock down code is heretical in the Smalltalk world ,but it's seen as a GoodThing among aficionados of B&D languages exactly *because* it makes it easier to refactor later. -- PeterSeibel

But not using const on member functions makes code more restrictive, since it limits its use to non-const objects of that class - see UseConstMemberFunctions -- JamesCrawford

Const can be left out so long as that's done consistently. I've been saved by const many times over the years, but to tell the truth, I'm not certain it really justifies the hassles. I use it because I'm in the habit of it and the standards call for it, but YMM certainly V. -- PeterMerel, who was actually groping for CppHeresy and especially AlternateHardAndSoftLayers

How do Smalltalkers do const?:-)

They can't really, but if you're the kind of person who uses accessors for all your instance and class variables, you can define only the getters not the setters. -- SteveFreeman

Taking the time to put values in a PoolDictionary? is a bit closer (a little bit of extra work but nice if you truly have some constant values) -- TimMackinnon

We're about to start a new project with all the usual commercial pressures and it looks like it'll have to be in C++ (still working on that). One thought I had would be to code for a while in something malleable (like Python) and then to port to C++ when we think the basics are stabilising. Otherwise, maybe we should just get on with it in the target environment. Any thoughts/experiences? -- SteveFreeman

I've worked in C++ as well as Smalltalk. I'd be very tempted to develop in something malleable ... especially something malleable that might also be fast enough. Maybe they'd release in Smalltalk ... I assume that the alleged performance of C++ is the reason for using it? And I use the term alleged advisedly. -- RonJeffries

For those interested, there has been much discussion on comp.object recently about Smalltalk/C++/Java in regards to static vs. dynamic and weak vs. strong typing. look on deja.com for the subject Typed languages a bad idea?