Please feel free to contribute 8')
--------------------------------------------------------------------
1. Letting classes get too large (feature creep at the class level)
2. Use of anti-patterns (overcomplicated code)
3. Using the wrong language
4. Using too many languages for a project
5. Introducing multi-directional dependencies/losing track of dependencies
6. Not using unit-tests
7. Forgetting to make a destructor virtual
8. Too lazy to write an assignment operator, copy constructor
9. Overuse of subclassing
10. Not reusing your own code
11. Over-generalizing code too early
12. Over-design/paralysis-by-analysis
13. Not breaking code down into modules (too many loose files)
14. Too many headers (kills build time)
15. Trying to roll out code when open-source is available
16. Choosing a 3rd party library with insufficient support
17. Choosing the wrong platform
18. Picking a bad name for a class
19. Jumping at new paradigms at the cost of code clarity
20. Choosing the wrong data-structure/algorithm/stl-container
21. Shadowed variables/functions
22. Not passing a large object by pointer or reference
23. Insufficient encapsulation of data/namespaces
...
24. Trying to optimize your code too early in your project's development stages.
25. Not leaving enough room to optimize your code later in your project's development stages.
26. Not using enough comments in team projects
27. Utilizing multithreading where it's not applicable.
some people over-design to the extent that features/generality gets added unnecessarily
others don't think enough about the big picture so they lose out on code-reuse (even failing to reuse their own code)
for people who over-design, test-driven development with constant refactoring is useful
for people who don't think enough about big picture cases, studying design patterns, and thinking about paradigms is useful
I tend to over-design, but sometimes, I, too, code without thinking enough
29. Failing to use a memory-checker/race-checker like valgrind
30. Overly verbose/succinct variable names
31. Inadvertently introducing circular dependencies when the project gets larger
That one was a painful experience for me. After reading my nice books about OOP, I was like "*dumdidumdidum, let's write some reusable and easily maintainable code*"
I had a lot of troubles with this. It took me a while until I realized that the problem was that I had so little experience on the field that I had simply no idea what I could reuse and what would be important for maintenance.
#32 was a common problem in the early days of C++ when people didn't know how to do OOP (you will see this in really old legacy code) - on the opposite extreme, there are C++ purists who will avoid using any C function or constructs, if at all possible
I tend to be closer to the C++ side, but will have no hesitation using C formatting over iostream formatting or anything that makes code clearer/cleaner/easier to maintain
33. Not having completed implementing code and switching to a different area
34. Refactoring and adding new code at the same time
35. Not committing to version control frequently enough
36. Not testing code frequently enough
37. Insufficient test code coverage
38. Ignoring crazy cases
39. Losing track of ownership of dynamic memory
40. Optimizing in the place I think, rather than running a profiler
@Xander314: Nothing wrong with casting between things of that nature =]
46. Using Dev-C++...
47. Creating static libs with classes, where all of the members that should be protected end up in the private section... *shakes fist
48. Using Dev-C++... (lol for emphasis)
49. Having absolutely no sense of humor, ever, in your code. I hate looking at other people's dry code. I love to comment little jokes and such. Though perhaps this isn't a programming "sin"...
50. Making code based on cross-platform libs platform dependent. (sometimes unavoidable)
51. (this applies to me) Being Hypocritical While Making Up Sins For Programmers (lol)
kfmfe04 wrote:
1. Letting classes get too large (feature creep at the class level)
7. Forgetting to make a destructor virtual
11. Over-generalizing code too early
15. Trying to roll out code when open-source is available
22. Not passing a large object by pointer or reference
23. Insufficient encapsulation of data/namespaces
35. Not committing to version control frequently enough
Guilty.
Albatross wrote:
25. Not leaving enough room to optimize your code later in your project's development stages.
26. Not using enough comments in team projects
27. Utilizing multithreading where it's not applicable.
52. Writing very clever code only to find that a month later, I can't understand it
53. Discovering magic numbers which were meant to be only temporarily used
54. Not constifying my methods as I should
55. Using friend as a quick patch - I'll fix it later... ...NOT!
56. Making a class do too many things
57. Get distracted by nifty new languages or paradigms
58. Helping noobies understand C++ on this forum when I should be coding
59. Letting the compiler find my mistakes 8'P
60. Putting the implementation in the header file... ...just to get it working quickly, first...
I'm interesetd in what you mean there can you elaborate? What is bad about this? Can much go wrong when casting between basic types?
One of the more common things noobs do:
1 2 3 4 5 6 7 8 9
char foo[] = "myfile.txt";
// This line gives you a compiler error, cannot convert char* to LPCWSTR or something similar:
DeleteFile( foo );
// So to "fix", they do this:
DeleteFile( (LPCWSTR)foo );
// which of course, doesn't work