Designing great frameworks training: Naming Conventions
Continuing on the weekly series, today we posted the session on naming conventions. Thanks for watching the intro class and coming that chat. We had over 1,600 folks already watch the talk and nearly 80 folks in the chat. If you missed it you can catch it here and the chat transcript here.
A couple of notes on this sessions:
I mention that these naming conventions, and for that mater the design guidelines as a whole can save your company money. If you spend less time arguing about items that are subjective then you can get more done in less time. I actually had a couple of customers tell me this at last year’s TechEd. They totally see the Design Guidelines doc as a huge argument-killer and therefore a time saver. I am more than happy to help!
I made the understatement of the year that Anders Hejlsberg has some experience Pascal . As you might know it was Anders that really popularized the Pascal language with the Turbo Pascal product. I learned to program with Turbo Pascal so it has been bright spot in my career to work closely with Anders on all of these guidelines we are talking about in this series.
Hungarian notation – I’d stress that the ban on these is for publicly exposed APIs.. I am going to stay clear on the religion debates about how you format your source code.
Can you guess what GUI framework that I am referring too? I’ll give you a hint, I would highly doubt anyone is using it today… The most recent doc on it I could find on the MSDN site is dated Jan 1997 ;-)
The whole notion of breaking changes is an interesting discussion that is really applicable when you don’t control all the clients. Sometimes you can force all the clients to recompile on your new version, but other times you want those apps to be able just pick up the new version of your framework.
Do take time to pause the talk and do that code review on your own… Here is the code if you need it an editable format… the idea is to spot the bad naming conventions used.
public class HtmlEncoding
{
public const string DEFAULT_NAME = "Html3.2";
public HtmlEncoding(string strVer) {..}
public string Doctypename { get {..}}
public bool UseJsEncoding { get {..}}
protected void _coreEncodeCharacter(char value) {..}
}
During the chat I’d love to hear your comments on how we’d fix it.
Learn why good naming is a key factor in API design, and what the recommended naming guidelines are to ensure consistency with the rest of the .NET Framework.
I will be in a chat room on 1/26 1pm PST to answer questions and hear your comments on this topic. The Q&A part of these classes is always my favorite part; I hope you will take time to come.
Sign up for coming chats…
Naming Conventions [Sign up for the post session chat]
Rich Type System [Sign up for the post session chat]
Member Types [Sign up for the post session chat]
Designing Inheritance Hierarchies [Sign up for the post session chat]
Comments
- Anonymous
January 21, 2005
Thanks for coordinating this series of events! I'm loving every minute of it! All these topics are often overlooked during project development, and I'm really glad to see focus on these areas of design! - Anonymous
January 21, 2005
>the idea is to spot the bad naming conventions used.
Given that naming conventions are pretty arbitrary I wouldn't call those bad naming conventions. I'd describe them as non-conformant with the .NET design guidelines. - Anonymous
January 21, 2005
Dare - That is a fair point, but if the goal is to build a consistent framework non-conformant==bad - Anonymous
February 01, 2005
Is there a transcript of the post session chat? - Anonymous
February 01, 2005
We have the transcript, but it is not posted yet.. I just talked to the folks that run that process and they should have it posted within the week. Sorry for the delay.