On Fri, Apr 20, 2012 at 02:45:51PM +0200, SomeDude wrote: [...] > Oh yeah, I've seen that story too in a couple of other places. C++ > seems to make exceptionnally easy for "mad coders" to screw up a > whole system with overengineered pieces of crap. One of my > colleagues spent more than a year rewriting a system that turned > into a black box that nobody could maintain. > > My opinion is, when a team works in this language, code reviews > should be an obligation, else there is always a guy like that, who > has his genius idea that nobody else understands and puts his crap > all over the place. Basically, the only piece of C++ software I've > seen that never became a huge piece of steaming crap was a system > that was systematically code reviewed by the main software architect > and a couple of highly skilled engineers.
The problem is, code review is a full-time job if it is to be done properly. Often it just deteriorates into a side-job: senior coder A reviews junior coder B's code, but coder A has a pending deadline that week and has lots of complex code issues to tackle, so there's no time to read through everything that coder B wrote. So just glance over it briefly, if there are no blatant problems, approve it. It gets worse if senior coder A himself doesn't have a good grasp of good coding practices, but got to where he is because he's just very good at last-minute patchwork hacks that makes everything "work". Seniority gives him code review rights, but he's really not qualified for the job. > I suspect D is not much better on this topic, it's possible to write > extremely complex code with it too. Actually, it's possible to write > complex and unmaintaineble stuff in any language (even in Python), > but I believe the more complex the language, the easier it is to > screw things up and the more important code reviews are. Problem is, good coders are hard to come by. It's even harder to distinguish between coders who succeed because they practise sound coding principles, and coders who "succeed" because they're good at hacking things at the last minute to make them work. >From a business perspective, the latter are actually (implicitly) preferred, because what project manager wants coders who are hesitant and cautious about making changes when there's an impending deadline of doom imposed by irate customers who want the product shipped by last week? No, they want coders who can make it work, right now, no matter what the means. Who cares about the consequences, what's important is Big Customer A's trivial bug must be fixed This Very Minute before we lose the multi-million dollar contract to a competitor. Use the ugliest, dirtiest, cruelest hacks if you must, the ends justify the means. Is it any wonder that so many large commercial software projects are crap? But anyway, I'm veering off-topic. The point is that C++ has too many features that are unsafe by default, or require the programmer to manually do too many things before it works correctly. Like that dreaded ctor, copy ctor, and assignment operator trio. For the most trivial of classes you need to (at least) provide boilerplate versions of all three, all correctly implemented. Forget some minor detail? No problem, the class will still "mostly" work. Any effects are hard to notice. Until somebody tries to do something that you didn't anticipate, and suddenly there are breakages everywhere. This is one of the many areas where D shines: the default behaviour is safe and generally correct, and you add more code if you want to fine tune stuff. Not like C++ where failing to add certain pieces of boilerplate code results in broken-by-default behaviour. T -- Latin's a dead language, as dead as can be; it killed off all the Romans, and now it's killing me! -- Schoolboy
