I have been learning programming in C# for about a year and a half now. How should I ensure that the code that I am writing and the habits are forming are good ones?
ie. I don't want to end up having written code which only I can understand.

I know that we must use the naming conventions as per language. But are there any more concrete guidelines which I must keep in mind?

Any rules which various companies enforce on their programmers while writing code? Any Documentation standards ?

Any books/websites would also be helpful.

  • Use MS StyleCop!
    – Job
    Feb 14 '11 at 19:19
  • Try posting some code to the Code Review stack exchange. It's in beta at the moment. Feb 14 '11 at 20:58

It is a tome, but I firmly believe that the information in Code Complete 2 is critical for every developer to know. Read the whole thing. It covers the details of the coding process in great detail. Everything from when to break out functions, to principles of good OO design to how to name variables. C# is not among the languages the examples are in, but that doesn't matter, it is worthwhile regardless.

Beyond that, make sure that you are using standard best practices. Do you have unit tests? Can you get people to review your code and give you feedback? Are you trying to keep up to date with the technologies that you use? From time to time re-read older code of yours and reflect on what worked, and why.

  • +1 for reading Code Complete. A bit outdated but it really goes deep into everything. Could not agree more.
    – c_maker
    Feb 14 '11 at 19:18
  • 1
    A more up to date book would be Clean Code by Robert C. Martin - it has excellent practical tips for producing very readable and usable code. Feb 14 '11 at 19:44
  • 2
    @ChrisAnnODell: Other than the omission of unit testing, the advice is not dated at all. And I love the many references. By contrast uncle Bob strikes me as generally good, very opinionated, but not as informed. To name one example, the widely repeated advice about having lots of short methods has absolutely no quantitative support from attempts to study the question, and some evidence against. I prefer McConnell's honest reporting of the facts over uncle Bob's blanket assertion about how to code.
    – btilly
    Feb 14 '11 at 19:59
  • Both books are highly opinionated (along with being well researched). Which is good, because overall when you ask any experienced peer for code structure advice they'll tell you it depends. I love the fact that both McConnell and Martin actually set out reasonable rules to start from. My guess is one's opinion on each book would lean towards the style one prefers. Feb 14 '11 at 22:05
  • Do not stop coding once the code works. Too many devs feel their job stops at making something happen. We could do this back in school without much experience. The real craft is to make the working code clean.

For C# you might want to check out http://www.jetbrains.com/resharper/ - a tool which might teach you some things about the language.

  • 2
    sharing links is very useful, but sharing your experience with the tool adds a lot more value. What was good about it? What was not so good? Please expand your answer.
    – Walter
    Feb 14 '11 at 19:07
  • Ah... Resharper is excellent, but I would not suggest jumping straight into relying on it - it's so easy to just Alt+Enter your way through a codebase believing that you're improving it when you're only obfuscating it further (e.g. when it 'Linq-ifies' a foreach loop into something extremely arcane). Learn the practices and reasons for them so that you know you can review and trust the output of a tool. Feb 14 '11 at 19:47

Just a few points here:

  • Consider reading Framework Design Guidelines. I think it's a must read book with collection of "do" and "don't" patterns in the .NET world.

  • Share your code. It may sound a bit trivial but the more code review, pair programming etc. you will held the more feedback you will recieve.

  • Write tests. They will not only help to spot some mistakes in implementation but your tests will be the first thing that will use your code.


A few ideas to consider:

Code reviews. Do you have someone that could try to understand the code and give you suggestions on how to improve what you have? This would also be in the category of finding a mentor to help develop your skills which would probably make a lot of sense as the first idea to pass along. You could also look at pair programming for another idea here where a second set of eyes does review what you write.

Unit tests. Do you have some tests for your code and how well does this explain how your code handles boundary cases? Do the tests seem like reasonable documentation when it comes to stating desired functionality? Just some questions to ponder as you put this with the rest of your code.

Continuous Integration. Granted this is more for a team case, this is another practice that can be useful in maintaining code quality.

Patterns & Practices would be a site that may help though I imagine there are probably a few other ones that may also help. Construx Blogs and ThoughtBlogs may also be useful if you want some links.


Microsoft framework design guidelines sits on my desk at all times. Much of the material is intuitive to pro's that regularly use the framework's objects. Still, its a great read for knowing in depth why certain decisions were made, who was involved, and there's nothing like showing another developer some written guidelines to swing a decision.


If you're in the C# world, then the two tools that I recommend are:

The two do different, but related things.

Resharper: acts as a line-by-line aide-mémoire about things that you really should be doing. It helps with refactoring (more than standard Dev Studio), it helps indicate which items are testable, it adds to intellisense.

NDepend: acts as a code quality and exploration tool. Where Resharper helps you see and make the trees, NDepend lets you see the forest, cut firebreaks and generally keep a high-level view. The CQL (Code Query Language) is wonderful for defining project-specific problems or rules to enforce.

Not the answer you're looking for? Browse other questions tagged or ask your own question.