Design Patterns: Naming Conventions

Microsoft's Guidelines for naming conventions. At first glance, naming guidelines seem unnecessary (a variable is variable). However, after working on various legacy projects, anything that improves readability and understanding is a good thing.

The most basic concepts are the capitalization names:

1. Pascal - The first letter in the identifier and the first letter of each subsequent concatenated word are capitalized. Used for class names, property names, method names, and events. example BackColor
2. Camel - The first letter of an identifier is lowercase and the first letter of each subsequent concatenated word is capitalized. Used for parameter names. example backColor
3. Hungarian - including a prefix in order to encode some metadata, such as the data type, about the parameter. Should not be used. example stringBackColor

Framework: .NET Dynamic Versus Static Typed Languages

This MSDN article discusses the new C# 4.0 "dynamic" keyword, but also helps illustrate dynamic versus static typing in .NET.

Short notes:

1. Dynamic languages don't perform compile-time type checks and identify the type of objects at run time only. Code is faster and easier to write, but doesn't give the benefit of compile time errors.
2. VB.Net can be made to be more strongly typed by including the "Option Strict" setting.
3. While the level describing how strongly typed a language is certainly relative, a good definition I found in Stack Overflow is "if I can concatenate a string and an integer without casting then it's not strongly typed."

Design Patterns: Cohesion And Coupling

Posting a few articles regarding basic design frameworks and patterns. This one is from MSDN Magazine regarding cohesion and coupling.

1. Decrease Coupling - Aspire to design loosely coupled classes or class which are not dependent on one another.
2. Eliminate Inappropriate Intimacy - Careful with business logic class which needs too much information regarding data access.
3. Increase Cohesion - Make the code inside a class directly related.

Observation of decrease coupling/increase cohesion creates these positive benefits:

• Keep things that have to change together as close together in the code as possible.
• Allow unrelated things in the code to change independently.
• Minimize duplication in the code.