views:

862

answers:

11

What techniques you use to ensure code quality?

Pairing? Code reviews? Design? Documentation?

What helps you creating extensible quality software?

A: 

In terms of code quality in my last .NET project I used StyleCop to keep my code clean. http://code.msdn.microsoft.com/sourceanalysis (i'm sure theres equvalents for other environments)

It took a while to get into the constant reminders to follow it's rules but I have to say the code is really clean as a result. I'm planning to use it again in the hope that it will become second nature after a while.

I don't think it takes anything away from the creative aspect of programming, it's more a way of reminding you to keep up the quality of your code. For most of the rules I was happy to use the defaults provided but you can provide your own too.

I'm a fan of code reviews but find that they are unpopular or percieved as too time consuming.

AJM
+2  A: 

I basically make sure my code is easy to read and close to the domain as possible. I believe there's no better documentation than the code, so if your code is easy to read then you'd have an easier time maintaining it.

As for actual engineering practices, I personally think that it depends on the size of the team and what kind of software you're writing. What you probably will want to have in any software project you're working on are:

  • High Level Design Document (detailing how it's going to look like at an abstract level)
  • API Documentation (something that can be automatically generated)

For code, I would recommend keeping it simple as much as possible. Tests are also a great way to specify requirements and as soon as you can write tests you definitely should. Once your code is tested enough, you should be able to refactor your implementation to keep it as simple as possible on many different levels.

One thing that is essential if you're working in a team would be code reviews and making sure that the written code is actually readable and understandable code. The less time you spend trying to figure things out means the better your code is translating the solution.

Dean Michael
15 years, hundreds (if not thousands) of code reviews. Only once or twice was a *meaningful* error found. However, if you don't have the reviews then people write really nasty looking code because they think no one else will bother looking at it.
Dunk
+11  A: 

Code quality starts when you interview someone - you need the right people with the right skills and (most important of all) ... the right attitude.

I've tried pairing, code reviews all sorts of stuff but if you don't have the right people - its pointless.

A stable team helps as well - if you have a high turnover of staff it means that you will find it more difficult to get the right people.

Once thats sorted out all the techniques above help. Developers who read books about development always seem to turn out better code.

Use tools as well: static analysis, coverage reports etc.

Fortyrunner
+3  A: 

I think, in order to be able to answer this question, you have to be more specific on what you mean by 'code quality'. :) Is code-quality the amount of code that conforms to some style-guideline ? Is code-quality the amount of code that has no defects ?

For me, code quality is readable code, that conforms as much as possible to the style-guideline that is used, and that has as little as possible defects.

In order to achieve that, I try to:

  • try to design my code in such way, that I do not violate the Single Responsability Principle ( a class should do only one thing, and do it well), and other OO principles. (Try to be open for extension, but closed for modification)
  • write unit-tests that test my code, so that I know that something works (or doesn't work)
  • the unit-tests also allow me to easily refactor my code if necessary. If I see a 'broken window' (code smell), I can easily fix it.
  • use FxCop to do a static code analysis, so that it alerts me when I violate some design guidelines
Frederik Gheysels
Code quality is defined (in a bunch of different ways :) here: http://stackoverflow.com/questions/405243/how-do-we-define-code-quality
Daniel Daranas
A: 

The most important element I have found is to make sure that everyone on the team understands what is expected of them quality wise. This can be communicated via pairing and code reviews (that also cover unit tests) as well as task prioritization - do we spend time refactoring the server (it really needs it) or adding the new feature, how much time to spend on integration testing etc. After that point everything comes for free and the team members tends to push each other on.

The real killer is how you get the best out of reviews, pairing etc as this will vary from team to team. You really need to get buy in from the team and let them arrive at an implementation that works well for all concerned.

neil.johnson
A: 

Code quality is a factor of if you understood the requirements for the new code correctly, are using sufficient programming skills with appropriate time available to get a meaningful results.

I know this sounds like weasels words, its not meant that way.

Bottom line:
   - **good requirements**
   - good skills in the solution domain (programming and design)
   - and enough time to turn out a good results

Plus a desire to create quality software.

All of these of course have trade offs depending on the situation. Hopefully you have them all.

John Burley
A: 

The Principle of Software Quality

The best way to improve productivity and quality is to reduce the time spent reworking code. Reworking can take the form of changes in requirements, changes in design, or debugging.

CMS
A: 

Here is what we have as our rules:

  • follow strict coding practices (use a well established good book as your bible)
  • review others code
  • test units of code (build an automated test suite, so you can detect code breaking changes early)
  • turn on all the warnings
  • use lint-like programs.
  • comment not just how the code work buy why it works that way
  • document every fix and change and the decision behind it
Richard J. Terrell
+2  A: 
  • Fail fast and loudly.
  • Make dependencies explicit.
  • Don't search for things, ask for them.
  • There is a time and place for everything that punches through layers of abstraction: main() or the equivalent.
  • Bound memory allocations to an explicit object. (Watch this get voted down for this entry.)
  • Structure is good. Leveraging structure is better.
MSN
A: 

Besides other things, we've used the following techniques/mechanism to make sure that our product is of high quality:

  • Code reviews
  • Beta tests
  • Automated tests
  • Logging
  • Error reporting
  • Customer feedback
  • Using proven code
  • Dedicated testers
  • Virtualization
  • Designing the software upfront
  • Using a good debugger
  • Debug and strict options

This worked out really well as we get only very few bug and error reports, even though our product is used by quite a few users. I wrote an article explaining the above mentioned techniques in more detail on our software quality blog:

12 Practical Tips for Building Bug-Free Software

Dennis G.