Now that I have been tinkering with Knockout for about a year, I have finally settled on a host of design patterns that I feel strike a nice balance between rigid consistency and flexible prototyping. I like to have all of my code look very similar. I can look at most code that I have written and know about when I worked on it last. I can usually even look at code that several other developers have touched and see what is mine and what is everyone else’s code. Now that I have a team to direct and an expanding code base to maintain, I have realized that I need to document my own code patterns.
Certainly, my way probably is not the absolute best, but it is what I like and what has worked best for me. Might I change my mind? Absolutely. Probably even before I finish writing this post, I will have changed my mind on several points. However, this is a good place to start.
Two days later, as I started to write up the actual rules I had been following, I decided to look around and see if other people have put together lists of their own. It brought me to this Programmers (Stack Exchange) question, which had a very nice explanation on why what I was doing was a bad idea.
It’s important for a team to have a single coding standard for each language to avoid several problems:
- A lack of standards can make your code unreadable.
- Disagreement over standards can cause check-in wars between developers.
- Seeing different standards in the same class can be extremely irritating.
I’m a big fan of what Uncle Bob has to say about standards:
- Let them evolve during the first few iterations.
- Let them be team specific instead of company specific.
- Don’t write them down if you can avoid it. Rather, let the code be the way the standards are captured.
- Don’t legislate good design. (e.g. don’t tell people not to use goto)
- Make sure everyone knows that the standard is about communication, and nothing else.
- After the first few iterations, get the team together to decide.
So much for that idea.
What have I learned? Well, I have learned that I like this idea of doing two weeks of off-the-cuff posts, and then spending one week putting together a longer post with lots of research and information in it. I also learned that I should do the research for that post at the beginning of the week, instead of at the end of the week. I think I will be coming back to this idea, but it will be less formal that the list of edicts I started putting together. Perhaps a screen-shot of source code with annotations will be the good balance between formality and flexibility.