Code Formatting - A reflection of Coding Level?
-
I think the only thing this thread proves is that generalization is always a bad thing. That said.... sloppy code indicates sloppy thinking. Everyone makes mistakes. Consider: - If you don't have time to make the code neat, you probably don't have time to make it work right. Doing code in a hurry is a recipe for error. - Making bugs easier to find and fix results in fewer bugs. How can anyone argue that point?
I disagree completely. "neat" is a subjective quality. If someone has to make their code conform to some "neatness" standard than is different from their own, that obviously takes a lot more time than if they use their own. Further, have you never heard of the term "conservation of energy"? I knew this guy with a desk piled high with stuff that nobody could find anything in, yet if you asked him, he knew where everything was and could find it in an instant. He didn't waste time organizing and quantifying, but rather simply remembered where everything was, conserving energy which he used to great effect elsewhere.
-
You've touched on one of my bete-noirs. If a function *isn't used* then it shouldn't exist. If the default constructor/destructor etc is correct for a class, then you shouldn't rewrite it. When I'm reading your code, if I come across a replacement for one of the defaults, which provides exactly default behaviour, I'm left wondering whether you intended non-default behaviour and made a mistake, don't understand the default behaviour, or are mindlessly following silly coding rules. If later I find a constructor that differs trivially from default behaviour, I now have no idea whether you intended default behaviour, or not. Furthermore I would suggest that if someone writes code where setting breakpoints in default constructors/destructors is essential to debug the code, then you have far more serious problems than code layout. Dan
Furthermore I would suggest that if someone writes code where setting breakpoints in default constructors/destructors is essential to debug the code, then you have far more serious problems than code layout. Indeed. Code layout is part of a larger job of thinking about minimising the cost of code maintenance. If adding a destructor or default constructor to a class definition is going to cause a large rebuild (lets say most of the files in most of the 50+ DLLs of 2 million lines of code - and yes I am working on code where a few files are sadly this important - (*)), then having that constructor/destructor always defined (even if #ifdef _DEBUG conditionally compiled) is a major bonus as I don't have to wait a few hours whilst it builds. I guess I got slightly off topic, but it is these trivial things that do matter. Default constructors/destructors that are supplied by the compiler are identical to empty constructors/destructors, so if I found them in someones code I'd assume they are there for a reason, not because of a mistake. I guess we have different attitudes to /expectations of the rest of the team we work with. Besides a decent comment with each would put your mind at rest in any case. (*) One part of my gig with these people is to track down resource and performance problems that the rest of the team are too busy to look at. As a result I'm often dumped into code I've never seen before. In those cases constructors and destructors and lifetimes of said objects are often a great help in determining at what point something didn't go as planned. Stephen Kellett -- C++/Java/Win NT/Unix variants Memory leaks/corruptions/performance/system problems. UK based. Problems with RSI/WRULD? Contact me for advice.