Showing posts with label BadCode. Show all posts
Showing posts with label BadCode. Show all posts

Thursday, March 22, 2012

String replace the better way.

This last week I have been working on making my team project at work run better on ie 7.  Usually that would mean that I spent all my time fixing styles, but there are better people then me at that.  So for me the project was getting rid of the scrpt is running two long errors.  The app I work on is very JavaScript heavy.  One of the worst offending functions I had found was the following:

function clean(word) {
        if (word) {
            
            return word.toLowerCase().
                replace(/\s/gi, "").                
                replace(/[àáâãäå]/gi, "a").
                replace(/æ/gi, "ae").
                replace(/ç/gi, "c").
                replace(/[èéêë]/gi, "e").
                replace(/[ìíîï]/gi, "i").
                replace(/ñ/gi, "n").
                replace(/[òóôõö]/gi, "o").
                replace(/œ/gi, "oe").
                replace(/[ùúûü]/gi, "u").
                replace(/[ýÿ]/gi, "y").
                replace(/\W/gi, "");
        } else {
            return word;
        }
    }

Which is a very brute force way of cleaning up strings for searching.  It was the most expensive call in our system.  With a little work it was changed to the following. 

var removeAccents = (function () {
        var translateReg = /[àáâãäåæçèéêëìíîïñòóôõöœùúûüýÿ]/g;
        var translate = {
            "à": "a", "á": "a", "â": "a", "ã": "a", "ä": "a",
            "å": "a", "æ": "ae", "ç": "ç", "è": "e", "é": "e",
            "ê": "e", "ë": "e", "ì": "i", "í": "i", "î": "i",
            "ï": "i", "ñ": "n", "ò": "o", "ó": "o", "ô": "o",
            "õ": "o", "ö": "o", "œ": "oe", "ù": "u", "ú": "u",
            "û": "u", "ü": "u", "ý": "y", "ÿ": "y"
        };
        return function(s) {
            return (s.replace(translateReg, function(match) {
                return translate[match];
            }));
        };
    })();
 
    function clean(word) {
        if (word) {
            return removeAccents(word.toLowerCase().replace(/\s/gi, "").replace(/\W/gi, ""));
        } else {
            return word;
        }
    }

For a massive boost in performance.




Wednesday, February 16, 2011

Date Time you are doing it wrong again.

The other day I reading the greatest developer fallacy or the wisest words you'll ever hear and then today I found some code that I think illustrated his point that learning it when you need it isn't always the way to go. This code looks very much that way.  Although I think a quick Google search would have found better code then this even if you didn't know what words to look for.


System.Text.StringBuilder mxIsDt = new System.Text.StringBuilder();
mxIsDt.Append(DateTime.Now.Year.ToString());
mxIsDt.Append(DateTime.Now.Month.ToString());
mxIsDt.Append(DateTime.Now.Day.ToString());
mxIsDt.Append(DateTime.Now.Hour.ToString());
mxIsDt.Append(DateTime.Now.Minute.ToString());
mxIsDt.Append(DateTime.Now.Second.ToString());
string mxDate = mxIsDt.ToString();
Which converts into around 70 lines of IL and takes just 19160 milliseconds to complete.   Now my question is why wouldn't you use ToString on DateTime to do this. 

var d = DateTime.Now.ToString("yyyyMdhms");            
Which takes 8 lines or less in IL and takes 1213 milliseconds to complete. It's way less code easier to maintain and examples on how to do this can be found all over the web.  



Wednesday, June 30, 2010

Proper Use of Properties

Today we are talking about properties.  How to use them and more importantly how not to use them.

When dealing with properties like they wore written before 3.5 you should have some thing that looks like this.

private string _test;
public string Test
{
    get { return this._test; }
    set { this._test = value; }
}



I love properties like this it’s only slightly less cool then using the 3.5 version of a property. The thing I don’t like about a property like this is when a programmer decides he doesn’t need to user the property and accesses the _test variable directly inside of the class to make a change.  So like this




this._test = "some string";



I consider this bad programming.  It makes maintaining code much more difficult and adds an unnecessary level of complexity. You have to look at two things now to see how a value gets set or modified.  To do all the access through the property takes about the same amount of work and ends up in a much cleaner code file.




this.Test = "Some string";



Is actually one less key stroke and is so much easier to work with.