Code Smells

At times it can be a challenge to figure out what’s wrong with an application or component. It’s just a nagging feeling in the back of your mind that something isn’t quite right.

For me, that’s a code smell.

Here are a few that I try to keep an eye out for and avoid at all costs in my development efforts.

  • Rigidity
  • Fragility
  • Immobility
  • Viscosity
  • Needless Complexity
  • Needless Repetition
  • Opacity

I strive for SOLID and DRY. Anything that violates those principles needs to be reviewed. Single-responsibility principle and Liskov substitution principle are biggies for me. Do one thing and do it really well. Wrap everything in an interface. Implementation details should always be hidden behind that interface.

The Purge

Recently, I moved around my Azure subscription. The site was down for a while and that was fine. I got everything spun back up, got everything updated and life was good. Eventually, I started poking around my site fixing broken links, removing unused templates, and the like. Along the way, I realized I have over 5,000 subscribers. None have ever posted a comment. Probably because I block all spam comments.

This got me thinking and purging… I removed all @*.ru subs. I started to see naming patterns, patterns that were obviously to human eyes but not machine eyes.

So…

I’m dropping all subscribers that don’t have an avatar. If you think I dropped you and you still want to subscribe, please re-up. I am also adding 2-factor authentication which should help limits bots from setting up more of these bogus accounts.

Anti-Patterns with CONSTANTS.

I have a habit that’s probably an anti-pattern. I like to nest classes in a constants file.

  1. I always call the file Constant.cs. Singular. It goes at the root level of my Framework project. This should be accessable from every other project within your solution.
  2. The class is a static. Therefore, all of the subclasses are static as well.

Normal Constant file

public static class Constant
{
  public const string Title = "My Title";
  public const string EmailAddress = "foo@bar.com";
 }

Now consider this…

Nested classes

public static class Constant
    {
 
        public const string Title = "My Title";
        public const string EmailAddress = "foo@bar.com";
 
        public static class Color
        {
            
            public static class White
            {
                public const string Name = "White";
                public const string HexCode = "#FFFFFF";
            }
 
            public static class Black
            {
                public const string Name = "Black";
                public const string HexCode = "#000000";
            }
 
        }
 
    }

Usage

public class Usage
    {
        public void Example()
        {
            var blackHexCode = Constant.Color.Black.HexCode;
        }
    }

I like how this creates a clean hierarchy to reference a constant. As I said, this is probably an anti-pattern. But it works for me.