Death by 1000 Programming Sins
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:
Do you mean some kind of state flag in a class?
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
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.
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
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.
119. Not using SCM at all.
Last edited on
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.
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
closed account (3hM2Nwbp)
126. Accidentally Blending languages (I actually did #import a few times...)
|
|
Last edited on
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
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
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
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
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.
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
-Albatross
| 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.