Shortcuts and Best Practices

Sometimes you think you don't need to follow Best Practices and that your situation is unique and different.... And that you're the best to judge right since you know the specifics of your current situation right?

... Not quite because most situations change so more often than not, taking that shortcut is going to hurt more than the extra few minutes it would've taken to implement according to best practices.

Trust me... I know... (Below are some personal examples.)

Getters and Setters 

When I first used Getters and Setters in Java, I always wondered why we needed write out the functions specifically, instead of like in C# where you could just use something like:

public string Name {get; set;}

At first, I actually didn't even know why we did this. Why not just use a public variable? Well you quickly realize making everything public is a very bad idea. When an object's field is changed by another object, usually it would like to know about it or have some say in what it can be changed to.

(It also saves you a lot of trouble if the underlying data type changes from like an int to a string, becomes a composite of multiple other values.)

But anyway... why would I ever need to implement it like as below?

Java
private String name;
public void setName(String value)
{
     name = value;
}

public String getName()
{
     return name;
}

Or slightly better

C# (Slightly easier)

private string name;
public string Name
{
    get
    {
         return name;
    }
    set
    {
         name = value;
    }
}


Why does Java make you write you to write it out? It does two things:

• It shows you how Properties actually work; C# is just automatically creating it when it's compiled (this understanding also helps you realize what a struct backing field is and why you get the related error)
• It will save you a minor inconvenience in the future where you need to add some validation logic or raise an event... like for INotifyPropertyChanged

Variable Naming

Early in my career and as a hobbyist, I would usually create some local variables for some calculation or formatting logic. But I used vague names for them as, at the time, they seemed trivial or temporary.

The keyword is seemed but as the surrounding code grew longer, very often it became less trivial: having a variable used like 5 times in some loop that spans over 50 lines of code makes it... not trivial.

Anyway, it saved me a few second at the time, but then months later there is an issue... you go back to the code and you cannot recall at all what this variable (or the function) is supposed to be used for.

If you're lucky you may be able to walk through it and figure it out... after like an hour.

Nowadays names are cheap and with code hinting, not very hard to type out. Use descriptive names and also comment when needed, because while they may not look so nice... they're really cheap.

Using x,y instead of row, col may make you feel smart until you spend 10 minutes trying to figure out if your incrementing a row or column (and sometimes like for an Excel output... that kind of matters... a lot).

Unit Testing

I work on existing systems, designed not by me. Test-ability was never considered and not a core part of the applications' designs (which also I think contributed to how messy and tightly coupled everything was).

Anyway, because we don't have tests for every possible usage, it is now extremely difficult to make core logic changes. One of the things I am doing this year is figuring out test cases from our usage data and creating automated tests that give us 100% certainty that any change does not alter existing behavior.

Another shortcut that now causes a lot more pain and issues... than it should.

Conclusion

The general thing about shortcuts is that you really need to think about and be able to predict whether or not the shortcut is worth it. For a small application, you can see far ahead and be pretty sure, and the cost of changing it is very low.

For a large and/or critical application or component, I've learned the hard way, from my own coding and from cleaning up other people's messes, that it is just better to not take the shortcut in the first place.

ALWAYS follow best practices, unless you are literally 150% sure the shortcut is worth it.