Writing Successful Solutions on SpecHero

To ensure you build and maintain a positive reputation on SpecHero, it's important to only post useful solutions to requests for help.

To make sure your solutions are useful, run through this checklist before hitting that big, shiny "Submit as Solution" button.

• Obviously, all specs must pass and no errors must appear in the box at the bottom of screen.
• Generally speaking, don't change the spec, only the code. If you have to change the spec because you believe the spec is in error, (it's possible) then put a comment at the top of the spec explaining why you changed it.
• Write enough code to make the spec pass but don't add code just because you think it might be useful. This is Test-Driven Development so it's really the responsibility of the tester to drive the implementation. Testers should take the code for a test drive and look for deficiencies and then write them up as example in the spec and submit the spec for further work. This ensures that the code is fully tested and fit for purpose.
• Write nice clear code. Keep it DRY. Use meaningful variable names, follow conventions for the language it's written in. Basically, write code that you wouldn't hate to have to debug six months from now.
• Make sure you don't have literals. In your code that weren't mentioned in the description of the spec. These are a sign that you're solution is not what the requester intended. See below for more info.

Most of the above are pretty simple but the last point may need a little explaining.

Have a look at the code in this solution. This is an example of slime. It makes the specs pass while at the same time being completely useless to the requester. Notice in particular how it contains literal values. The description of the spec reads:

A picture
  when its height is changed
    maintains its proportions
  when its width is changed
    maintains its proportions

Nowhere there does it mention the numbers 400, 200, 50 and 100 which appear as literals in the code. This is a big clue that the code is not doing what the requester intended.

Now checkout the code for this useful solution to the same problem. Notice that it contains no literals that weren't mentioned in the description of the problem (in this case, none at all). This is a good sign that you're on the right track to doing what the requester intended.

If you've done your best to follow the above guidelines, go ahead and submit it. We're working on a feedback system now so hopefully soon you'll be able to receive constructive comments and work toward an effective solution.

Happy Solving.