Death by 1000 Programming Sins

[kfmfe04]

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
...

[Albatross]

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.

-Albatross

[zb0S216C]

28. Purposely ignoring compiler warnings.

_Wazzak

[quirkyusername]

You've mentioned over-designing, I tend to do the opposite and design my programs a I go along, which is terrible.

I don't know whether this is common.

[kfmfe04]

it goes both ways

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

[hanst99]

Over-design/paralysis-by-analysis

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.

[quirkyusername]

I never do this but you see it all the god damn time

32. Programming in C++ as if it was C

[kfmfe04]

#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

[kfmfe04]

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

[anonymous23323124]

quirkyusername wrote:

You've mentioned over-designing, I tend to do the opposite and design my programs a I go along, which is terrible.

I think I have the same problem as you... but I am trying to fix it ;)

[3hM2Nwbp]

kfmfe04 wrote:

15. Trying to roll out code when open-source is available

+

2¢

=

15. Trying to roll out code when (well designed) open-source is available, that doesn't force an unwanted licensing restriction on the project. IE GPL

[Disch]

41. Casting around compiler errors

[Danellos]

42. Improper error-checking for users that input invalid values.

[quirkyusername]

41. Casting around compiler errors

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?

[jsmith]

Lots of stuff can go wrong. Imagine casting a pointer-to-apple to a pointer-to-car, then trying to call startEngine() on it.

[anonymous23323124]

casting between basic types

But something like int -> float is alright for small numbers, right?

[Computergeek01]

43. Using "Sleep(...)" or equivalent commands instead of proper Call back functions to "fix" race conditions between two seperate threads\processes.

44. Spiking the CPU with No Op instructions while waiting for a command to finish. This looks like this in C++: while(!OtherThing.IsDone()){}

45. Copy pasting or re-writting code instead of making it into a function.

[ultifinitus]

@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.

Guilty.


Hmmm. I'm not very good at this game =]

[kfmfe04]

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...

[Disch]

quirkyusername wrote:

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:

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