We all do it.

File, Open. Scroll down, scroll down, pause. WTF!^$%@!. Scroll up, pause. Scroll down. “Wow……, dude you have to come look at this…”

Yeah, we have all been there, finding code that we love to hate. It’s sloppy, hard to read, and looks like a monkey with no fingers pounded it out. Code so ugly only it’s mother could love.

But really who can blame software developers for hating other developers code? A large part of software development is artistry and intellectual matter. I assume that literary authors have a difficult time truly enjoying other authors’ work because either they believe it is horrible or they deeply respect it but then have a sense of jealousy.

So what can we do to find enlightenment instead of anger in these moments of discovering rotten intellectual stew?

Laugh

It is very easy to get angry, but why? The damage is already done, so let’s do something constructive.

Pretend that you wrote the code 5 years ago. Hell, maybe you are looking at your own old code – oh the irony! Whether a co-worker, past employee, or you wrote the code – take a moment to chuckle at it. Chuckle at it’s complexity, chuckle at it’s comments, but most important chuckle at fact that you once were at this point too and that is why you are now wise enough to recognize a better way of doing things.

Learn

One of the largest life lessons I could ever learned was to take every single moment, reflect on it, and attempt to learn something new.

Although there may be a dozen better technical implementations, take the opportunity to speak to the original author and try and understand what they were thinking. In my career, the most enlightening moments have been listening to the innocence of interns.

Learning goes both ways, and be sure to also teach offenders why some code is smelly. Teach the wisdom, direct the plan, and help (or review) the execution.

Leave It Better

I don’t know who started the “Campground Rule” but Uncle Bob used it in his book Clean Code:

We should leave the code cleaner than we found it – Robert Martin

Identifying and laughing at bad code helps you accept it, but only fixing it helps you find new love in it.

Similar Posts:

• Don’t Unit Test? Start Counting Your “Oh Shits!”
• The Art of Harvesting Abstraction
• Concentrated Codesqueeze: February 2008
• The Wisdom Of Insecurity
• Nobody Has A Duty To Teach

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

What is the difference between intelligence and wisdom?

Some would venture to say experience, and I would agree to a point. I believe it is our failed experiences that continue forcing life’s lessons down our throats. An additional injection of humbleness through humility, and we have the perfect dose of much needed medicine to aid us in our journey towards personal improvement.

So what is stopping us from traveling down the path of enlightenment through failure? Simple. The fear of perceived failure.

Notice I did not just say “failure”, “fear”, or even “fear of failure”. What I am after is “perceived failure“, which can be interrupted into many things including:

Perceived lack of…

• Knowledge
• Artistry
• Intellect
• Ability
• Skills

You need to quit sweeping known uncertainty under the rug and this includes your code.

I grow weary of code reviews where the author (with a nice sized grin) proudly shows their clean solution, and then [being the asshole I am] call to see where they hid all of their crap code that I know is truly holding the house of cards up. Their grin quickly turns to a defensive posture, and the true code review begins…

I don’t care what you best code is – I want to see the weakest link! You and your solution are only as strong as the weakest link, so let’s take a look at it and improve it. We all have them, so let’s quit hiding them. Sure you might not look like superman now, but at least you won’t look like a liar later when your bad designs and hacks come back to haunt you (and they will).

Find it hard to open up to a group of people? Find those one or two buddies you always show your crap to. They don’t even have to work on the same team or even in the same company as you. As long as you think they can help you out, confide in them and allow yourself to take criticism.

The road to being better is to simply allow yourself to become better. Your pride is your own worst enemy in this scenario, and overcoming it will start to open many doors that lead to learning opportunities.

So after all this, why should you never flaunt your best code? Because self pride leads to a lack of humbleness…plus it’s probably not all that great to start with.

Similar Posts:

• Your Software Process Sucks : Resistance To Change
• Metrics and Wealth – It’s All Relative
• Do Managers Prey on Developer Pride?
• Why Are You Asking Me This Question?
• Geek Speak: When Developers Attack!

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

This post is in response to Blog Action Day. This year’s topic is one that is important to everyone – poverty.

Back in the first years of my computer infancy, one website struck a core nerve with me – The Hunger Site. It was the first time I saw a website completely dedicated to the greater good of humanity. It is rare that we as software developers get the chance to utilize our talents for the sole purpose of making the world a better place, but there is always opportunities if we keep our eyes open.

While passing through Sioux Falls, SD this weekend on a family vacation, the family and I decided to take a road break at a local mall. While bopping around we discovered a store unlike any other called Catharsis. Catharsis is a small, local art studio with some of the best local talent I think I have ever seen.

Since I am a chatty guy, I started chatting with one of the owners and he began to tell me a story that the entire store actually operates like a non-profit organization and that all proceeds go to local charities such as animal shelters, half-way houses, and the local Luther League. I was absolutely humbled by these guys and their generosity (as must have the mall, because they practically donated the space even through the xmas season).

Long story short, they said they were new to the internet and needed a website – I decided this was one of those opportunities to help. I donated a small amount of money, time, and personal resources and help them to create Experience Catharsis. It is literally only hours old and still slightly under construction, but it is a start of something I feel could be larger than local to Sioux Falls.

Many small hands move mountains, but small hands with the power of the internet can change the world. I hope you search and find at least one opportunity in your career to donate your time and skills as the rewards you inadvertently may find might be greater than anything you could ever imagine.

- Max

Similar Posts:

• Balancing A Workaholic Schedule
• 25 Signs That You’ve Got a Bad Client
• How Your Socks Can Determine Software Lifespan
• Save Time By Writing Better Bug Reports
• Quit Exaggerating On Your Skill Set

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Every developer has some amount of code that they feel is reusable to them, but doesn’t clear that bar to be reusable for everyone.

This is what I call Pocket Code – reusable code that does not belong in reusable libraries that is shared amongst projects and team members, but code that you keep handy somewhere to be cut-and-pasted into applicable projects (I need not bring up the now famous State enumeration).

But where do we keep this code? Do we keep just lug it around on a memory stick or do we attempt to squeeze every last ounce of worth out of it? Here are some ideas besides keeping it squirreled away:

Code Snippet Websites

There are tons of code snippet sites and directories out there. Some are generic, while others are very specific to language or need. Here are the few that I use frequently:

• Code Project – http://www.codeproject.com/
• DZone.com Snippets – http://snippets.dzone.com/
• Regular Expression Library – http://regexlib.com/
• VS.NET IDE Snippet Library – http://gotcodesnippets.com/
• Joyent CodeSnippets – http://codesnippets.joyent.com/

Got another one we should look at? Feel free to add a comment below to your favorite snippet website.

Junk Drawer Assembly/Jar/Repository

This is the least favorite of all the possible choices; however, it is the one I most practice.

The first thing I do when starting a new project is to create the SVN repository. The second thing I do is immediately create a “toolbox” repository for that project that I call – the junk drawer.

Anything code that does not contribute to the product but does indirectly support it (quick and dirty data migration apps, record matching apps, or that crummy State enum) gets saved for prosperity in this repository. There is no structure or rules in the junk drawer.

I have seen people attempt to organically grow “reusable” libraries from these snippets in the forms of assemblies and jars. I highly frown upon this practice – you wouldn’t keep your yeast and flour in the same jar, why are you keeping junk and clean code together? Trust me, the maintenance headache of this practice far out weighs the ROI of ever reusing that pocket code.

Your Blog

The majority of developers who blog create posts only around code – making their code available for the entire world.

Here are a couple of thoughts on this:

1. I love bloggers who post and explain code because it adds to community learning
2. I loathe bloggers who post uncommented code with no explanation further than – “thought this might be useful to someone else”
3. If you are blogging about something – normally you are passionate about the topic, so I will take that piece of code a little more seriously

Those are just some of my ideas, and I am sure there are a few others. Where do you keep your pocket code?

Similar Posts:

• The Most Reusable Piece Of Code Ever…Period
• Are You In A Claustrophobic Team?
• Squeezed Links: August 2007
• The Correct Process Guides Us (Tracer Architecture Cont.)
• Binding Software Patterns to Languages

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Did you know that only two countries, the United States and Canada, participate in what the Americans call the "World Series"? It’s as stupid as it is hilarious. The average American doesn’t know that the European Union has almost twice as many citizens as the United States. Americans only care about their own 50 states. And that’s fine with me. As a Dutch guy, when filling out (American-made) personalization forms on “international” web sites, I always chuckle when I see that half a million people in the state of Wyoming are apparently more interesting than the 86 million people in the Chinese province of Shandong.

Last year, when some guy in California noticed that I am from The Netherlands, he asked me if I knew a certain Johan Christiansen in Denmark. (For American readers I should explain why I thought this was funny: There is country, called Germany, with 80 million people in it, separating The Netherlands from Denmark. The chance of me knowing someone in Denmark is as small as the chance of Max being able to pronounce "een schip in Scheveningen" in Dutch.) So I said no, and I asked this guy if he knew a certain Carlos Gonzalez in Ecuador. For some reason he didn’t appreciate that reply.

Max asked me what I thought about Americans forcing programming languages, with English syntax, and frameworks with English API’s, upon non-English developers in the rest of the world. Well, here’s what I think:

Americans are stupid, and I love them for it. Because stupidity leads to simplicity, and simplicity is exactly what we need in software development.

We Europeans are different. We know where the United States are. (It’s that place where all that CO2 stuff is coming from.) And we distinguish ourselves from the Americans by making things as complicated as possible, particularly when the French are involved. If the .NET Framework was created by a European organization, it would have a core API in three languages (English, French and German), and there would be many dozens of adapter layers translating these core API’s to secondary API’s in any of the other twenty official languages. Europeans have a horrible tendency to compromize, not wanting to forget or offend anyone, which makes the outcome of our efforts completely incomprehensible, and utterly unworkable. (My partner works for the European Union, so I know first-hand how things are handled here.)

I think most software developers are now glad that the unique combination of American imperialism and stupidity has resulted in all computer languages and frameworks being presented in one simple language: English.

Microsoft has once made the error of trying to please the non-English users of Excel by offering versions of Visual Basic for Appliation (VBA) in non-English variants. I have to tell you, programming in that language, with Dutch syntax and keywords, was horrible. Our language is hard enough to speak, let alone to program in. Even the non-programmers that I was trying to teach Excel thought that this was weird. Since then, Microsoft has decided to ignore their European users. (A strategy that has resulted in a $2.57 billion fine imposed by the European Union.)

I think we should all be happy that Americans have imposed their language on software developers around the world.

Just imagine how awful it would be if everyone in the world had to program against French API’s on French frameworks. Anything written in French costs almost twice as many keystrokes as the English counterparts. And I really wouldn’t care for diacriticals and other typical French baroque embellishments in my programming languages. France, despite being the center of Western Europe (and feeling itself the center of Western civilization) cannot offer us the simplicity that the US can offer us.

And we can be just as glad that all the other old global empires have died long before they were able to impose their difficult character sets upon everybody.

The Arab empire has given us the decimal numeral system. But many of us still blame them for not having selected the octal numeral system, despite the fact that they did give us chess, which is octal by nature. This error has already cost the software development world billions of dollars in inefficiencies, so let’s be glad we’re not programming in the Arab language too. And if it had been the Turks we would now all be struggling with all the variants of the letter I.

Similarly, the Chinese empire has failed long before being able to trouble each one of us with Chinese characters. Of course, China is growing again. But, even though the Chinese can choose to ignore the rest of the world at times, the standard American qwerty keyboard is here to stay.

Good old American culture gave software development simplicity and no compromises. The typical American inability to grasp the nature of special characters has given us programming languages and frameworks with an easy syntax. It’s simply take-it-or-leave-it-English for everyone. And no funny British idiosyncrasies like the extra superfluous u, as in colour. That might have saved us another 0.x percent in size of various API’s. I can hardly think of a better example of the KISS-principle. Because, in this case the phrase "Keep It Simple, Stupid" actually refers to people having made things simple by being stupid.

In this respect it might be interesting to note that (British) NewScientist magazine has recently published an article on the rapid evolution of the English language. It now appears that stupid non-native English speaking people (like me) are making the English language even simpler and more consistent, because we often fail to recognize the last few exceptions that the English language still has. For example, many of us simply use "informations" as the plural form of "information". And why not? Let’s make it simple for everyone. We’re not all French, are we?

So, let’s stop attacking Americans for their simple-mindedness. Americans have saved me a lot of trouble. So I really don’t care if I have to explain to them that Copenhagen is not the capital city of The Netherlands. (It’s Amsterdam.)

If you enjoyed Jurgen’s writing, you can subscribe to his blog for more great ideas.

Similar Posts:

• Why Linguists Are True Code Artists
• Binding Software Patterns to Languages
• Quit Exaggerating On Your Skill Set
• How Did I Get Started In Software Development?
• Abstraction Is For Both Humans And Software, But Not Software

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

using System;
using System.ComponentModel;

namespace Codesqueeze.Entities
{
    public enum State
    {
        [Description("Alabama")]
        AL,

        [Description("Alaska")]
        AK,

        [Description("Arkansas")]
        AR,

        [Description("Arizona")]
        AZ,

        [Description("California")]
        CA,

        [Description("Colorado")]
        CO,

        [Description("Connecticut")]
        CT,

        [Description("D.C.")]
        DC,

        [Description("Delaware")]
        DE,

        [Description("Florida")]
        FL,

        [Description("Georgia")]
        GA,

        [Description("Hawaii")]
        HI,

        [Description("Iowa")]
        IA,

        [Description("Idaho")]
        ID,

        [Description("Illinois")]
        IL,

        [Description("Indiana")]
        IN,

        [Description("Kansas")]
        KS,

        [Description("Kentucky")]
        KY,

        [Description("Louisiana")]
        LA,

        [Description("Massachusetts")]
        MA,

        [Description("Maryland")]
        MD,

        [Description("Maine")]
        ME,

        [Description("Michigan")]
        MI,

        [Description("Minnesota")]
        MN,

        [Description("Missouri")]
        MO,

        [Description("Mississippi")]
        MS,

        [Description("Montana")]
        MT,

        [Description("North Carolina")]
        NC,

        [Description("North Dakota")]
        ND,

        [Description("Nebraska")]
        NE,

        [Description("New Hampshire")]
        NH,

        [Description("New Jersey")]
        NJ,

        [Description("New Mexico")]
        NM,

        [Description("Nevada")]
        NV,

        [Description("New York")]
        NY,

        [Description("Oklahoma")]
        OK,

        [Description("Ohio")]
        OH,

        [Description("Oregon")]
        OR,

        [Description("Pennsylvania")]
        PA,

        [Description("Rhode Island")]
        RI,

        [Description("South Carolina")]
        SC,

        [Description("South Dakota")]
        SD,

        [Description("Tennessee")]
        TN,

        [Description("Texas")]
        TX,

        [Description("Utah")]
        UT,

        [Description("Virginia")]
        VA,

        [Description("Vermont")]
        VT,

        [Description("Washington")]
        WA,

        [Description("Wisconsin")]
        WI,

        [Description("West Virginia")]
        WV,

        [Description("Wyoming")]
        WY

    }
}

Similar Posts:

• 3 Places To Keep Your Pocket Code (Besides Your Pocket)
• The 7 Software “-ilities” You Need To Know
• 3 Simple Ways To Avoid Making Code Smells
• Lobsters Attack the Gut Instinct Equation
• The Art of Harvesting Abstraction

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

I do agree that every team must have (and enforce) some basic standards of code uniformity. These may include items such as:

• Use PascalCase over camelCasing or Hungarian notation
• Prefer language keywords over hard types (as in – int not Int32)
• No single line if statements or use of ternary operators such as ?
• All references to class member variables will be prefixed with this.

These types of standards give a clear outline of the fundamentals of code cleanliness and uniformity that can aid in a team environment.

However, often I see team leads attempting to micro-manage these coding standards. The majority of these standards have very low impact on overall readability and maintainability. I have see religious wars break out over stupid standards such as:

• { on new line or same line
• _ or m_ in front of private variables
• The order of class member declarations (private vars, ctors, props, methods [in alphabetical order], etc…)

It is unfortunate that I see teams creating standards not only littered with these types of rules, but fore-running as the core foundation. These types of standards do have worth, but must be enforced with a much lighter touch as policing these types of infractions just does not yield overall benefit to the application.

In the large scheme of things these types of code uniformity infractions are small potatoes. It is the equivalent of creating a standard way of monotone communication for optimal office efficiency – yeah ok.

I am not advocating that we should not have coding standards nor that they should not be enforced by frequent code inspections; however, I am of the belief that developers write code with minor deviations that show the same uniqueness you would see in articulated words or drawn pictures. Instead of attempting to find a happy standard, let’s celebrate our minor differences in writing code and be more adaptive to different flavors.

Sometimes the small things do matter – but not in this case.

Similar Posts:

• Best of Codesqueeze 2008
• The Dangers of Git ‘R Done
• Burning Down the Architect Title
• Whiteboard Wednesday: Keeping Teams Small
• Metrics and Wealth – It’s All Relative

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

On a recent project, I had referenced a 3rd party component for PDF generation. When I attempted to add a spell-checking component from another vendor, *POOF*, everything went up in smoke. I could not shake a compile error complaining about ambiguous class names. Using Reflector I loaded up both 3rd party assemblies and found the following:

Careless obfuscation can create conflicting type names

I am protecting the guilty by blurring out the assembly names, but what is visible is the fact that both assemblies created non-unique namespaces and class names. This ambiguity created a deadlock of references and the possibilities were:

1. Get one of the vendors to get me a new build ASAP
2. Delay purchasing either component until a suitable replacement was found

Thankfully, this story ends happily and one vendor immediately responded to my email by fixing the issue and sending me a specialized build. The troublesome obfuscated classes had been moved into proper namespaces thus removing the ambiguity.

Compile errors are a bad first impression when attempting to make a sell. Bad obfuscation can cause problems that you may not have foreseen in testing. Test your assemblies in a number of scenarios to ensure they play nice with others and under different security contexts.

Happy Coding!

Similar Posts:

• Is Product Splintering The Future Of Software?
• Customer Polarizing – Why Microsoft Will Always Be A Mediocre Giant
• Sell Yourself With Business Benefits (And Not Geek Speak)
• Why Office Gurus Are Bad (And The Buses Who Hit Them)
• The Diminishing Return on Code Uniformity

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

1. xhtmlConformance is not set in web.config

Even if you declare a page to run as Strict, ASP.NET will still render all pages and controls under its default mode Transitional. In order to tell ASP.NET to render controls under Strict, simply add a xhtmlConformance tag in your web.config file.

2. Ensure you have a DOCTYPE

When setting up a new page, it is common (for me at least) to accidentally remove this declaration. Double checking that your DOCTYPE declaration exists is a commonly overlooked gotcha.

3. Add a w3cvalidator.browser file to App_Browsers

By default ASP.NET does not recognize the user agent for the W3C Validator service. As a result, pages and controls are not rendered under the XHTML conformance that you set. This again, is an easy fix. Simply download a w3cvalidator.browser and place it in your App_Browsers folder.

Yahtzee! You should be able to validate your page now. If not, more information on web standard fundamentals using ASP.NET can be found over on the MSDN website.

Similar Posts:

• Can XHTML Strict Ever Be A Practical Standard?
• The 7 Software “-ilities” You Need To Know
• Save Time By Writing Better Bug Reports
• The Ultimate Top 25 Chuck Norris “The Programmer” Jokes
• The Most Reusable Piece Of Code Ever…Period

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Users do not want to view validation summaries at the top of a page, only to go visually searching through your form for the invalid fields. Nor do they want to play a rousing game of hide-and-go-seek with little red asterisks (*). This is especially true when your form becomes larger and/or when multiple validation errors occur. The form below is fairly common place:

By writing your own custom validators, you can override the EvaluateIsValid and Render methods to add a new dimension of usability. Here are 3 tricks that you can implement in your own custom validators:

1. Modify Control.BackColor

Changing the BackColor property of the invalid control can be a quick and easy way to allow the user to instantly view which fields are invalid. Additionally, this is a way to do validation in situations where screen real estate is limited (i.e. PDA).

The implementation of this is easy: override the EvaluateIsValid method of the validator you are inheriting from (in this case the RequiredFieldValidator), find the control being validated, and set its BackColor property. Control of the color has been accomplished by an added property called InvalidColor and text is added to the control if it is of type IEditableTextControl.

Note: Modification of the invalid control must occur earlier in the ASP.NET Page Life Cycle than the Render method as it may be too late and rendering of the invalid control may have occured.

2. Use Animation

Using an image as a validation marker is generally a bad idea; however, in some circumstances images can work. Compact forms or very clean designs may benefit from a more stream-lined form of pinpointing invalid data. Before using images be sure that the users are able to fully understand what the iconic representation of each image is.

Implementation of this type of custom validator is slightly different as you will need to override the Render method. This is because dynamic creation and rendering of an Image control needs to occur before the base rendering.

3. Be Blatant

When all else fails, throwing messages the size of billboards will always work. To accomplish this, I used some Bubble Tooltip CSS, and put together a validator that displayed absolutely positioned balloon messages.

Using the two concepts outlined above, writing this validator is can be done is 3 small steps. First, we need to create the balloon image.

Second, register the CSS in the EvaluateIsValid method.

Finally, insert the specific HTML in during the Render method.

In order to achieve the absolute positioning you will have to create a style tag on your validator such as the one below.

UPDATE: Check out the ValidatorCallout in the ASP.NET AJAX Control Toolkit. Everything as the above with none of the work!

Feel free to download these validators and modify them for happier validating!


Similar Posts:

• XHTML Gotchas With ASP.NET
• How To Tactfully Gain Approval For Changes
• Money vs. Wealth
• The 7 Software “-ilities” You Need To Know
• Suck At Estimation? Use The 2 Day Crutch Method.

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.