I’ve seen dozens of holy wars regarding the subject of naming conventions - when a project starts, when a new team member comes along, when the team leader is replaced etc.

I used to think that a project should have a single naming convention, and everyone should follow it. Now, I’m not so sure any more. I mean, what is really so important about naming conventions? What makes a project with a unified naming convention better than a project without one?

Unity

The first argument for naming conventions is always unity. You want all your data members to look the same.

But, think of it, what is really that important about unity? What business value do you get from it? Does it cut down development time? Does it improve performance?

IMO, if one developer wants his field to be called “_identifier”, another wants “m_identifier” and the other wants “nIdentifier”, just let them! No one ever died from Hungarian notation or a “m_” prefix, I believe.

Readability

For those who still believe in Hungarian notation (or any of its siblings), readability seems to be a great argument for naming conventions.

However, Hungarian notation might have been a good argument a decade ago. Today, all IDE’s provide great intellisense, and one could determine the type of a member in a second by hovering on it.

Scope

Determining the scope of a variable (method or class) is important, but can also be easily discovered by intellisense.

Focus on What’s Important

I’m not trying to say you shouldn’t have a naming convention in your project. I’m just trying to say, don’t let it bother you so much.

Set up a naming convention at the beginning of the project, have your team members agree on it, but don’t hunt down any exception and have it fixed.

Write a unit test or get a cup of coffee instead.

Do you think naming conventions are important? Where would you draw the line?

I hope to learn some stuff I just never get around to, such as:

• Domain Driven Design,
• Behavior Driven Development,
• Domain Specific Languages.

I don’t think I’ll be able to share any knowledge, since I’m positive that I will be stunned by the high-level knowledge of the people there.

So I’m off to stare and drool. See you there!

I did, however, try to keep up and see what’s the fuss about extension methods, but I never got it. I mean, this is anti-encapsulation at it best - break into any type, do whatever you feel like. Total chaos.

So I gave it some time. I didn’t force it into any of my projects until the time was right. Then I finally got it - extension methods are ideal for little pieces of code which you need, but creating a utility class for them feels wrong.

For example, I was implementing a new feature for Regionerate a couple of days ago in which I had to sort a list, split it into distinct values and recursively sort it again.

Its a reflection-based sort and it has quite a bit of logic in it, so it had a class & unit tests just for it. I had to take care of the splitting thingy, but it felt wrong to add it as a method in the sort class, as it operates on lists. It really feels like a method that should run on IList<T>.

Subclassing List<T> for the job feels wrong - c’mon, how would you pitch such a class? “It’s a list that you can split!”. Unpersuasive.

That’s how I got it: If IList<T> was built especially for Regionerate, it would have had a reflection-based Split function, but since its not, I should implement it as an extension method.

Took me 2 minutes and works like a charm.

   1:  public static IDictionary<object, IList<T>> Slice<T>(

   2:          this IList<T> list, PropertyInfo propertyInfo)

   3:  {

   4:      IDictionary<object, IList<T>> slices = 

   5:          new Dictionary<object, IList<T>>();

   6:      foreach (T t in list)

   7:      {

   8:          // Get the value of propertyInfo.

   9:          object value = propertyInfo.GetValue(t, null);

  10:   

  11:          // Add it to slices.

  12:          if (slices.Keys.Contains(value))

  13:          {

  14:              // slices already has a slice for this value.

  15:              slices[value].Add(t);

  16:          }

  17:          else

  18:          {

  19:              // there is no slice for this value 

  20:              // inside slices, create a new slice.

  21:              IList<T> newSlice = new List<T>();

  22:              newSlice.Add(t);

  23:              slices.Add(value, newSlice);

  24:          }

  25:      }

  26:   

  27:      return slices;

  28:  }

A fully documented, well-aligned version of this extension method is freely available here.

Note: yes, this post should have been a tweet, but I’m Twitterless.

Krzysztof Cwalina

I’ve read Framework Design Guidelines a couple of years back and learned a whole lot from it. It definitely makes it to my top 5.

However, I’ve had problems convincing my staff members to read it, as it contains~400 pages of design tips, which are quite hard to read in succession.

The Framework Design Guidelines Digest narrows the basics down to 9 pages. I recommend everyone to download and read it every once in a while.

Quoting Krzysztof:

This document is a distillation and a simplification of the most basic guidelines described in detail in a book titled Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams. Framework Design Guidelines were created in the early days of .NET Framework development. They started as a small set of naming and design conventions but have been enhanced, scrutinized, and refined to a point where they are generally considered the canonical way to design frameworks at Microsoft. They carry the experience and cumulative wisdom of thousands of developer hours over several versions of the .NET Framework.

Get it here.

We split to several teams - development, marketing, user experience etc’. Over at the development team we split to front and back end teams.

I wrote a YouTube adapter yesterday for uploading and displaying YouTube videos, hope to post about it later on.

Looks like I’ll be doing some NHibernate today.

Can’t really write too much as I’m late, again, for day III, but:

1. Some pretty great guys out there, its always nice to reach outside your circle of colleagues.
2. People are smart.
3. People are stupid.

The only important things I’ve learned from talking to a nice gentleman from marketing is that if you plan to release a killer app in a domain which has already been harvested, your chance to succeed aren’t that big. Most successful application we see today recognized an un-harvested domain and conquered it.

Keep following on Twitter, I’m off!

Nada.

I got there about 4 (!) hours late. I was busy helping my brother choose the caterer for his wedding.

Over at SWI, They were just about to vote between two project ideas. I didn’t really relate to any of them but maybe because I didn’t get to hear too much about them. We voted and went home.

I’m a better man. I have a SWI T-Shirt.

Just kidding, if I wasn’t such an idiot trying to eat so many steaks I could have actually participated.

Oh well, hoping for better luck tomorrow.

Keep following at Twitter.

Startup Weekend Israel, in a nutshell is a weekend marathon held by dozens of hi-tech employees from Israel. The objective of this weekend is to try to create a startup company within one weekend.

You are welcome to follow my adventures at Startup Weekend Israel on Twitter.

Real life sometime brings you to strange situations. I lead a development team which is building a web application and we recruited a new member a couple of weeks ago. I’ll refer to him as “the baby”, since he never wrote a single line of code.

Why is he on board, you ask? Well, he’s a fresh computer science student and knows his way around the presentation side of websites (good knowledge of HTML, CSS, Javascript and good ol’ web black magic) so this seemed like a good trade-off for both sides - the baby will join the team and help us out with his mighty presentation powers and in exchange will be part of a real project for the first time and will get on-job-training.

This is an interesting spot. Computer science has brought his knowledge to a certain level so far (basic C) and I need to catch him up with:

1. Object Oriented Programming,
2. What design is,
3. Separation of Concerns,
4. Liskov Substitution Principal,
5. The .NET Framework (3.5),
6. A whole bunch of BCL,
7. C#,
8. Relational databases & SQL,
9. Active record & SubSonic,
10. MVC,
11. Dependency Injection & Inversion of Control,
12. Test Driven Development & MbUnit,
13. Mocking with Rhino Mocks,
14. Design patterns,
15. Scrum,
16. Continuous integration,
17. Source Control Management with Subversion,
18. Tools.

Oh, and this needs to be done as we go on with the project.

Can you think of anything I forgot to mention?

Does the order make sense or would you suggest a different one?

Eeek.

I was working with this enum:

    public enum AvatarSource

    {

        Gravatar, Uploaded, Web

    }

and I wanted some conditional logic performed, depending on an AvatarSource instance. So I started to type switch and then thought I might use a code snippet for it, so I pressed TAB twice.

Well, I didn’t see this coming.

            switch (avatarSource)

            {

                case AvatarSource.Gravatar:

                    break;

                case AvatarSource.Uploaded:

                    break;

                case AvatarSource.Web:

                    break;

                default:

                    break;

            }

Once you enter the variable for your switch block, the snippet automatically adds a block for each value in your enum.

Sweet.