Sorry, I prefer not to discuss it.
"Interesting" is an ... well, interesting ... way to put it. Projects of that size are so large that no single person can understand how it all works. Programmers at that point become specialists -- they become the sole author and
maintainer of a small subset of the overall project. They know the internal details of how their code works, and
they know the external APIs they use. Because they have the most knowledge, they can "maintain" the code
more easily than anyone else. They fix all the bugs in that piece of code, and they implement all the new
features. And it becomes a positive feedback loop.
It is a problem when they move on to other projects or other jobs because nobody will ever have as thorough,
detailed knowledge and understanding of the software the programmer wrote as the programmer himself/herself,
regardless of how much documentation they write. Even the original author will forget a lot of details if they aren't
dealing with the software routinely. I know. I've written a lot of code in the system that I work on, in many
disparate areas. I jump from area to area, depending upon what new features need to be implemented.
Some of the software I wrote six years ago was
so simple at the time. All you had to do was derive
your new class from some base class, and override a few virtual methods. Today, I've forgotten all the
important details of how to do that -- what should function Init() do, when is it called, etc. It was simple
back then, yes, but time erodes even the best of memories. Looking back, yes, I did write copious amounts
of documentation -- design documents, code comments, etc. But still, neither the documentation nor the
comments add up to the knowledge I had when I wrote the software.
And that is why I always harp about maintainability and even why I often post messages like "here's a one-
liner that does the same thing". Less code to maintain, readability equal, is always better. Not only is it
easier to modify later, but it is quicker to understand.
1 2
|
std::sort( people.begin(), people.end(),
&boost::lambda::_1->*&Person::age < &boost::lambda::_2->*&Person::age );
| |
IMO is slightly quicker to understand (provided the lambda expressions are readable to you; for anyone
beginning to learn boost::lambda, the above will be unreadable) than looking at an inlined custom
quicksort to do the same thing. Even though many programmers are able to look at the overall structure
of the code and realize it is sorting, there is still some text-scanning involved to figure out the sorting
criterion/criteria.
And IMO the above use of boost::lambda to define the sort criterion is slightly more maintainable than
writing the function object:
1 2 3 4 5 6
|
struct SortAscendingByAge {
bool operator()( const Person& p1, const Person& p2 ) const
{ return p1.age < p2.age; }
};
std::sort( people.begin(), people.end(), SortAscendingByAge() );
| |
because, while both are equally readable to me, the function object is more typing, and if I ever want
to change the sort criterion, I either have to write another function object (more code to maintain) or
change its name in two places -- call site and declaration site.