Pet peeves (lighthearted)
in [C++]
|
Prev: Special container
Next: map within map
From: Carlos Moreno on 11 Aug 2005 17:02 Andrei Alexandrescu (See Website For Email) wrote: >>Having overhauled thousands of lines of code in the last couple days, >>I'm wondering what other C++ programmer's pet peeves are. > > template <class Iterator, class Value> > Iterator Find(Iterator b, Iterator e, const Value & v) { > bool found = false; > while (!found && b != e) { > if (*b == v) { > found = true; > } > } > return b; > } Cryptic, are we? :-) What's the pet peeve? Redefining Find as opposed to using std::find? Using Iterator instead of InputForwardIterator? Using "class" instead of "typename" for the type parameters in the template? Putting the opening bracket in the same line as the if or the while? Using single- letter names for the parameters, instead of begin and end and value? Not putting redundant brackets to clarify that the condition is ((!found) && (b != e)) ?? Not using an additional return statement to avoid the [arguably] unnecessary flag? Carlos -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Ulrich Eckhardt on 11 Aug 2005 17:03 Carlos Moreno wrote: > Jeff Schwab wrote: >> // Unecessary use of preprocessor. >> >> T* p = NULL; // T* p = 0; > > IMO, your alternative is wrong. Deeply wrong. I know that I'm > just re-triggering an endless discussion (a-la MAC vs PC, Unix > vs. Windows, Ford vs. GM, etc.) No problem, the answers are of course Mac, Unix and public transport. ;) > One of the things that I profoundly hate of C++ is the use of > 0 as the name of a null pointer. 0 should mean *only* 0 -- the > numeric value of zero; and not the null value for a pointer. > > When I see NULL, it stands out and I know immediately that we > are talking about a null pointer. When I see 0, my mind tells > me that there is a number in there, and it requires some > additional effort to realize that it is a pointer what's really > involved. There is some enhancement idea to introduce a null-pointer constant to C++, I recently saw it at Bjarne's website. Other than that, and doing a bit of embedded and kernel C lately, I'd say that C and C++ are lacking pointer literals. I could imagine using a 'p' suffix, just like the 'u' for unsigned or 'l' for long. struct ata_controller_regs*const = 0x3f0p; if( some_ptr != 0p) {...} Just my two cents. Uli -- Questions ? see C++-FAQ Lite: http://parashift.com/c++-faq-lite/ first ! [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: kevin.hall on 11 Aug 2005 17:03 (1) People / rules that make unnecessary requirements. For example: code must be single entry, single exit. (2) "#pragma once" instead of header guards (what if you need to use a non-MS compiler?) (3) "using someNamespace" in header files (4) Classes that are not const-correct (5) NULL not be used (I believe it makes code more clear) (6) Not comparing against 0 or NULL for pointers. "if(somePointer)" instead of "if(somePointer != NULL)" (again this is an issue of clarity) (7) Prepending all class names with "C". Contrary to popular belief, "C" is not related to hungarian notation. This convention was picked up by compiler writers before namespaces existed. Microsoft used "C". Borland used "T". Microsoft never wanted or expected programmers to adopt this convention. People originally just blindly picked this up b/c Microsoft was doing it. People now blindly pick it up because other people do it. Now that namespaces exist, new interfaces provided by compiler vendors (including Microsoft) don't use the "C" convention anymore. Neither should we. (8) People / rules that require hungarian notation in C++. (9) People who say that "macros are evil" or that require that macros cannot be used. Use templates where you can. But don't be afraid to use macros if it makes sense. Andrei Alexandrescu and Matthew Wilson both use macros in their books and libraries where it makes code cleaner and easier to read. (10) People who mandate rules just to save source-code space. Ex: Function names can only be 10 characters long. The following pet peeves are those found outside of source code: (11) Companies that will not provide the tools to help the developers do the best job possible. (Ex: "Memory leak detection software is too expensive.", GCC/GDB is free, why do you need an integrated development enviroment.) (12) People who refuse to use source control systems. (13) Developers who believe that testing departments exist to find all the bugs and consequently do nothing to develop tests themselves. (14) Companies that do not do code reviews (15) Development teams where nobody has the authority to make a final say. (This usually happens on a two-person co-development environment where neither was designated as the lead developer). I think that's enough for now. I'm sure I'll think of more later. Good topic by the way! Cheers! - Kevin [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: John W. Peterson on 12 Aug 2005 05:07 How about never incrementing b? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andrei Alexandrescu (See Website For Email) on 12 Aug 2005 05:05
kevin.hall(a)motioneng.com wrote: > Andrei, > > With all due respect (and I do respect you -- you have a lot of insight > and the work you have done has helped me tremendously as a developer), > but what are you trying to say in your post? It's not really clear > since you only posted code. Are you saying that people shouldn't > develop their own find algorithm and should use the STL instead? It was a joke referring to the past heated debate on multiple function exits. I know... explained joked aren't fun :o). Andrei [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |