Posted 2008-05-25 23:30:24 by
I ordered a book on C# a few days ago. It was odd, to want to get a technical book again; lately I've just been -- and this seems to be the general programmer zeitgeist nowadays -- relying on google for just about all my technical questions. But the question I had in this case wasn't a technical question, it was a style question, and style questions don't fit search engines. Not only because it's harder to translate such a question into a keyword search, but also because given a decree from a random blogger or forum poster or what have you, it's much harder for me to verify whether it's sensible.
I've been programming in C# for a couple years now and I still don't know what, you know, good code is. Not the way I did for C and C++. I think partly this is because C# style is still evolving; it's still a relatively new language. But partly I think it's because the way I've been learning languages changed.
For C I had a mentor, a really brilliant guy. For C++ I think the big driver was working with Tim, who had a very strong, and rather incompatible sense of style from his university studies. Coming to understand each other's extreme positions on style, and coming to a compromise between them, was really the C++ code style boot camp neither of us knew we needed. The three solid months of coding in the same room on the same project helped in that regard too.
For C#, what I basically have is Adam's old codebase for RECE, the RosArt External Combustion Engine, a very large and very general website back-end which was architecturally solid but very much a work in progress when he left RosArt for greener pastures.
Python actually makes an interesting contrast -- when I started working in Python I felt like I was solid, stylistically, very quickly. Python lends itself to elegant code well, has a tiny syntax so is quick to pick up, and due to its hacker roots, has a user-base that can be trusted to a much greater degree to know what makes makes good code. Another factor to consider, though, is that coming from a C++ and Perl background, Python is such a pleasure to work with that you could probably spew out any old nonsense and it would be as much a pleasure to work with as well-written C++ and Perl programs are.
| Posted by Anonymous (Adam) on 2008-07-28 19:31:30 |
It's really hard to find good books, too. Often the author isn't very smart, but is good at communicating. So the reward for figuring out what they're saying is getting misled. Somewhat better are the authors who are smart but can't communicate. Authors that have both qualities seem pretty rare.
I think there are some style ideas that transcend language, like trying to make code self-documenting, adding comments to summarize ideas, and documenting code that might be called by others. For the longest time I was too lazy to do any of that, and the result is that my old code is really inscrutable. I still don't think I'm great at it.
But good style seems to improve the design, too. For instance, making code self-documenting often involves taking code that is only used once in the project, and pulling it out into its own function or class just to give that piece of a code a name. I've often found that breaking things into these small pieces makes refactoring much easier later, because you already have all these little tools with well-defined inputs and outputs. And since refactoring is easier, I end up doing it more often.
As basic tenets go, here's what I try to do, but it's all easier said than done. These have evolved only since I worked at Microsoft and had to deal with other people. Before then, I just did whatever took the least effort.
Design interfaces that are easy and natural to use correctly, and very difficult to use incorrectly.
If you find a bug, try to prevent it and all bugs of that class from happening again. Like Toyota's "5 whys". Sometimes the style is to blame.
Make your code testable, such that writing unit tests is easy, and then write the unit tests. This involves some new design approaches that I don't quite have a handle on yet, like making things very modular, so that dummy objects can be swapped for the real thing almost anywhere, including file systems and networks, so you can simulate all kinds of problems in the test environment. Being forced to make things so modular pays off in providing a more flexible design. I still don't know how to unit test graphical applications, though.
But you were wondering about C# style in particular. I guess I don't know much. C# doesn't provide multiple inheritance, which would seem to close down a lot of possibilities for OO design. You can get those possibilities back by using interfaces, delegation, and object composition, which also make it easy to write modular, testable code. I think most programmers just stick with simple inheritance and end up with a bulkier, less flexible design.
You might also look at FxCop, which analyzes .NET executables. It catches a lot of problems, including some style issues, and explains why they are problems and how to fix them. There's also StyleCop, but I think it's only about enforcing code style in a team. I remember there was a .NET best practices guide that Microsoft wrote, which included style and programming techniques, but I can't find it now. There's a printed copy in the RosArt office somewhere. :-) The C# programming guide (http://msdn.microsoft.com/en-us/library/67ef8sbd.aspx ) may be useful. It's more about how to use the language and framework than style, but it's good to know.