coding guidelines? design guidelines? best practices?
Can you point to your documents? How far do you go to enforce these guidelines?
+2
A:
Ok fine, here's a more robust list :)
- Check in constantly
- Write tests when it makes sense
- Use the right design patterns to solve your problem. When in doubt, brainstorm with a teammate, or with me.
- Nothing is finished, everything can be improved. Refactor constantly, even though it
mightwill hurt. - Peer review when it makes sense
Trust is an amazing thing. A good developer will apply FxCop (or whatever) on her own code, not need it to be enforced as a check-in gate. If you're hiring people that don't do that, you're wasting your own time and money.
Rex M
2010-08-15 16:03:09
Rex, answer the question or point to an existing answer.
Christopher Mahan
2010-08-15 16:08:13
Understood, but how do we provide consistency across many competent developers.
CodeToGlory
2010-08-15 16:08:19
@CodeToGlory I think you're missing my point... if you hire competent developers, very little oversight is necessary. I lead 13 developers and my job is great, because they don't need hand-holding. I give them a reference architecture and say "build x" and lo and behold, they do it correctly! Design patterns and best practices are not magic and competent developers don't need to be told to use the right tool for a job.
Rex M
2010-08-15 16:12:24
+1, @Rex M, excellent answer and comment.
Darin Dimitrov
2010-08-15 16:35:37
+1
A:
As an MS dev shop we use checkin policies, code coverage, FxCop and a succinct coding standards doc.
Daz Lewis
2010-08-15 16:11:37
+2
A:
Coding Standards - one standard document for each language (SQL, C#, js, HTML + CSS etc) Standards are each numbered, and each standard has a "rationale" (why) and "enforcement" level (Must, Should etc). There are tons of examples of standards out there, which you can use as a starting point but you will need to customise to fit your specific needs. These are reviewed at the beginning of each project.
Design Guidelines - each project is different. Typically the software architecture document describes the system decomposition. Developers are expected to read through this.
Best Practices - we try to contain most of this within the coding standards, and regular training sessions are held to transfer knowledge (and Links to articles and webcasts etc). However, best practice has a habit of changing over the period of a project (the world is changing faster than we can deliver projects ;).
Enforcing standards - we use FxCop and StyleCop. Code can't be checked in until it conforms.
Design Guidelines - some can be picked up automatically (e.g. through assembly referencing), and others in code reviews.
Adherence to Best Practice is usually only picked up in code reviews or similar. There is a degree of subjectiveness in this unfortunately.
nonnb
2010-08-15 16:13:12