Death by 1000 Programming Sins

Pages: 1234567
Jun 2, 2011 at 6:16am
111. Using const_cast except for compatibility with C library functions.
112. Using C library functions, where a better C++ counterpart is available [thanks, rapidcoder ;)]

@helios My resource manager has two get functions, one of which returns a reference and one a pointer. The reference function doesn't really have a choice but to throw an exception if it fails to find the specified resource.

EDIT:
Disch wrote:
I think the appropriate behavior in this case would be to have an error return by default, but have an optional setting so you can configure it to throw an exception.

Do you mean some kind of state flag in a class?
Last edited on Jun 2, 2011 at 10:15am
Jun 2, 2011 at 9:47am
112. should be rather: Using C library functions, where a better C++ counterpart is available

113. Committing broken code to the project source code repository.
114. Not taking benefits of source code management system while working on unstable code until it stabilizes, in order to avoid 113.
115. Creating a branch and after a week of work realizing you can't merge with the rest of the project because of 1000 or more conflicts.
116. Not using branching/merging to avoid 115.
117. Using ancient, crappy SCM like Subversion or CVS, thus being forced to (either 113. or 114.) and (either 115. or 116.)
118. Lying to other people that Subversion is a CVS fixed.



Last edited on Jun 2, 2011 at 9:50am
Jun 2, 2011 at 3:16pm
Programming, versioning. Same thing, really.
Jun 2, 2011 at 5:19pm
Not same, but using SCM is inherent part of programming. Except in cases when you are programming a hello world, there are no reasons not to use SCM on your programming project. So 119 is:

119. Not using SCM at all.


Last edited on Jun 2, 2011 at 5:21pm
Jun 2, 2011 at 6:10pm
If by "programming" you mean the software development process as a whole, I suppose so. Otherwise, it's like saying that where you keep your manuscripts is an important part of writing.
Jun 2, 2011 at 6:56pm
I'm guily of 119 because I haven't learned to use git yet.
Jun 2, 2011 at 7:20pm
Same; I downloaded it a while back, but it's still on the to-do pile :/
Jun 2, 2011 at 8:25pm
83. Keeping compiled binaries in SCM

@rapidcoder - are you looking over my shoulder? I just committed that sin last night, out of laziness...

93. Using gets to deal with user input.

got hurt by a corollary of this one last night - have to use gets.chomp in Ruby

98. Putting of work that should take less than 30 min. to do. 

guilty as charged

110. Using everything as a singleton.

ouch - that's a scary one

Re: SCM - any SCM is better than no SCM

120. refactoring code and adding new functionality at the same time (a sure source of bugs)
121. worrying about functionality that you don't need (eg SSL when you could just tunnel)
122. paralyzed by the number of platforms available these days (which one to pick?)
123. mutant class as requirements change over time - should've refactored instead
124. touching the mouse (trackpad is not as bad, but still slows down coding)
Last edited on Jun 2, 2011 at 8:26pm
Jun 2, 2011 at 10:05pm
125. Not RTFM.
Jun 2, 2011 at 11:08pm
closed account (3hM2Nwbp)
126. Accidentally Blending languages (I actually did #import a few times...)
1
2
3
4
5
#import <map>
public static void main()
{

}
Last edited on Jun 2, 2011 at 11:09pm
Jun 3, 2011 at 7:36am
127. adding code too quickly (it's much easier to write code than to remove it)
128. mixing levels of abstraction within the same module
129. copy-pasting code rather than use templates or polymorphism
130. doing too much in one method or class
Jun 3, 2011 at 7:58am
I'm seeing lots of repeats.
Jun 3, 2011 at 3:17pm
I'm seeing lots of repeats.

see what I did there?
Jun 3, 2011 at 3:23pm
closed account (S6k9GNh0)
131. Over use of templates.
132. Not enough use of templates.
Jun 3, 2011 at 4:25pm
+1 Ultifinitus for providing some light amusement as always
Jun 3, 2011 at 4:33pm
I don't think anyone has mentioned these... has anyone?

133. Having too much superfluous code in your project at any one time.
134. Using the wrong objects for the wrong jobs.
135. Using std::list to store large collections of small variables EDIT: in a highly memory-critical project.
136. Freeing allocated memory too early and/or too often.
137. Accepting bribes from the redundantly redundant redundancy department of redundum.

-Albatross Albatross
Last edited on Jun 3, 2011 at 5:06pm
Jun 3, 2011 at 5:02pm
135. is not always a bug - what if you want to have fast insertion or deletion from inside of the collection? Vector would be painfully slow.
Jun 3, 2011 at 5:07pm
Okay, I didn't express myself properly. I meant for projects where the top priority in terms of optimization (and there are some indeed!) is reduced memory usage.

-Albatross
Jun 3, 2011 at 5:11pm
Albatross wrote:
Albatross Albatross

A working example of redundancy?
Jun 3, 2011 at 7:56pm
120. refactoring code and adding new functionality at the same time (a sure source of bugs)


Ahem, I disagree this is bad practice. I do it quite often, for example, I wanted to change my mathematical vector class to work with arbitrary coefficients (say, rational functions).

Instead of copying + pasting the mathematical vector and replacing the coefficients by hand, I directly templated it all, only passing const pointer to the 0 and 1 elements of the coefficient type.
Pages: 1234567