views:

230

answers:

11

This may seem like a fairly arbitary question but it would be nice to know the symptoms of bad design before its to late to change anything.

+7  A: 

Bad design can predominantly be detected by Code Smells.

Here Be Wolves
+2  A: 

If it's difficult to change anything then you probably have a bad design!

Tim Wardle
+3  A: 

If you find yourself making ad-hoc fixes...always a bad sign...

peirix
+1  A: 

some say that software engineering is a science, but only experience can tell you what a bad design is... after having seeing many of them xD

fortran
+9  A: 

If you find yourself procrastinating instead of working on the code because you know what to do, but the how is painful, that's one good sign.

Rytmis
Fancy term for badness here is "viscosity." Should be easy to code things which are easy to think.
Drew Hoskins
+2  A: 
  • Are you spending a lot of effort on code that makes an effort to be unnecessarily flexible when a more straightforward, yet less flexible solution would work? YAGNI

  • Do half of your class names end with Manager, Helper or Wrapper? Or even worse a combination of two or more?

  • Are you coding for features that have not been fleshed out with decent requirements? Poor requirements will bleed into every aspect of the project, including the overall design.

Dan
+1  A: 

One way I found was that if you go through how different features are supposed to work and the process seems very convoluted, that's a good sign that you need to change your design. One dead giveaway is if there is one "master class" where almost all of your other classes go, that's a bad design. Likewise, if many classes are dependent on many other classes, that's probably not good. If you have objects doing more than one thing, that's not good. Each object should contain data and functionality which is related, if its not related, you need to change something. This last one I learned from experience: If you're going to be making changes later and you know you might have to change anything, avoid singletons like the plaque. They are very difficult to refactor out if you have to and even when you can have only one of an object, it's very easy for someone to accidentally make a second instance of it.

indyK1ng
+2  A: 

Just a short point, but anytime you start enumerating out variables, it's typically time to see if you need a collection instead - i.e. descriptionLine1, descriptionLine2 or color1, color2.

Jon
+1  A: 

There are many ways bad design can manifest.

A few questions you could ask yourself:

  1. Does each class have a single responsibility (wikipedia)?
  2. Do classes leak details of their implementations?
  3. Are many different classes held inside the same source file or is the correlation between software components and source files hard to follow? Physical design is also important.

To detect bad design try having a code review with other programmers.

CiscoIPPhone
A: 

Try to make a simple change in your code. If you need to adjust a lot of code in order for this to work, you may have a problem.

Geo
For example change the background color of a window? I don't think this is a good way to measure bad design.
CiscoIPPhone
A: 

Bad design is not coding for the future. Always assume that someone else is going to take your spot and have to read what you're doing. Also if the code is not easily extensible, or not portable, something is wrong. Your code should be so slick that another programmer could include it almost like a module.

mandroid